On Thu, 20 Nov 2003, Joel Aufrecht wrote: >Thanks for the tips in this thread - I got imaps working no problem. >I wanted to verify my understanding: >The significance of the key and cert is that they prove the identity >of the server. If we didn't care about that, we wouldn't really need >to generate and protect private keys and create certs - the server >could just make something up on the fly, as the client already does.
Well, the client doesn't make up a cert. All client software should have access to a CA bundle that came with the distribution. This CA bundle contains hard-coded certificates of what is known as Certificate Authorities, othewise known as "trusted third parties". Basically the server grabs the certificate from the IMAP server, which can basically be forged in any way. It then connects to one of the certificate authorities (it checks its ID against the hard-coded certificate) and checks if the certificate it got from the IMAP server matches the host it got it from. It's a tad more complicated than that really, but that's the basic idea. Once the identity of the server is established, the server and client agree on a encryption cipher to use, such as Blowfish, 3DES and so on. They seed the crypto algorithms and synchronize them, and then start sending data to eachother. >In this situation, the pipe between client and server would be >encrypted, but neither client nor server would have any assurance, >beyond the soft protection of DNS and routing, that the computer at >the other end was the one they thought it was. This problem is >slightly mitigated on the client end, because the client provides some >authentication to get its mail. Well that's a different layer of security. The transport layer, SSL, makes it hard for people to intercept, forge or replay your communication data. Without a properly signed certificate for the SSL layer, it's still quite hard to intercept the communication, but not for people who really know what they're doing. >Question: does anybody actually check the server cert that we have to >go to the trouble of generating? Am I missing something when I assert >that, given the profiteering and fundamental security holes in >commercial PKI, most server-side certs in most uses have no >effect other than to complicate installation? If so, would it be >possible to remove this step, which sometimes ends up *reducing* >security by causing people to give up ssl? Every mail client that uses SSL should check the SSL certificate, and issue a warning to the user if the cert does not match the host. And as far as I know, all clients do. If the server only provides a self-signed cert, then the client will have no CA to look it up with, and so the identity of the server can not be verified. The communication is still encrypted, but it is vulnerable to interception, forging, replay etc.. So the three options are: 1 - Provide plain text authentication 2 - Provide SSL encryption with a self-signed certificate 3 - Provide SSL encryption with a third-party signed certificate Number 3 is definitely preferred, number 2 is not so good but okay if the server can act as a CA for the cert, and number 1 is quite unacceptable over an internet connection. Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
