I rarely care. Even the CA-signed certs are usually for "RL Media Enterprises Inc." or something equally opaque to me, rather than something more meaningful.
Bluntly, the refusal of a certain part of the security community to simply secure transport first and then worry about authentication on top of that is both frustrating and mind-boggling.
No. With http I can phish you, and anybody else can read or alter that phishing attempt. With self-signed certificates, I can phish you, and you know that my phishing attempt was neither altered in transit nor read by anyone else. We now have a channel over which we can negotiate authenticity.
If you went to my blog and saw that a CA had verified that I am who I claim I am, that doesn't particularly help you, because you don't know anything about me. But you might like to know that, whoever I am and claim to be, no other party is interfering with our communication. My issue is not with things like Gmail or my bank, but with the thousands of "ordinary" sites where learning the identity of the business that owns the site doesn't actually give me any useful information. That is, even if I see the name of the company in the certificate, I don't have a reason to trust them more than I would trust a phisher because I have absolutely no sideband interactions with them to begin with.
Bluntly, the refusal of a certain part of the security community to simply secure transport first and then worry about authentication on top of that is both frustrating and mind-boggling.
This sounds a lot like the thinking that brought us the TSA. Do something, anything!
He's asking to decorrelate the authentication problem with the encryption problem, because at the moment the main problem is that to get encryption (without a big ugly warning), you basically also need to pay a CA for authentication.
I really don't see your point with TSA, we're not talking about security theater here.
I have a blog. No ycombinatorer has any idea who I am or whether I'm trustworthy, so a verification from a CA that I am who I claim I am isn't particularly helpful to either of us if I link here.
Since you don't know who I am to begin with, presumably you wouldn't trust me with any greater information than you would give to a phisher, since even with a CA-signed certificate I might have nefarious purposes. But with encryption you would at least know that whoever you are in fact communicating with actually sent the message you received and not something else.
It's genuinely puzzling to me that so many people obtusely claim there's no value there.
If I'm reading your blog, why am I going to "trust" you with any "information" at all? You shouldn't need to prove your identity to publish a blog, and if you need either positive identity, non-repudiation, or encryption, then you need something that 99.999% of your fellow bloggers don't.
So to me, the whole thing sounds like a red herring, or rather a Trojan horse for the imposed removal of anonymity from the Web. No one has articulated just what problem is being solved here, but plenty of people have articulated the downside.
Considering that's something we can't do at the moment with http I hardly think it's important. If nothing else, using https means purely passive attacks aren't possible. Active attacks are much easier for devices to spot by looking for key changes, too.
No, but check out how XKCD is presented at the moment. It doesn't look like it's secure or insecure, it looks like http. I would happily read webcomics over a self-signed certificate if it was made easy for me.
We don't need identity verification on many sites, being resistant to passive eavesdroppers or transient active attackers (such as sites that present different SSL certs when accessed from a public wifi) is a nice to have as they prevent some attacks rather than none.
So you would be OK with your ISP adding popover flash video ads to XKCD for you? Or your boss calling you in, asking why you are reading comics instead of doing useful work?
No, I'm not okay with it, which is why I'm so against the near ubiquity of http which suffers from this exact problem on most mobile networks and many free wifi networks. The things you describe are not only possible but widespread.
By requiring a perfect solution to auth and ident (rather than iterative improvements) you are part of the problem.
Unidentified but authenticated connections should not be penalised compared to unauthenticated and unidentified connections. If someone MITMs a TLS connection with a forged certificate they can indeed do all the things that are trivial already with bog-standard http. If a client records TLS keys of sites they've already visited there is partial mitigation of this attack.
This doesn't have to have any effect of the CA scam business model, although obviously I would be in favour of a combination of key pinning and some sort of hand-wavey consensus determination for initial pins of arbitrary sites, but the fact that people are being forced to pay in order than browsers won't prefer plain-text over end-to-end encryption is absurd.
HTTPS sure does hide the URL's you are hitting. It may leak the domain name, and you are also resolving DNS entries in the clear, but there's a difference between the Wikipedia entry on puppies and on something more nefarious.
Feel free to stop with the strawman attacks at any point.
That said, I would prefer comcast ad injection to someone running firesheep. And hiding which comics I looked at for two hours isn't going to help my job very much.
You looked at a position saying it wasn't important, gmail or bank level important, to secure webcomics. You then argued that position was completely okay with having webcomic visits altered. That's a strawman.
I am not sure where you are getting this from, though it is very probably I wasn't completely clear. To clarify:
I believe all content (banks, GMail, XKCD) should be served over HTTPS and protected by a trusted certificate. Self-signed certs are not trusted and should not be (the problem of "should GMail give me a self-signed cert?" cannot be solved; you need some type of external trust).
Notice, I am not saying trusted and signed by a CA. We can replace the trust model and do something different to fix the currently broken CA system. However, I never argued and am not arguing that some content is OK to be served over plain HTTP.
You're going to end up with similar issues to key-signing, maybe we could have certificate exchange parties or a friend-of-a-friend network passing on certificates from trusted parties.
Right now a certificate doesn't mean much anyway, there is hardly any difference between accepting a self-signed certificate or one that has been issued by any one of the CAs for security purposes, it's mostly a feeling, nobody went there to check who ordered the certificate.
All it says is that someone paid someone else some money.
A self-signed cert says "I claim to be example.com", while a signed cert says "I claim to be example.com and I previously convinced someone else that I was example.com, too."
It's certainly not perfect, but it is a much bigger hurdle for a mitm attacker to get past.
But it's just wrong to conflate these two things. Security of transport and authenticity of parties are two separate questions and should be treated as such. Particularly since conflating them essentially says "anonymous secure transport will not be possible".
Anonymous secure transport is fundamentally not possible. If you don't know who you're talking to, you may be talking to a MITM.
It's possible to have pseudonymous secure transport, if you identify sites with key-based pseudonymous identities rather than some form of authenticated identity, but you have to have some notion of identity or you don't have a secure transport at all.
That remains a silly claim no matter how many times it's repeated. All that is required for secure transport is a two key pairs. I need not have any idea who the other party is, but I can be certain that I have received exactly what that party transmitted and that no other party could read it in transit (remember, even the sender can't recover the original plaintext in this case if he's lost it).
It's pretty basic cryptographic theory and I'm not sure how such a fundamental misunderstanding became so widespread. A secure channel need not tell me anything about the probity of the other participant. (In basic terms, even if I'm being phished, there's an advantage in keeping some other criminal syndicate from also reading my information.)
"But you don't know with whom you are actually communicating to begin with!" you may say. Agreed, and not cared about. I'm communicating with someone. Step 1 is to make sure that whoever that person is, she and I share a secure communication channel that no other person can alter or intercept. At that point she and I can negotiate authenticity. Solve the simple problem first, and the harder problem becomes easier.
"Secure" against what threat model? If your threat model is a passive eavesdropper that simply reads the contents on the wire, but cannot actively change things or impersonate as another hostname, it will be secure.
While this attacker is too weak for most security use cases, it will cover many forms of passive mass surveillance by ISPs and governments, so it is quite valuable in that sense.
Tor puts quite a lot of effort into authenticating part of the infrastructure, why do you think they do not? And Tor isn't providing a "secure" transport, they're trying to provide a "mixed" transport to hide you among others. If you were the only Tor user (or facing a big enough foe) and Tor did no authentication, then those random encryption hops could get hijacked easy enough since a fake directory could get published right to you, and you'd happily encrypt each hop with a MITM key.
If you're in a position to MITM a TLS connection, you can most likely also alter those signatures for your target.
You would need to use something like DNSSEC as well, relying on a government-controlled PKI [1], which isn't really any better than the current situation.
The current situation is that everyone in the Starbucks can completely monitor all of your plaintext. Self-signed, encrypted, unauthenticated connections are better than plaintext connections.
