Fact: Submitting a password (or anything else) is far more insecure over a plain HTTP connection than over an HTTPS connection because HTTPS - even if the server certificate is self-signed - is at least encrypted.
Paradox: Why do modern browsers scream "danger" if you visit a site with a self-signed certificate, but say nothing when you submit an input of type password over plain HTTP? This unnecessarily complicates the life of developers who, trying to prevent transmission of passwords as plain text (but without budget to buy a commercial certificate), enable HTTPS with a self-signed certificate only to receive complaints from users saying that the browser now presents a full page error message saying that the site has now become a security risk. (As if it were not a far worse security risk when it was running over plain HTTP.)
Mozilla Firefox has gotten some criticism for their particularly bad handling of this. See http://tech.slashdot.org/tech/08/08/22/1139236.shtml
In fact, this fashion was started by InternetExplorer 7, and the copied by FireFox 3.0. And it is one of the biggest mistakes I have ever seen, it basically sends the message: "Self signed HTTPs is more insecure that plain HTTP".
To have a sensible security policy, all browsers should present this annoying "This site is a security risk follow these cumbersome steps for reading it" for every plain http site on the web.
[Wouldn't be bad before posting password fields, at least. However, something to realize is that HTTPS can be performed without a cert. SSL allows it. I'm not sure what the configuration effort on IIS or Apache would be.]
- There is not need to try to configure HTTPS without a cert, just create a self signed one and you are done(of course it would be better if webserver could create one just in time).
- [Self-signed certs are pointless. The main reason for certs is to protect against Man-in-middle attacks, and self-signed certs cannot do so unless one modifies the protocol to add a secure-hash of the public key to every URI (which is fine for ObjectCapabilityModel implementations, but not so great for web URIs - which are often intended to be human legible). Self-signed certs also require an extra protocol handshake.]
- Self-signed aren't pointless. My secure connection means that no one in the Starbucks I'm sitting at it toying with the data in transit. Nor their ISP, nor the server's ISP, nor the NSA etc... They can compromise the endpoint, but then that's easier than cracking TLS, and at that point transport encryption is meaningless against that attacker. Also while I dislike the ugly warning, it puts the fingerprint in front of my face to verify against the copy in my wallet. A JIT TLS cert would be more worthless, as you couldn't hold a verified copy of the public key or its fingerprint.
- [Tell me: how many of these 'fingerprints' do you have in that wallet of yours? I know the answer for most people is: 0. Self-signed certs aren't secure against man-in-middle attacks unless you can trust the cert you're looking at was actually signed by the endpoint, which requires either a trust source (usually the certificate authority; you're trusting an earlier visit to the same domain by another ISP) or a secure URI (one with an unforgeable fingerprint that allows you to challenge the remote server... e.g. a self-signed SHA hash of a public key). The latter is better for decentralization of authority (no certificate authority or WebOfTrust needed). The fingerprint-in-wallet approach is pretty weak, given that you cannot trust any new sites you visit unless they are served to you through your trusted authority and you can trust the ISP through which the site is hosted and every intermediate ISP.]
- How many? One. The fingerprint was given to me by the person who had it generated and installed it on the server, this transaction occurred in person. Possibility of a man-in-the-middle attack? Depends on how much I trust that person to actually be the server admin. Does it scale? No, and I'm not claiming it is, I have only 3 self-signed I'm trusting, but I can trust them completely. I can still fall back to trusting CAs for most certificates (or accept the fact that like 99+% of the web I _can't_ trust it). Since the data on the site has usernames and passwords to protect the data, it is pointless to not have the data encrypted, and be dumber to have the authentication unencrypted when the data is. The point of this page's title is that somehow it is "safer" according to current browsers to use a plain http site (and let the usernames, passwords and data be sniffed), than one with a self-signed cert.
- [If the goal is "to protect the data", then it is sensible to encrypt everything. Regarding the "safer" comment, I'm of two minds. On the one hand, I agree that encrypted is less subject to arbitrary attacks, if only because sniffers are easier to build than getting a man in the middle. On the other, I believe that the illusion of safety offered by a little 'closed lock' and 'gold URI' can be, in some ways, more dangerous. Users should be aware of their security and privacy in a given context. If browsers put up a big, fiery alert every time it was going to transmit a plain-text password, or simply rated the security of sites (i.e. on a rubric of five stars), that might be better.]
[Anyhow, rather than plaintext passwords, one can also use
HmacUserAuthentication with a small bit of javascript. It can provide very powerful security at a tiny fraction of the cost (SSL has a lot of extra handshaking.)]
Yes, but that only works for passwords, the rest of your data is still being transmitted unencrypted....
[HmacUserAuthentication protects the password and the content of the data (in the sense that nobody can toy with it). With a little extra protocol, it can also protect against repeat attacks. For many sites, that's enough. If you need full site encryption for privacy from end-to-end, HTTPS is the way to go (at least for now and the immediate future). But protecting passwords is very important, in part because people reuse passwords all the time.]
CategorySecurity
Http Https Security Paradox