[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Bryan Stansell bryan@conserver.com
Tue, 2 Nov 2010 02:41:40 GMT
On Mon, Nov 01, 2010 at 09:25:41PM -0400, Thor Simon wrote: > On Mon, Nov 01, 2010 at 11:41:26PM +0000, Bryan Stansell wrote: > > > > Well, if you provide the certificate, it needs to succeed it's > > authenticity check. If you don't provide one at all, it falls back to > > an anonymous cipher (so, it's encrypted, but not authenticated and > > subject to man-in-the-middle). > > But anyone can man-in-the-middle the client by pretending to be a server > with no certificate, no? > > Thor Isn't that what I said? ;-) But, taking that a step further, my summary before was off. In the case where the client has a certificate and the server doesn't, it's really: - Client-side certificate only - server fails SSL handshake - *this just won't work* The reason? We disable anonymous ciphers if we load a certificate. I haven't looked into the exact reasons (dunno the low-level details of the SSL protocol - at least not as much as before) but a test showed it fails the handshake. Now, if the server ignores this issue, perhaps it can fake it out. I assume the client side would fail handshake as well if the server didn't provide a cert (since it won't accept anonymous ciphers). Maybe someone out there knows the protocol. Otherwise, it'll require some testing - but this is my best guess right now. So, I *think* it's safe to say you're talking to the right server as long as you have a certificate loaded and the proper CA repository on the client. I do agree that more hooks to force this would be nice (like, you *must* validate with this CA or whatever). Bryan