Re: Why is self-signed such a bad idea ?
> - To encrypt the connection to
> the endpoint.
> - To verify that the endpoint is
> the intended recipient.
> Self-signed combats the first
> but not the second.
A subtle point here that I suspect Lee understands but others may have missed.
The first point is more correctly stated as "To encrypt the connection to some endpoint". If you deliver your site over a self signed certificate, you cannot be sure that the self signed certificate presented to the browser is the one you sent. Here is the scenario in action.
1. Alice visits bob.com from Mallory's internet cafe.
2. Mallory intercepts the initial clienthello negotiation and sends a fake serverhello with a self signed bob.com certificate.
3. Simultaneously, Mallory does her own clienthello to the real* bob.com and negotiates everything from there.
4. When Mallory gets the response back from bob.com, she decrypts it with the negotiated session key between her and the real site, then re encrypts that stream with the session key she negotiated with Alice.
5. The process is reversed for sending any requests to the server.
Realise that neither Alice nor Bob see anything unusual in this interaction. Alice would be informed by a big red warning box in her browser that the certificate is untrusted. The problem in our scenario is that this is exactly the error she will see where communicating with bob.com without Mallory in the middle.
*A comment on real site in this context. Even Mallory could not know in this step whether another mitm exists between her and bob.com. It's turtles from there.