Is it possible to prevent man-in-the-middle attack when using self-signed certificates?

Question

I'm not sure is similar question has been asked before (I couldn't find any), but is it possible to protect Client/Server from Man-In-The-Middle attack?

I'm writing a Client application to communicate with Server. Communication will be SSLv3 based. I am OK with server's self-signed certificates, but worried about someone else generating same self-signed certificate in the same server name and pretend to be it. My Client application uses OpenSSL library. [Client and Server are thrift based, if it makes any difference]. Can I avoid such attack at the same time maintaining support for self-signed certificates?

If your application doesn't need to be compatible with existing clients/servers, you might as well go straight to TLS 1.x (the highest supported by your libraries) and skip SSL 3.0 if you can. — Bruno, Jul 30 '12 at 19:34

Joachim Isaksson · Accepted Answer · 2012-07-30T20:59:03.397

16

Yes.

In short, a self signed certificate is more insecure than a CA certificate only when the client does not know the certificate in advance and therefore has no way to validate that the server is who it says it is.

If you add the self signed certificate to the client and don't accept any other certificate, you're actually as secure (or, one could argue, even more so) than having a certificate authority signed certificate.

The important parts to keep SSL secure with or without a certificate authority are;

The server private key (and in the case of a CA, the private keys of all its roots) is kept secret.
The client knows the server certificate (or its CA root).

edited Jul 30 '12 at 20:59

answered Jul 30 '12 at 17:10

Joachim Isaksson

176,943
25
281
294

Looks like possible solution in my case. So, even if 'man-in-the-middle' presents same certificate (public key to be specific) as that of my 'real' server, it can't decrypt data from client as it won't have the 'real' server's private key, right? – Tushar Sudake Jul 31 '12 at 03:56
@TusharSudake Exactly, the certificate is of no use to anyone that does not have the private key for it. – Joachim Isaksson Jul 31 '12 at 05:11

score 4 · Answer 2 · answered Jul 30 '12 at 17:09

4

You can hard-code the server's certificate and compare it against what you receive.

Or better yet, create a CA certificate and server certificate, signed by the CA. Have the CA trusted on the client (again by hardcoding it in your application) and validate received server certificate using the CA certificate.

answered Jul 30 '12 at 17:09

Eugene Mayevski 'Callback

45,135
8
71
121

(Manual configuration can also work, instead of strict hard-coding.) – Bruno Jul 30 '12 at 19:37
@Bruno indeed. But this makes users' life and support a bit more complicated, so I like self-made CA approach. – Eugene Mayevski 'Callback Jul 31 '12 at 07:11

score 1 · Answer 3 · answered Jul 30 '12 at 17:09

If you can protect your private keys well enough, a middleman will not be able to masquerade as you, assuming the user actually looks at the certificate. The problem with self-signed is that if you want the user to add the exception to their browser, or just ignore the warning, then you are exposed to man-in-the-middle attack, because anyone else may create their own certificate.

Of course, "protecting your private keys well enough" is not trivial at all. When you pay for a "Verisign" certificate, you're not paying for their software creating the certificate - you're paying for the security forces they have guarding the building in which the private keys are stored.

score 0 · Answer 4 · answered May 15 '21 at 05:45

0

That's easy! NOOOO !!! Not anymore than you could prevent a man-in-the-middle attack from certificate issued-by a well-know authority. >:)

answered May 15 '21 at 05:45

SensorVista

71
4

Is it possible to prevent man-in-the-middle attack when using self-signed certificates?

4 Answers4

Linked