Whether indy SASL component can use to TIdTCPServer and TIdTCPCLient?
if can, please give me advice how the algorithm to handle that ?
Do I have to use TIdSMTP too ?
Thanks
Indy's SASL components are client-side components only. There are no server-side SASL implementations available in Indy at this time. You would have to implement server-side SASL manually. The SASL components are designed primarily to be used with the TIdSASLCollection class, which is used by the TIdSMTP, TIdPOP3, and TIdIMAP4 components. Have a look at the source code for those components to see how to incorporate SASL into your client code.
Related
I am experimenting with Google RPC and managed to establish an encrypted connection. Now I would like to perform NTLM authentication on server. I know that I should use a pair of functions InitializeSecurityContext and AcceptSecurityContext for that.
I was intending to do it by myself, but then I found traces of these functions in Indy components, namely in IdAuthenticationSSPI.pas and IdSSPI.pas. After unsuccessful attempts to figure out what and how could I use for my task from Indy library, I started to look for examples in Internet, but all these examples work with TIdHTTP component.
Could I really use SSPI separately from Indy?
Is there any way to explicitly specify the set of cipher suites that you'd like your URLSession client to try and use when establishing a secure connection?
I know that there's the NSExceptionRequiresForwardSecrecy key in the NSAppTransportSecurity dictionary but that doesn't seem to be what I need.
I basically just want to be able to tell the client to notify the server that it is only willing to use the following cipher suites:
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,
That way I can decrypt the HTTP/2 traffic that the client and server and communicating with.
As far as I'm aware, there's no way to do this at the NSURLSession level. You can, of course, write code based on the Secure Transport API, but AFAIK there's no easy way to make NSURLSession use a custom underlying socket. (You might be able to use CFHTTPMessage and friends to make it slightly less horrible than writing a full HTTP stack yourself, but it still won't be pretty.)
With that said, if you're using an HTTPS proxy (e.g. Charles Proxy), it should be able to specify which cipher suites are supported and let you MitM the connection without the need for any sort of custom code in the app itself.
If that doesn't meet your needs, I would encourage you to file enhancement requests at bugreport.apple.com and explain what you're trying to do and why. They might be able to suggest some other options.
I have learned a little about https, but was not clear why it is needed.
What if I encrypt the data using the most powerful algorithms like RSA instead of sending through a HTTPS zone? Can someone explain with a few reasons why we need https?
On the Wikipedia article it says
Technically, it is not a protocol in itself; rather, it is the result
of simply layering the Hypertext Transfer Protocol (HTTP) on top of
the SSL/TLS protocol
On the SSL/TLS article on Wikipeida,
TLS and SSL encrypt the segments of network connections at the
Application Layer for the Transport Layer, using asymmetric
cryptography for key exchange, symmetric encryption for
confidentiality, and message authentication codes for message
integrity.
So the key exchange does use asymmetric cryptography and RSA is an asymmetric cryptography algorithm.
After key exchange has been performed in a secure manner further communication can be done through symmetric cryptographic algorithms. The reasoning behind using both symmetric and asymmetric algorithms can be found here.
What if I encrypt the data using the most powerful algorithms like RSA
instead of sending through a HTTPS zone?
You will have to implement all by yourself, i.e. reinvent the wheel. HTTPS is by default supported in every browser.
Can someone explain with a few reasons why we need https?
Secure communication that is widely supported. If you have in the middle of communication someone with sniffer tool like Wireshark, he/she will be able to see all packets that you and your peer exchange. Try to catch the HTTPS communication, you won't be able to see anything meaningful in the body of the request.
You could indeed encrypt the data by yourself, but you will face a big problem: The encrypting code must be available on the server as well as on the client (normally the browser).
Implementing the encryption on the server can be done securely. On the client side you can either install a software (plugin), or you can send JavaScript to the client. The problem is: how do you get the encrypting code to the client? Everybody evesdropping, will get the javascript code as well, so he can do the same things as the client will be able to do.
Instead of forcing the user to install a plugin, you can use the built-in support for SSL, every browser understands this protocol already. You could think of it, as an already installed plugin for encryption.
I need to implement Microsoft's LDAP server signing protocol to be able to connect to AD servers that require it but can't find this protocol description. Is there a protocol description published somewhere?
If it is done from LDAP it is implemented from a SASL mechanism implementation and utilizes GSS-SPNEGO/GSSAPI.
Perhaps the first problem is to determine "What is Signing?"
Which AFIK, Signing implies:
Clients that are signed SASL (Negotiate, Kerberos, NTLM, or Digest) or LDAP binds over a SSL/TLS connection.
So no simple binds or un-signed (ie un-encrypted) SASL mechanisms.
The Negotiate, Kerberos, NTLM, or Digest are implemented from GSSAPI/SPNEGO.
I'k looking for a xmpp windows client with SSO feature in a Windows Domain.
I've tried pandion but it doens't work.
You're likely looking for Kerberos 5 support. The GSSAPI SASL mechanism is how this works on the wire. I think Psi implements GSSAPI. Setting this up on the server side can be hard, so please don't assume that if it doesn't work the first time it is the client's fault.
Spark + Openfire (http://community.igniterealtime.org/docs/DOC-1362)