Hacker News Reader

Comment by jwr | Hacker News Reader

How about we solve the "certificate" situation first?

I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct).

I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert.

If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.

View on HN

But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course.

(Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)

The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only.

There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.

Alternately, you do have that problem with SSH, and you work around it by scratching your head, saying "oh, right, because I switched hosts/reinstalled the OS/ran that mysterious command," and then nuking the key entry.

Alas, this does not scale well into the HTTP realm.

What about trusting not the key itself, but the CA which signed the cert - whose cert came within the cert chain upplied by the server ? Then everyone could get their own "root" CA and renew the certificates to their heart's content.

Lol, took me a minute to get the sarcasm.

The problem is it requires knowledgable, involved users if the private key ever needs to change. If I suddenly get an SSH key error on a company server, I can just ask the sysadmin if it's legit. That wouldn't really work on sites intended for the general public - users would just click "ok" on every error or they'd be scared off.

Although I think it could work great on sites intended for small numbers of clueful users. (Web-based admin consoles, etc.) But something else is needed to make HTTPS usable by average people.

Oh, certainly. I agree completely with everything you said.

But right now, the situation is that I go to arstechnica.com, which offers no encryption whatsoever, and Firefox just loads it up like nothing's wrong.

Yet I go to self-signed.example.com, and Firefox presents me with a giant warning screen, followed by a pop-open warning dialog, where I have to click to confirm the security exemption, add the certificate in, and OK another scary prompt. It's so over the top that laymen probably think proceeding will give that site complete interception control over every site they ever go to again in the future.

That's absolutely ridiculous. Worst case, self-signed should be treated like HTTP is now. No padlock, no green address bar.

People who are knowledgeable and able to confirm self-signed certs should be able to very quickly and very easily do so. This will greatly help with developing inside the local network, or for small communities that know what they're doing and don't want to pay hundreds of dollars for wildcard SSL certs.

This.

