This document says that a challenge response authentication proves the servers identity. But is a man in the middle attack still possible if the client does not verify domain name ? Please help me understand this.
Asked
Active
Viewed 1.1k times
3 Answers
20
The SSL handshake implies the use of certificates; the server has a certificate which the client shall validate (with regards to its known trust anchors, aka "root CA"). The certificate contains a public key and the cryptographic algorithms used in SSL that the connection is secure in the following way:
The client knows that whatever data it sends and receive will be usable only by the server which owns the private key associated with the public key it received (within a certificate).
The certificate proves to the client that the said private key is owned (controlled) by some entity whose name is written in the certificate; for SSL, the name is a DNS name such as "www.example.com".
It is still up to the client to check that the name in the certificate is the name of the server that the client intended to contact in the first place.
Analogy: you meet someone who tells you that his name is Bob. You ask him to show you an ID card. Verifying that the ID card is a genuine ID card is not enough; you also have to check that the name on the ID card is indeed "Bob". Otherwise, Charlie could tell you "I am Bob" and show you his ID card with the name "Charlie".
Thomas Pornin
- 320,799
- 57
- 780
- 949
-
Perhaps could you add in a little blurb about how to verify the certificate path in your browser? I know it should be common knowledge to most by now, but there's still plenty of people out there not familiar with it. – Iszi Jan 21 '11 at 16:42
7
Thomas' answer is great as far as it goes. I'll just note that there are still holes in the system, and you're right to pay close attention.
The biggest hole is that by default you probably have a huge number of "trusted" root certificates, any one of which can certify any DNS name out there. I think there is reason not to actually trust them all.
For example, in 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy. But it is in a lot of trusted CA lists: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars
The mechanisms used by many CAs to validate that you own a domain name are vulnerable to various attacks, so folks can get credentials that they shouldn't.
Also, people can steal certificates, as was done twice by the stuxnet developers.
The policy-related parts of the public/private key puzzle are really much harder than the crypto itself.
Update: See also a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure
nealmcb
- 20,544
- 6
- 69
- 116
1
A server proves its identity by being signed by a root (or intermediary) certificate authority that your browser trusts.
The root CA (e.g. Verisign) will digitally sign the site's certificate request. The digital signature is Verisign's way of certifying the identity of the original website. Verisign has methods for preventing someone like me from generating a certificate for ebay, usually via in person registration or by using a combination of proofs of identity.
The list of root CAs is updated and revoked as time goes on, you may notice this in your windows update.
That being said, if someone has physical access to a machine, they can always install fake root certificates...which makes man in the middle possible again, without warnings.
oreoshake
- 309
- 1
- 9