Delphi Indy - How to get SSL certificates for a SSL-TCP Client/Server link with Indy 10

Question

I'm completely new to SSL and these ciphering stuff but I need to make communicate client and server Delphi XE6 apps running on mobile devices. The TCP communication has to be safely ciphered.

To start, I simply wrote the Delphi/Indy TIdTCPServer/TIdTCPClient based Win32 client and server exchanging strings. (Issued from the indy10clieservr demos found on SourceForge: svn://svn.code.sf.net/p/indy10clieservr/code/1_sample Simple String Exchange)

I tried to modify them to cipher the communication by adding a TIdServerIOHandlerSSLOpenSSL component on the Server, and a TIdSSLIOHandlerSocketOpenSSL on the Client, attaching them respectively to the TIdTCPServer and TIdTCPClient.

I set their following properties on both sides: - SSLOptions.Method = sslvSSSv23 - SSLOptions.Mode = sslmServer / sslmClient (respectively) - SSLOptions.VerifyDepth = 2

And I added an OnGetPassword Event handler setting the Password parameter to 'password' on both sides too. (What is the role of this password ? Is it critical for the privacy of the communication ? What if it is found by analysing/reverse enginering the binary file ?)

Finaly, in the server's OnConnect event handler I set the TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough property to false.

But what about the 3 SSLOptions certificate properties ?? - CertFile - KeyFile - RootCertFile

How to generate and deploy them on my target devices to make run my SSL layer on the client and server ?

Moreover, is there something special to do or to take into acount if I intend to deploy later my server and/or clients on IOS or Android mobile device.

I'm aware that I have few knowledge on this SSL topic. Sorry if I ask something trivial. Any basic documentation explaining all of this tricky stuff to a newbie would be greatly appreciated.

Answer 1

As I told you in my answer to your same question on the Embarcadero forums, certificates are optional. They are used to allow peers to validate each other's identities, not for encryption. Certificates help avoid man-in-the-middle attacks, by allowing a client to verify it is connected to the correct server it is expecting to be connected to, and vice versa. It is not common for a client to have a certificate, except maybe when making a proprietary system where only authorized clients are allowed to connect. But it is pretty common for servers to have certificates, at least. Certificates can be password-protected, so if you do use them, you have to provide the correct password for the certificate(s) that you are actually using. A certificate's password can't be retrieved from the certificate itself, but if an attacker gains access to your certificate files then you have bigger issues to deal with.

As for SSLv23, it is a wildcard that allows dynamic version negotiation in cases where client and server support different SSL/TLS versions. SSLv23 allows them to figure out and use the highest version common to both parties. If a server needs to support a wide range of clients, it makes sense to use SSLv23 on the server side. Not so much on the client side. Since you control both client and server, you should use use a specific version instead, preferrably TLSv1 or higher.