I won't defend it, but I can imagine that an argument for why self-signed certs could be worse than plain HTTP might be that if you're using HTTP, the communication isn't meant to be secure/trustworthy, but the presence of a certificate means that your communication is meant to be one or both, and since the cert is self-signed, it may not be either. This argument does presume that site administrators know what does and doesn't need to be confidential, which of course may not be the case.
Some argue that all communication should be encrypted, but that's another issue.
It's an argument made through misleading categories. Self-signed certs specifically are not an indication that the connection needs to be trustworthy, so treating it like HTTP is fine. If it's marked with HSTS, then fail it like HTTP. Don't show secure cookies. Easy.
But if someone clicks a link that says https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.
Because security is already confusing enough for the average user, and screen real estate is valuable. We don't need an extra type of distinction that they need to know. We don't want to have to say to someone, "before logging into your bank, make sure that it is https AND that there isn't some little warning somewhere about unconfirmed identity."
Then create a new name, like ohttp. If it is the name of the protocol that is causing a roadblock for better security, then changing the name should be the obvious choice. Alternative we could always treat http as both being an unencrypted protocol and a opportunistic encrypted protocol.
Depends on how you define "wrong". The S stands for secure, that's been pounded into people's heads. HTTP 1 and 2 are miles apart and get the same protocol marker. So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
> The S stands for secure, that's been pounded into people's heads.
The S stands for "this connection is on port 443 and has been negotiated with TLS". That means it's being encrypted and has been authenticated.
> HTTP 1 and 2 are miles apart and get the same protocol marker.
Which was and is a terrible terrible idea and among the many reasons I dislike HTTP2.
> So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
Which is a terrible terrible idea. The protocol marker should denote the protocol used, not some fluffy stuff that doesn't really mean anything to the user.
>That means it's being encrypted and has been authenticated.
Except that TLS does not always imply encrypted and authentication. You can use TLS with a self-signed cert. You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
Whether the connection is actually encrypted and authenticated is what the vast majority of users care about. I'm not sure how you can call that fluff.
(Now as far as http 2, it's tricky because it's kind of at a lower layer that still runs http on top. And when you're linking to something you don't care about whether that layer exists. So there are pluses and minuses to having http2:// or spdy:// or whatnot. Not that any of that matters, because cocksure middleboxes nearly force it to continue to use http://.)
And your point is? If there is no port specified, that's what it's on if the protocol is HTTPS?
> You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
As they should, because allowing such things to happen automatically is contrary to what the spec is expecting to happen:
> If the hostname does not match the identity in the certificate, user
> oriented clients MUST either notify the user (clients MAY give the
> user the opportunity to continue with the connection in any case) or
> terminate the connection with a bad certificate error.
elsewhere
> In order to prevent this form of attack, users should carefully
> examine the certificate presented by the server to determine if it
> meets their expectations.
(for the second quote, the User Agent automates that process to make sure the certificate meets trust and expiration and the cipher suite meets exceptions.)
That's good in that it requires a slightly more sophisticated attack, but I don't really view that as a very effective defense.
However, the bigger thing a self-signed cert allows you is the ability to verify later if your communication has been snooped by an active attacker--which is very significant. It's problematic that the communications aren't authenticated before they occur, but that doesn't mean they can't be authenticated later (via CAs or other means).
I hear this frequently but I don't buy it. What about the MITM scales worse than a passive listener?
As far as I can tell, both insertion of a passive listener and a MITM are algorithmically O(n) on the number of connections being surveilled. All you're increasing for the MITM is the constant factor.
When you're on the order of billions of connections being surveilled, even linear growth is hard, but we know that the NSA already has done that. Increasing the difficulty by a constant factor is not much harder, and there's no question that the NSA has the budget to do so. And in fact, the constant factor isn't even large: it's whatever the resource costs of two connection handshakes per connection is, plus decryption/encryption on the data flowing across, all of which are highly optimized algorithms at this point.
No. Passively listening only requires dumping whatever flies over the interface of some router. Done! Very hard to detect. You can also just scan for keywords and only start dumping traffic when triggered.
With SSL, you cannot retroactively decide that you'd want to dump traffic. You have to MITM from the beginning.
That's point 1.
Point 2: Detection.
Actively MITM-ing an SSL connection requires you to (if the CA Chain-O'-Trust works as supposed) give away the fact that you own a (valuable!) compromised CA authoritative cert. You would want to use such a cert for a targeted attack, not waste it on blanket surveillance and get found out (and called out) within a couple of days.
If you don't own a root cert but rely on vulnerable implementations, or implementations such as this one which do not rely on the CA infra, same story. You do not want to waste that on blanket surveillance and get caught. You'd save it for the /special occasions/.
SSL-MITMing everyone, all the time, as in blanket surveillance, is unfeasable even without CA chains. You'll get called out on it by people that do check cert fingerprints once in a while.
This is a different kind of scalability than the computational order-of-complexity one that you seem to be thinking about.
Can anyone who's in the "HTTPS without certificate verification is bad, m'kay?" camp (I'm not directing this to the author of the post I'm replying to) compare and contrast that approach to the approach of SSH, where there is (usually) no such validation, and the breaking of which could have much larger consequences on global security then just HTTPS?
Why not adopt the SSH model of accepting the server's cert at the first connection and then complaining loudly if the fingerprint changes? Or even go a step further and have browsers manage private keys (client certs) which identify the user? Some Linuxes already do this with SSH: if you have a private SSH key, an SSH agent will remember its decrypted form on first use, and use it for SSH auth.
The client certs can be exchanged in a standard format throughout browsers and devices, and mobile phone-based two-factor-authentication can be used to increase security.
So - bam, good enough MITM protection (sure, let the banks retain the PKI system), no passwords, and a completely ready implementation requiring no new standards. There is no requirement for the client certs to be "blessed" with strong identification with the person, so anonymity is achievable by having an arbitrary number of different client certs.
It is a GUI problem. How it is presented to the user.
Typical mildly advanced user thinks this way:
I see https:// in URL bar and no scary red/yellow untrusted cert dialog? -- Ok I am all set to type my credit card number in.
There are the green brackground in there too, which I forget what it means, but it presumes some extra "security/authentication" thing.
What should the encrypted but not authenticated mode show? https:// with a yellow or gray bar? Try to teach the user about is the difference between authenticated vs encrypted. Warn them once and put a "Got it, do not bother me again" dialog.
Remember windows vista with "deny or allow?" dialog every single time you did anything with your computer. The intent was good but how the users perceived it was the problem. Here it is the same problem.
The problem with that argument is that HTTPS is being increasingly used for all traffic, rather than just traffic meant to be confidential/authenticated. As a result, the semantic difference between HTTP and HTTPS is being lost in those cases.
Some argue that all communication should be encrypted, but that's another issue.