SSL on login pages?
August 25th, 2005
Kasia is doing her oh-you-morons thing again. But she might just be wrong here: SSL is not only for encryption, it is also used for authentication. The server needs a certificate that is provided by a trusted (by the user) Certificate Authority, yada yada... (you know this stuff). While I think that phishing is done in more subtle (and thus easier) ways than DNS-hijacking, the authentication in itself should not be seen as "a waste of CPU cycles".
Maybe it's a flaw in the https-model, where encryption and authentication can't be separated (as opposed to encryption and authentication in the email world: you can do each individually, or both at once). That doesn't necessarily mean that the designers of https were clueless.
April 21st, 2008 at 10:18 PM They can’t be separated for good reason. Authentication without encryption makes sense. But how are you going to do that over an insecure channel? You need a secure channel to be sure that a middle man is not tampering with the communication. Encryption without authentication only seems to make sense. Because the remote end has no authenticated itself, you have no idea whether you’re actually talking to the remote end you think you’re talking to – there might be a man in the middle de- and reencrypting all communication between the two parties. So cryptographically, you cannot separate one from the other. It might make sense to separate authentication (done over a secure channel) from the transmission of authenticated data (can then be done over an insecure channel), but I can hardly think of any scenarios that would benefit significantly from this option.