How safe is my SSL connection even with a SSL certificate?

Question

I have a client program that talks to a web server through a SSL connection (https). How safe is this connection? I bought a SSL certificate installed on my web server, so my understanding is that even if someone attemps a man-in-the-middle attack between my client and my server they would not have the certificate? Is this true?

So for example if they attempted to redirect the hostname www.myserver.com to an ip they own, the https will still fail because the connection will report an untrusted source without the certificate installed?

---

Just wanted to point out that my program is a binary, not a web page that a user will see through a browser. Therefore they cannot simply press "accept untrusted SSL" and carry on. My binary is coded to exit if a untrusted SSL connection is detected. Given that, is it still possible for someone "in the middle" to redirect the traffic to somewhere and extract the encrypted data?

Thanks!

Answer 1

If the 'man-in-the-middle' actually sits on the client computer (think of a virus, trojan or other malware) they can read/modify anything going on over that connection. However, between the client and the server, the connection is quite safe, provided your client program checks the validity of the SSL certificate.

Answer 2

If it's a person (not code) choosing whether or not to accept the SSL certificate, the error that results from the hostname change might not halt everything, as the person might click right past that warning box.

Answer 3

It depends on how you validate the certificate on the client-side and what CAs you've chosen to trust in the validation process.

If any of the CAs your client application trusts have issued a certificate to the same hostname, this certificate can be used in a MITM attack. (And it's not completely unheard of that certificates have been issued to the "wrong" people).

What CAs are used in the process to determine whether or not a signature is valid depends on your SSL library and how you've used it.

I.e. in the case of browsers, firefox is bundled with a set of CA certificates from more or less reputable SSL vendors which your browser trusts by default.

Windows similarily has a certificate store which IE trusts by default and I'm guessing other applications using Microsofts SSL libraraies either will have the option to use this certificate store or use it by default.

Answer 4

Yes, you are generally safe from MitM attacks when using SSL, which was engineered (and revised) to prevent it.

Just to be clear, your SSL certificate is public information - and has no secrecy value. Your server will give it out to any client that says Hello. It's the private key matching the public key in the certificate that must be kept, well, private.

For maximal safety of the connection, you should tightly restrict the certificates that are acceptable to the client - in fact you can even restrict it to an exact match by storing the certificate itself (or the certificate's hash) in the client. In that case you don't even care about hostname matching - and you eliminate even the miniscule chance that a hostile intermediary has managed to get a valid certificate from your CA with your hostname in it, and has also subverted DNS.

Answer 5

The data transferred between the server and client is encrypted.

So for example if they attempted to redirect the hostname www.myserver.com to an ip they own, the https will still fail because the connection will report an untrusted source without the certificate installed?

Yes. But still the warning message can be ignored by the user if he is not worried about security. Only the communication is secure and safe. If there is a client program (virus) which can interpret the received data and do what ever it wants. So its better to educate the client (user) about security issues and importance of having a "safe" PC.

If the data transferred if very confidential then you can add another layer of security by adding a digest field (formed with the data to be transferred along with a secret key) and passing it to client. The client can then create the digest once again (with the data received and secret key) and then compare it for any mismatch.

If there is a mismatch the data was modified while it was being transferred.

Answer 6

You are confusing the issues:

1. transport level security, which SSL provides; and
2. client authentication, which SSL does not.

Depending on your application, you may want to consider using something like an SSH tunnel instead. That provides both strong crypto to protect the transport, and also login credentials via the use of public-key crypto.

You could automatically generate a new public-key for each client programme and add that to your list of authorised keys for login. Therefore, only clients that you have authorised can ever gain access.

Most SSH clients will automatically fail when they encounter a server with a different public-key from what they expect as known hosts. You can pre-configure this to be your own server public-key.

Answer 7

Tls do provide for client authentication in the handshake