A self-signed certificate is significantly better than no encryption whatsoever (even if you're being phished, you at least now know that no other phisher has viewed or altered the response in transit), but browsers for reasons that defy explanation treat them like they're worse.

There was even an MTA (exim maybe?) that on seeing an untrusted certificate would actually downgrade to plaintext in some circumstances. Great job, guys; you really dodged a bullet there...

If all a domain-validation SSL cert means is that the certificate issuer could reach you via admin/administrator@domain.com - that's nearly all they do, besides ask for some payment information - why not automate that part of the process?

That is, the certificate presented by the site should be signed in a fashion that proves that whoever signed it owns the domain.

How do we know you own the domain? Because you control the DNS. If you control the DNS, you can control the domain in so many ways, including receiving the DV email, so it seems like a proper way to verify it.

If you control DNS, you can set a TXT record and put a public key in it.

So why not have browsers actually just ensure that a certificate is signed by the public key stored in DNS? Is there a good reason not to do this?

Might just be because you need DNSSec for that technique to be viable (otherwise an attacker could just spoof the DNS response too) and that hasn't been widely available until recently. Offhand it sounds like a pretty good approach now.

Point is, this is what we do now. We do this without DNSSEC. The step of receiving the email is pretty much redundant and is only there because people understand email better than creating a TXT record.

DNSSEC is a terrible ide and should be abandoned for many reasons. So should this method of domain validation. You know who knows for sure that you own the domain you say you own? The registrar. That is who should issue you your cert, not some third party.

This is called DANE described in RFC 6698. But it requires DNSSEC. Without DNSSEC, the visitor to the site can be easily be MITM'd by spoofing DNS. It is presumably more secure when a CA verifies an email (or DNS) because the CA can control their DNS servers and be reasonably sure their DNS is not spoofed. Random clients internet clients can't without DNSSEC.

How do you check the difference between your self-signed cert for your site and my self-signed cert for your site?

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.

or someone is going to stuff the signature in DNS like we seem to do for a lot of other items (e.g. SPF, DKIM)

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.

[1]: http://sockpuppet.org/blog/2015/01/15/against-dnssec/

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.

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".

Guess it sucks when reality gets itself conflated. You cannot have "security of transport" (encryption?) without authentication.

Repeating that over and over does not make that true. Or have I just been imagining the existence of Tor, etc.?

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.

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.

This might help:

http://www.coniks.org/

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.

But would you use gmail.com over plain HTTP? Would you use it if it presented a self-signed cert?

You know gmail.com is one of the domains with known invalid certs signed by browser-supported CAs in the wild, right?

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?

Generally you trust your ISP slightly more than strangers sitting near you.

No version of HTTPS has ever hidden what site you were visiting.

Really? http://arstechnica.com/tech-policy/2014/09/why-comcasts-java... doesn't bother you?

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.

No strawman here. I would prefer that nobody but the origin host can deliver content as the origin host.

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.

No version of HTTPS has ever hidden what site you were visiting.

Eh? That's why SNI was invented, because pre-SNI https did not send the hostname in plaintext.

SNI wasn't put in to leak information.

The server sends the hostname in plaintext when it sends the certificate.

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.

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.

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.

Bingo.

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.

I sure care. If my browser starts to accept YOUR self-signed certificate for gmail.com, we're back at http.

we're back at http

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.

You can get normal certificates for free these days and wildcard certs don't cost significant amounts of money.

At startssl you can get unlimited amounts of wildcard certs for 60 $. I know startssl isn't that popular and partly that's justified.

In summer hopefully let's encrypt will start and make it even easier to get certs for free.

Or in other words: People are working on solving the certificate situation - and even now it is not as bad as you make it sound.

Agreed. Enforcing SSL on the entire web will just mean a lot of very sloppy and bad SSL. Better to just make it abundantly clear when traffic is insecure, because that's a problem you'll have to solve whether you force SSL or not.

Let's Encrypt is scheduled to launch in mid-2015, so by later this year, the procedure to get a proper certificate will be something like:

    sudo apt-get install lets-encrypt

    lets-encrypt example.com

https://letsencrypt.org/howitworks/

How about we solve both these problems and stop quibbling about which one we should solve first, given that they both need to be solved?

I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound. Trusting CNNIC, no DNSSEC, etc show that Mozilla and Google aren't taking this very seriously. It's more a dog and pony show at this point with encryption.

Plus I'm still cognizant of the bullet I dodged by not having OpenSSL on my server back when Heartbleed hit.

> I'd rather not spend hundreds on a wildcard cert, or thousands on an EV cert, plus the costs in setting it up, until I'm sure the model is actually sound.

I'm 100% sure the model isn't sound.

I'm also 100% sure that a model which includes unencrypted HTTP will never be sound. The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists.

Chicken, meet egg.

It's really not a chicken/egg problem. We solve the easy problem first, then the hard one. I'm not yet sure there's actually a good solution to the cert problem.

There is one solution I can think of, but it involves equating URLs with identities via a Namecoin-like system, and that technology just isn't there yet.

No. It's only chicken and egg because we needlessly conflated two very distinct problems a few decades ago.

Problem 1: isolate the communication between myself and whatever other party is actually sending me a message. Easily solved by encryption. (You're being MITM'd? That sucks. But you have now at least isolated the communication to you and the attacker. The problem domain just shrunk quite a bit.)

Problem 2: verify that the other party is who she claims to be. Not easy to solve but a completely separate problem from Problem 1.

We could solve Problem 1 tomorrow (modulo the time it takes to upgrade every browser/mail client/etc.) by simply encrypting all traffic, period, and not doing any authentication whatsoever. We would then be exactly where we are right now in terms of having a PKI system with all of its advantages and faults, but we would then have the amazing bonus feature of preventing all passive attacks, period.

> The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists.

Sure it is. Whether or not HTTP exists has zero bearing on solutions to the cert problem; the cert problem is independent of the unencrypted problem (whereas the unencrypted problem is dependent on the cert problem, since the cert problem is precisely why the unencrypted problem currently exists).

It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place.

Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.

No, that's not a good idea, there are lots of cases where the static page being sent to you contains secret information, and should yell loudly when the source can't be verified. Secret information that you don't want to be intercepted or modified by an attacker.

Sure, but there are also plenty of cases where you don't care. Why make everyone everywhere bother with HTTPS? If you want to protect the user, as a browser, go ahead and yell or block access, but only when the user's data is at risk. Blocking access to my page because someone might have misrepresented what I put there, and thus forcing me to deal with HTTPS? That's more than a little excessive IMO.

Even on a static page you want to be sure that what you see is what the server sent. Without any third party injecting anything.

That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.

> Even on a static page you want to be sure that what you see is what the server sent.

So have a PGP signature of the page available and the browser can check it.

> HTTPS provides not only encryption, but also authenticatoin.

And this is the problem. Those are two separate issues and should be handled separately.

Yessiree, Bob, those are my cat pictures, and here's the 1024-bit key to prove it.

That's what subresource integrity[1] is for. Links will have a secure hash of the content they link to. So you don't have to secure page assets such as pictures, CSS, Javascript, fonts, etc - just the entry pages for a site. This cuts the need for encrypted traffic way down.

This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys.

[1] http://www.w3.org/TR/SRI/

> HTTPS provides not only encryption, but also authenticatoin.

Comments like that are a reinforcement of an increasingly-common point: that HTTPS shouldn't be conflating those two things, since doing so is resulting in a lot of pain whenever these sorts of suggestions to encrypt all web traffic come up.

All I want is a way to set up an encrypted connection without caring about it being authenticated, thus offering at least basic protection against random passerbys at Starbucks. Let me do that without having to buy a certificate from some schmuck who was arbitrarily trusted by a bunch of browsers (without any actual guarantee of trustworthiness, mind you; just an empty pinky promise that they won't be naughty).

There have been cases of ISPs injecting ads into the websites customers visit.

http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...

This should be treated as a legal problem, not a technological one.

> the padlock icon really isn't any more secure than a self-signed cert.

I understand this comes from a frustration, and an understanding that the certificate based authentication is not perfect. But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for.

So as long as no practical and better solution for server authentication has been found, this is the best we have and it is still working pretty well (you don't see a lot of rogue certificates in the wild).

> But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for.

It's perfectly called for. The CA system is based on arbitrary trust. An actually-effective system should not rely on trust at all.

Even something like what Namecoin does - using a Bitcoin-style blockchain as a public ledger, but for SSL certs instead of DNS entries - would be a massive step in the right direction in comparison to the current CA system.

It's not entirely arbitrary. Some CAs may actually be worthy of trust. I imagine it would be possible to modify the browser's UI to reflect the trustworthiness of the server certificate to encourage better diligence on their part.

> Some CAs may actually be worthy of trust.

By what measure? Some empty promises of good security practices, perhaps? Or maybe some pinky swear that they'll always act in the best interests of the internet as a whole rather than in the interests of whichever government or set of shareholders happens to be in a position of power relative to them?

Basically: name one.

But self-signed certificates are more secure than CA-signed certificates, because they don't involve a third party. My various servers only use self-signed certificates among themselves because it drastically reduces the amount of initial trust required.

The huge problem there is key distribution (easy since I run all the servers), but in terms of just "security" that's much more secure than involving a third party CA.

Self signed is one thing in an internal environment/infrastructure role but quite another in a web server interacting with the public role. You're comparing apples to oranges.

"Internal" begs the question of key management, which is the whole issue to begin with. At any rate, my claim stands that a self-signed certificate is by nature more secure than a CA-signed one, because it does not require the additional level of trust in the CA.

It's only more secure between two parties that can reliably confirm their identities with each other out of band. A CA, however badly implemented in practice, is more secure by design because the worst case scenario (a subverted CA) is no different from a self-signed certificate from a client perspective.

In terms of what you're focusing on in this thread (verification of identity) I don't disagree. But a MitM attack on coffee shop wifi is a problem which is exacerbated by self signed certificates.

You make a good point. This might be more of a UI issue: perhaps self-signed certificates could use a different browser icon that lets people know traffic is encrypted, but the identity of the site is not verified. Use a large "E" in the icon?

I don't mind at all visiting someone's personal site that has a self signed certificate but a UI change to avoid the glaring waring dialog would be nice.

There are large advantages of having almost all traffic encrypted.

This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.

I wonder if web-of-trust SSL is the right way to solve this.

On its own, probably not; web-of-trust is one of those things about PGP that was awesome on paper, but in practice ended up being a significant pain point.

A cryptographic ledger, on the other hand (think Namecoin), would probably be at least slightly more effective; it would effectively confer the same benefits (decentralized registration authority) without the logistical nightmare of a web-of-trust.

Well-stated. You are not the only one.

Reply on news.ycombinator.com