Hacker News Reader

Comment by pilif | Hacker News Reader

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool"

no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".

Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.

Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server.

So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.

This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have.

The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

View on HN

The solution is something nobody hasn't quite come up with.

SSH has. It tells me:

WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future.

That model isn't perfect either but it is much preferable over the model that we currently have, which is: Blindly trust everyone who manages to exert control over any one of the 200+ "Certificate Authorities" that someone chose to bake into my browser.

...and then if the fingerprint changes, you get something like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

... and then you do rm .ssh/known_hosts and try again :P

ssh-keygen -f ~/.ssh/known_hosts -R 123.45.67.89

You have probably just saved me.. minutes of time over the course of a year!

But seriously thanks, I was going into the known_hosts file and manually deleting the offending line :)

If you get past the terrifying warning, it even gives you the command to copy and paste. You don't even have to type it!

Certificate Patrol can give you something like this for Firefox.

+1 for Certificate Patrol; used to use it until it got too annoying for me. Same with RequestPolicy; another great extension that is unfortunately a lot of work if you surf a lot, esp these days, when everything is hosting assets on CDNs.

I used to use EFF's SSL Observatory until I realized it spits out lots of extra http requests. X509 is inherently flawed/complex and adding a browser plugin to make it better feels wrong.

> SSH has.

IMHO no. We don't SSH to the same 46 servers everyday. But we do log into that many (or more) websites. Can you imagine the amount of homework users need to do in order for this to work?

Not to mention the amount of non-tech savvy users who just won't put up with it.

Quite the contrary: SSH's system means that you only have to "do your homework" when first connecting to the server. It seems I have 64 lines in my ~/.ssh/known_hosts (there are probably quite a few duplicates, because this seems high to me) and almost never have SSH tell me the key has changed and someone could be doing something nasty. When it does, I almost always know why, and when I don't then I try to contact the admin before connecting.

The way certificate authorities work though, you might visit your bank's "secure" website everyday, with its green padlock and company name displayed, but if one day a rogue authority or a compromised one issues a certificate to someone else, and your DNS resolves to a new server, your browser would not even tell you anything has changed and would happily display the green padlock like it always has.

In the current state of things, you have to do the homework yourself for every site you visit when using HTTPS, while you don't with SSH.

Or you can install Certificate Patrol (https://addons.mozilla.org/fr/firefox/addon/certificate-patr...). And then you'll cry at the amount of sites badly configured.

My browser also offers me to accept any self-signed certificate, I can investigate it and then I can accept it and it won't ever bother me again, until the certificate changes.

The problem is that this is a huge hassle for incidental visitors. Whereas SSH does not have incidental visitors. Same goes for email, if it's your own server, you know the cert to be the real one, and you can accept it, you're not bothered again.

So this is where we stand:

    Encrypted (Certified)    COOL GREEN
    Encrypted (Self-Signed)  EVIL RED
    Unencrypted              NOTHING / NEUTRAL CHROME

I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.

To know something is insecure can be acceptable. To think something is secure when it isn't can be far more dangerous. I'm considering secure to mean encrypted and identity reasonably verified. Whatever your thoughts on the CA process it serves a purpose.

There are plenty of other things to complain about. EV for one.

> Encrypted (Certified) COOL GREEN

I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.

> Encrypted (Self-Signed) EVIL RED

Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me.

> Unencrypted NOTHING / NEUTRAL CHROME

This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don't even have to think about this case.

Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA's. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain.

This is all castles in the sky, but IMO that's the correct solution.

I'm not sure you should completely cut off anyone else but your registrar from holding the power to grant you certs.

As long as you can transfer the domain out I guess it's not too bad.

What does it matter who issues your cert if your registrar controls your domain name? They can transfer your domain name to the FBI, your competitor, your ex-husband, whoever. They can keep it for themselves, and they can publish their own DNS servers as authoritative, making all traffic flow through them anyways. They already are in 100% control of your domain and you are at their mercy. You already trust them enough to buy the domain from them. Why would you want to give a third party that same level of access when you don't have to? The CA's would have you believe that they have tighter security than anyone else, so you should trust them. That's silly. Your registrar has more control over your domain than your CA, so either their security has to be just as good, or you are screwed anyways.

This article[0] is largely about DNSSEC and DANE but it might give you some insights why making registrars the sole authorities isn't such a good idea.

[0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

I may be dense but it seems to me that your registrar is still the trusted entity no matter what:

- they sell you the domain name. Doesn't matter how you try to authenticate yourself to clients (cert pinning aside), the registrar can seize the domain at any point.

- they control what your authoritative name servers are. They could easily change these on you.

- they populate the whois database, which is used when you purchase your TLS certs. This means that a registrar can list joe@fbi.gov as you the contact, and have Joe get a completely valid cert.

- one important issue that the article does not mention is that you are forever locked into trusting the site operator. This means that you as a user already must trust another entity.

This, what I am proposing is that out of the current trust list: [site owner, registrar. CA] we cut out the CA. Once again, the registrar always trumps the CA in their ability to seize your domain. At the same time, the CA provides zero protection against the registrar misbehaving. This article talks about shifting trust from the CA to the registrar and how that's bad. I posit that you already trust the registrar, forever (or as long as you are willing to use their TLD) so you would be strictly reducing the amount of entities you need to trust, never adding new ones.

> This case should be eliminated. We need to stop publishing stuff over HTTP. Period.

HTTP is perfectly fine for information originating on and never leaving controlled, trusted, internal networks, and there is no reason to pay the overhead for HTTPS for those cases.

There's other use cases where its probably not worth the (small) overhead for HTTPS.

No it is not. I have talked about this on here before, but I don't mind repeating myself:

- Your small blog you publish over HTTP is now opening the door for me, the attacker to mess with any traffic originating from your site. Say you host your resume on your site. I can substitute it with a much less flattering version. Say you host a code snippet. I can add a little obfuscated fork bomb or root kit at the end. Say you have a referral link to Amazon. I send your users to amazom.com, a site that's MitM'ing amazon.com but captures credit card details on the payment form.

- Your internal corporate system is great an all, until you have an unrelated breach and the HTTP site becomes a vector for me to attack your systems. Or worse yet, I learn how to trick your users into believing they are accessing your genuine document store when in fact they are uploading their secret company plans to my very own rogue site. Trust inside the electrified fence is different than on the Internet, but a self-signed cert that your IT sends to every employee is also pretty easy. Conversely, if your organization is so large that it's impractical, just buy a $10 domain and a $8 TLS cert. The "overhead" you speak of does not exist when your server side stops supporting HTTP. FFS, configuring nginx to use TLS/HTTPS takes exactly 3 additional lines of configuration code as compared to an HTTP-only site.

> I can substitute/add/send...

Only if you control any of the infrastructure. If you do, then you can make my life a misery anyway, encrypted or not.

Authenticated and encrypted? That throws a wrench into things.

The authentication provided by the extant PKI system is much weaker than the encryption provided. Any CA can do anything it wants, and browsers trust lots of them.

What's worse is that there has already been at least one case of an ISP rewriting links to Amazon for all of their customers. https://news.ycombinator.com/item?id=6992897

There's also significant overhead to the community at large in having both HTTP and HTTPS be reasonable systems to use, and requiring that HTTP not show loud warnings. There's also a risk to your organization that you're teaching users that some HTTP sites are reasonable, which is a hard judgment for them to make. I can put up an external website which claims to be internal, and probably get some passwords or confidential information that way.

If you use HTTPS everywhere, there is a tiny bit (but usually negligible) runtime overhead, a bit of process overhead (which this announcement is pushing much closer to zero), and significant simplicity in many other axes. I think the tradeoff leans towards publishing internal sites with globally-valid HTTPS certificates.

The registrar issuing cert solution would certainly speed up HTTPS adoption; you're dealing with one less org to secure your site. The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee? Or what about revoking the previous cert? Now the registrar is functioning as a de facto CA so it doesn't completely eliminate the middle-man factor.

I'm hoping the EFF project will smooth over these hiccups, which is why I'm looking forward to it.

> The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee?

Then everyone stops using that registrar and they go out of business.

> Or what about revoking the previous cert?

You're asking this as if there is some kind of functioning method of revoking certificates already. If anything this makes it easier because it could be plausible for clients to somehow retrieve who the registrar is for the domain and then only accept certificates signed by that registrar.

If the popularity of GoDaddy has taught me anything, it's that people use what they know; not what's good. The list of companies that should have gone out of business is as long as the number of years since commerce began.

The fact that they still stay means (and this is relevant to the EFF project as well), creating alternatives is just as hard as making enough people know and care about them.

The registrar check per domain is probably the biggest plus in having it act as CA. Of course, that adds overhead to the registrar which they may not be willing to accept (margins and all that).

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

There is such a thing -- name constraints. It allows exactly what you describe, limiting the valid names for certificates signed by the certificate.

Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...

You mention that the revocation-check problem is old, which is certainly true, but I think you allude to the possibility that a domain-registry-based hierarchy will exacerbate that problem in the form of an increase in revocation checks. I'm not sure that would be the case; it should be about the same. What difference does it make if I owned a domain, got a cert from a CA, and stopped owning the domain -- vs -- got that cert from my registrar? If anything this helps the process, because my registrar knows when I stop owning the domain whereas a CA has no clue and relies on the cert's expiration date exclusively.

I guess you're right - I was considering the fact that someone once owned a domain was a threat, but it is already.

But with a delegated chain of certs, the problem does get worse - not least because you'd require individual domains to manage their own certificate revocation.

But since there's basically no secure way to obtain CRLs or perform OCSP cert validation, it's kind of moot.

I think this is kind of backwards? I.e. a CA that implements name constraints for one of its sub-CAs does limit the certs that sub-CA may sign. However, name constraints do not allow one to say "for this domain, only this sub-CA may sign certs", which is more what I feel we're looking for here?

Name constraints don't work [1] [2]. It's a nice thought, though :-/

[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... [2] http://middleware.internet2.edu/pki06/proceedings/chadwick-n...

> There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

As currently implemented this is mostly correct. I don't think the CAs want that situation to change, but it really harms the usability of the entire system.

This is the problem that pinning is intended to solve.

>> Encrypted (Certified) COOL GREEN

> I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.

Maybe. I just checked my browser and it already trusts more than 100 certificate authorities from all around the world, including some companies that I don't trust, some governments that I don't trust, but mainly composed of organisations I've never heard of. Even in a good system, there would occasionally be leaks etc, but this mess of promiscuous trust is clearly insane.

The problem here is that getting a vetted cert - or worse, compromising the authority that vets those certs is relatively trivial for a nation state, or even someone that's morally compromised enough to say, kidnap the CA Director's family. The fact is, trust is easily compromised and the current infrastructure needs to be hardened against that.

Even if the browser only had a single authority you do trust... how easy would it be for someone to force them to do something to compromise your trust? For instance with an NSL bound with a gag order?

> Even if the browser only had a single authority you do trust... how easy would it be for someone to force them to do something to compromise your trust? For instance with an NSL bound with a gag order?

By having several authorities you do trust? Preferably in different jurisdictions and parts of the world. But only those who you do trust.

>We need to stop publishing stuff over HTTP. Period.

This is a short sighted solution. If you go this route, then you are constraining authentication to the client. Users always choose bad passwords, so we are stuck.

In mobile networks, you have the network in a position to strongly authenticate the subscriber, without necessitating the weaknesses that can come with bad passwords.

I generally agree that TLS is desirable, but if we go all in, there are interesting and potentially more desirable alternatives that are lost.

FWIW, this is the route we are already going with HTTP/2: as implemented SPDY pretty much requires encryption.

Also, while mobile networks can authenticate my mobile phone and the hops from my phone to their edge router can be "trusted" (don't forget that the NSA is snooping here), I want end to end encryption. I want to know that the only two entities able to send/receive data are the site I'm trying to talk to and myself.

Let's think about it this way: in 2014 I propose a new protocol and implementation where you run a program on your device and I push arbitrary code to it. I also include code from advertisers, partners, third party affiliates, and my buddy Dave. All of this is done over clear text with no authentication, no authorization, no proof of identity or ownership, and over unsecured networks. Here's the link to the installer :) Yeah, I wouldn't sign up for that either.

I understand your argument. Barring some of the hyperbole of your worst case scenario, I totally get it.

In my opinion the rationality of your perspective is one of the most damaging consequences of the NSA's behavior.

Attacking the client is easy for both hackers and nation states. Moving the control to infrastructure tends to cut out whole swaths of script kiddies. There are important scenarios where this makes a ton of sense (m2m, iot, many mobile apps) and those assholes have just burned everyone's trust to the point that nascent solutions are no longer viable.

I am not quite sure what you are saying. Is it that it is in fact better to allow HTTP to exist vs providing HTTPS backed by some type of trusted infrastructure? Or is it that you are saying that we can build a brand new from scratch solution and need to fix the existing system somehow?

It's better to allow http to exist.

There is an opportunity for new authentication approaches that can't exist in a TLS-everywhere world.

I'm looking at http://en.wikipedia.org/wiki/Generic_Bootstrapping_Architect... in particular.

It's actually more like this:

    Encrypted (Certified)    EVERYTHING'S FINE
    Encrypted (Self-Signed)  OMG!!!
    Unencrypted              EVERYTHING'S FINE (while it's not)

It's definitely an antipattern. It's hard to solve until we get HTTPS deployable everywhere, because the first browser to defect from this antipattern will lose all its users, so it's extremely important to push on HTTPS being deployable and deployed everywhere.

Authentication and encryption are fundamentally separate ideas, and the problem here is that the CA system mixes them together, when an optimal solution (read: encryption everywhere) would be to tackle them separately.

    Encrypted (Certified)    AUTHENTICATED & ENCRYPTED
    Encrypted (Self-Signed)  NOT AUTHENTICATED & ENCRYPTED
    Unencrypted              NOT AUTHENTICATED & NOT ENCRYPTED

Doing financial work or communicating with friends/coworkers? Make sure you're connection is authenticated and encrypted.

Connecting to a blog? Encryption is a plus (and is the topic of this very HN post). But unencrypted is also okay.

The original CA system was not designed to defend against mass surveillance so it had little incentive to separate these concerns.

> It's just the best that we currently have.

No, I wouldn't say so. Having SSL is better than having nothing pretty much on any site. But if you don't want to pay $200 somebody for nothing, you would probably consider using http by default on your site, because it just looks "safer" to the user that knows nothing about cryptography because of how browsers behave. Which is nonsense. It's worse than nothing.

And CA are not "authorities" at all. They could lie to you, they could be compromised. Of course, the fact that this certificate has been confirmed by "somebody" makes it a little more reliable than if it never was confirmed by anyone at all, but these "somebodies", CA, don't have any control over the situation, it's just some guys that came up with idea to make money like that early enough. You are as good CA as Symantec is, you can just start selling certificates and it would be the same — except, well, you are just some guy, so browsers wouldn't accept these certificates so it's worth nothing. It's all just about trust, and I'm not sure I trust Symantec more than I trust you. (And I don't mean I actually trust you, by the way.)

For everyone else it's not really about SSL, security and CAs, it's just about how popular browsers behave.

So, no, monopolies existing for the reason they are allowed to do something are never good. Only if they do it for free.

> And CA are not "authorities" at all. They could lie to you, they could be compromised.

Actually just read their terms of service, which may as well be summarised as "we issue certificates for entertainment purposes only".

There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc).

There are certainly other options too: here's my suggestion-

The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it.

Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people.

It's basically what we do for ssh connections to new hosts.

The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to.

I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed on them.

With SSH you usually own both endpoints (or at least trusting your cloud provider).

The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.

I'm putting my eggs on certificate pinning.

How would you rotate keys with that scheme?

You'd need a strong root key and subkeys that rotate underneath. To change the root key would require signing by the original root and a new message to appear for confirmation.

All this plus something like a notary system to double check all your trusted root keys, would be much better than the hierarchical CA system we have.

Which root keys? The ones you store on your web server, which just got compromised?

Why would one store them there? Why not just use them to sign other keys that are actually used in online systems?

No, the question is what to do when you need to rotate them. Because that need will arise somewhere, globally, if we were to run the secure web on trust-on-first-use.

It's not interesting why someone hypothetically did get their root keys compromised, it's interesting how the proposed system would cope with it.

(Downvoting the question is not really a web scale way to build a global trust system.)

You're (almost) describing certificate pinning. Have a look at http://tack.io although it appears down for the moment. Here is the HN thread: https://news.ycombinator.com/item?id=4010711

"Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private."

This is misguided thinking, pure and simple. Because of this line of thinking, your everyday webmaster has been convinced that encrypting data on a regular basis is more trouble than it's worth and allowed NSA (or the Chinese or the Iranian or what have you) authorities to simply put in a tap to slurp the entire internet without even going through the trouble of targeting and impersonating. Basically, this is the thinking that has enabled dragnet surveillance of the internet with such ease.

but as user I can understand that an http site is insecure, while a self signed certificate might lead me into a false sense of security.

That's the proffered reasoning as we all know. But the actual outcome (to quote rufb from this comment https://news.ycombinator.com/item?id=8625739)

    Encrypted (Certified)    COOL GREEN
    Encrypted (Self-Signed)  EVIL RED
    Unencrypted              NOTHING / NEUTRAL CHROME

 Tell me how the logic works here (for an average user).

I can self-sign a certificate for gmail, the browser correctly warns about potential BIG security issues with it.

Not considering the many holes, cyphersuites, running TLS 1.3+ etc.

( http://wingolog.org/archives/2014/10/17/ffs-ssl )

...it should probably look like this:

Safe against active attacks:

    Encrypted (Certified)    COOL GREEN

Safe against passive attacks:

    Encrypted (Self-Signed)  SCARY ORANGE

Safe against world peace, ie. UNSAFE:

    Unencrypted              EVIL RED

> Tell me how the logic works here (for an average user).

"Neutral Chrome" is the default state of the web -- the site doesn't assert that it should be trusted, and it shouldn't be, and that's the default state people should have in approaching the web.

"Cool Green" is "the site asserts that it has a particular identity and that communication with that identified site is private, and it passes the tests built into the browser's security model to verify all that."

"Evil Red" is "the site asserts that it has a particular identity and that communication with that identified site is private, but it fails the tests built into the browser's security model to verify all that."

Seems to me to be perfectly logical, even if we might prefer a better security model for making and verifying the claims at issue.

Plaintext is zero security.

Self-signed is a low probability of security.

Signed is a high probability of security.

This continuum makes more sense than the current state of affairs.

If someone forwards plaintext, it's called a proxy.

If someone forwards encrypted content on behalf of my server, it's called man-in-the-middle attack, and they should not be capable of doing it without the huge red flags.

Self-signed is a significant probability of man-in-the-middle attack.

> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".

That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default.

FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...

The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.

They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate.

PS. nice (presumably political) downvote further up ...

One would hope certificate transparency would help fix this problem.

(for the record, I didn't downvote you)

The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business.

So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA.

For lesser sites and narrow targets, this may not be true.

This is precisely the problem with centralized security authorities. As we've seen a state actor can easily force a central authority to share it's private key, thereby granting the state actor the ability to untraceably create it's own certificate chains.

It would also have to control the wire for the attack target, but via wire tapping laws that is already a solved problem. Because they control the connection of the attack target, I don't see how the fact that the certificate chain was compromised would ever become public knowledge.

Web of trust was designed to address the central authority weakness, but itself apparently has scalability issues, although I'm unclear on why.

Google is indeed in a (unique) good position to detect and possibly prevent a fake certificate, but we don't know if that's what they want or whether they can be coerced to cooperate. Millions of other websites are not protected in the same way.

Fake certificate for Google wouldn't work in Chrome at least. There is certificate pinning already.

That is completely ineffective if they get Google to cooperate and issue an update that pins the new cert - and due to how automatic updates work, the majority of users will be completely oblivious, and those who do notice the new certificate won't find it any more suspicious than any other certificate update.

NSA has NSL (national security letters with gag orders). There are CAs in the US. Mission accomplished.

Wouldn't help with google though - anybody who tried to fake a google cert would be caught by chrome within a few seconds. There is a lot of value associated with owning a browser. Enhanced security is just one of them.

You speak as if the power of NSLs has a functional limit - it doesn't, which is what makes the entire concept so dangerous.

There's nothing stopping the requirements from being "mint us a certificate according to these specs" and additionally "okay, now pin this certificate in your browser".

You might want to read up on what an NSL actually is, since you and the GP are clearly very confused.

It's a letter, issued by an occult kangaroo court, that coup d'etat forces hold in hand while demanding the keys to the kingdom - a demand that can't be challenged in a legitimate court of law.

Explain, please.

What prevents an NSL from compelling Google from minting a new certificate (they are a CA), providing the keys to the bad guys, and distributing that certificate in Chrome? NSLs have been used in the past to compel positive action (c.f. Lavabit), so I really don't see how you think there's any practical limit to their power.

My understanding is that there isn't a limit. If I am wrong about this, then kindly reply directly here so we can all learn instead of giving the "read up on" non-answer.

An NSL can be used only to compel release of connection or transaction metadata, and cannot be used to compel disclosure of message contents. It's basically a fast-track for getting things like call records, and it most emphatically cannot be used to compel turning over a certificate or allowing a man-in-the-middle.

To my knowledge the exact details of the Lavabit case were never released, but from what has been released it's quite clear that the issue was regarding a warrant and a gag order, because the ensuing litigation wouldn't have been remotely applicable to an NSL (otherwise Lavabit's attorney would have won on a walk).

None of this is to say that I think NSLs should exist. In fact, I think they're a terrible idea. But the vast majority of discussions around them and similar topics is so grossly uninformed that it's impossible to take most people seriously on these subjects.

Okay, so not an NSL. Incorrect terminology pointing at the same awful effect, an unaccountable court issuing unchallengeable rulings that cannot be discussed.

No substantial difference from the concept I'm complaining about.

"Ignorance more frequently begets confidence than does knowledge."

I'm now curious. Explain to me how an NSL fits into the scenario you're implying.

That would be stupid. Google is a US company. NSA has NSLs. Mission accomplished. No certs involved.

How did you get Google into all this? If you're implying that Google owns a search site/Gmail/a browser, know that there are alternatives, which NSA's target could be using. A fake certificate from a trusted US CA can MITM any connection to almost any website from almost any browser.

That should have been a reply to the sibling comment, where it was implied this would be a strategy against Google.

I agree. A more common MITM, and that it actually would prevent, comes from a rogue wifi operator.

> FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...

And it's only going to get worse as SHA-1 become more and more affordable to crack.

The CAs have agreed to stop using SHA-1 by 2016, and Let's Encrypt will launch with something stronger on day one.

But SHA-1 attacks are going to be a huge problem all over our protocol stack :(

Browsers shouldn't silently accept self-signed, but there is a class of servers where self-signed is the best we've got: connecting to embedded devices. If I want to talk to the new printer or fridge I got over the web, they have no way of establishing trust besides Tacking my first request to them.

Oh god, they have internet fridges now? What on earth for?

http://en.wikipedia.org/wiki/Internet_refrigerator

Technically, there's no reason why a fridge couldn't have a signed cert tied to some dynamic DNS (e.g. <fridge-serial-number>.<manufacturer>.<tld>).

But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.

Allow the cert to be configurable, then the company can use its internal CA to give certs to all its appliances.

Yes, that's the status quo, and has been for a while. The point is that's currently the best you can do. For boxes without external exposure, this work won't change anything, but a standardized protocol for dealing with boxes with external exposure would still help some use cases.

True, but on many small networks, you aren't addressing the embedded device by a FQDN.

All these appliances should let you change the cert on them, but you still need that initial connection, and at smaller organizations (or households) the certs will never ever be changed.

I used to work on embedded security projects so I care about this; I also realize that's a small portion of the market. I'm okay with making the people connecting to their new printer jump through a hoop in order to reduce the chances of someone hijacking www.paypal.comm but you still have to allow some way in.

True, but on many small networks, you aren't addressing the embedded device by a FQDN.

Why not?

NAT traversal?

FQDN doesn't have to mean publicly accessible. I have a personal subdomain that points to an internal IP. It's kinda weird to do with IPv4, but it works fine, and with IPv6 it'll be natural, since each device will probably have a globally unique address anyway, even if it can't be accessed outside of your LAN.

Why should my fridge have a FQD name? What purpose does that serve?

Why install a firewall in each device if you can install one on the router that works for everything?

Why should my fridge have a FQD name? What purpose does that serve?

To allow you to create a signed certificate to authenticate it?

Why install a firewall in each device if you can install one on the router that works for everything?

Having an FQDN doesn't mean you need to install a firewall on your device. You can still use the router's, and even prevent any inbound connections from the WAN to the device.

I bought a camera the other day with the nifty feature of having an NFC tag embedded in it to guide your phone to launching (and installing, if necessary) the companion mobile app.

It occurred to me that this is a really good way of establishing a trust path: while they're only using it to guide you to the right app, they could embed a little public key in there. Then you could authenticate the new printer or fridge by physically being near it.

We'd have to extend our UIs a bit to cover these use cases (it should basically act like a trusted self-signed cert), and probably you only want to trust NFC certs for *.local.

>So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

Maybe a security-conscious person thinks that, but the typical user does not knowingly choose http over https, and thus the danger of MitM and (unaccepted) snooping is at least as large for the former.

So it's somewhat debatable why we'd warn users that "hey, someone might be reading this and impersonating the site" for self-signed https but not http.

The use case for the CA system is to prevent conventional criminal activity -- not state-level spying or lawful intercept. The $200 is just a paper trail that links the website to either a purchase transaction or some sort of communication detail.

The self-signed cert risk has nothing to do with the NSA... if it's your cert or a known cert, you add it to the trust store, otherwise, you don't.

Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network".

It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to nail all the office doors open and require you to sign a form in triplicate that you are aware the door is not completely soundproof before you are allowed to close it to make a phone call. (Or jump through a long registration process to have someone come and install a heavy steel soundproofed door which will require replacement every 12 months.)

After all, if you're closing the door, it's clearly meant to be private. And if we can't guarantee complete security against sound leaks to people holding their ear to a glass on the other side, surely you mustn't be allowed to have a door.

The person next to you in cafe can MITM a self-signed TLS connection just as easily as the NSA; and the NSA can probably MITM a CA-signed TLS session, since the U.S. government owns or has access to quite a few root certificates. So, "no self-signed certs" is really a measure to protect you from the lowest level of threat. Almost any attacker than can MITM http can MITM https with self-signed certs that you never verify in any way. Encryption without authentication is useless in communications.

Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.

The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.

CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.

This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.

Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session.

If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.

You don't need a CA system to solve that problem, though. Take, for example, Convergence[0] which uses a notary system in place of the CA system.

[0] http://convergence.io

But when you browse over http, you don't know who you're talking to either, so how are self-signed certificates worse than http?

I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.

Security-wise, if they are both vulnerable to trivial exploits, how can you say one is "more secure" than another?

How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)?

How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) they clearly notice but that b) doesn't annoy you when you connect to www.myblog.com which also is presenting a self-signed cert?

If the user typed www.mybank.com, let the server redirect to https but don't show the lock icon if it's self-signed. This is no worse than an impostor that just doesn't redirect to https.

If the user typed https://www.mybank.com, show the usual warning for self-signed certificates.

This is EXACTLY what I want for my intranet sites. It lets me protect my users from the wireshark in the next cubicle.

But that don't protect you from a malicious user hijacking this domain in the next cubicle. Perhaps, if your switches are not properly configured , that the guy in the next cubicle ou do some arp spoofing and https://intranet.yourdomain would be served by a bogus server collecting passwords.

But your users won't notice the difference, because they are used to see the certificate warning on his browser.

The solution for this is to run your own CA internally and push out the cert to all the machines. (if you have byod stuff it makes it a little harder but you could still have an internal ca signing only a certain subdomain and get people ot install it)

How many people are careful to type "https" every time they visit a website? How many people pay close attention to the lock icon/color of the URL bar? This advice seems to ignore the existence of sslstrip [0] and related attacks, and the numerous countermeasures that have been designed to deal with this problem (e.g. HSTS).

[0] http://www.thoughtcrime.org/software/sslstrip/

You would have to simply install the certificate for the CA that signed the certificate. Self-signed just means that YOU are the CA.

How would a browser know that the fact that www.mybank.com doesn't use SSL at all is intended by the bank, or the result of a MITM attack? At the end of the day it all relies on the user seeing the (lack of) a padlock in his browser. So as long as you don't show a padlock (or a different kind of padlock) for www.mybank.com when the certificate is self signed, you're good.

No. Self-signed certificates are much worse because they bring a false sense of security.

A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766).

EDIT: You can downvote all you want but I'm still right.

Each time anyone repeats the "self-signed certificates are still better than HTTP plain text" lie is hurting everyone in the long run.

They're much worse, both for the users and from a security perspective. Self-signed certificates are evil unless you know exactly what you're doing and are in full control of both ends of the communication (in which case just trust it yourself and ignore the warnings).

The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats.

An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt:

http://www.tcpcrypt.org/

So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.

> With some browser behavior self-signed certs could make some users safer against some threats

How exactly? Did you read my linked comment?

As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart.

The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself.

In the age of WiFi, you can't dismiss active attacks.

EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views.

Even parent's Tcpcrypt link says it is vulnerable.

> By default Tcpcrypt is vulnerable to active attacks

> Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication.

How are you going to perform authentication via insecure channels without CAs?

Well, the best example I know of is proposals to do opportunistic upgrades from HTTP to HTTPS, for example via a browser header in the HTTP reply. If the browser performs the opportunistic upgrade, and negotiates an HTTPS connection behind the scenes, and doesn't tell the user that the connection was served over HTTPS, then accepting a self-signed cert invisibly in this context makes the user no worse off than not performing the upgrade (and better off against an adversary who's not currently performing an active attack).

I forgot what the current status of drafts proposing this is. Amazingly, I found that Rohit Khare described a form of this mechanism way back in 1998 (so it's not a super-new concept).

Although such scheme is indeed safer than HTTP (protects against passive attacks), what you're describing is not self-signed certificates, but merely encryption (with new random _unathenticated_ keys per session).

Keys would be exchanged via Diffie-Hellman as usual, but a certificate wouldn't be involved since it's useless anyways (you can't certify anything in such a scheme, why bother at all?) and thus would be vulnerable to active attacks.

Certificates imply long-term authentication. It's an important nuance since they are long-lived by definition, so they have to be trusted and revoked as needed, in which case we're still facing the problem I mentioned earlier.

I agree that the certificates don't serve any useful function in this scenario; they might be required pro forma, but they aren't actually doing anything helpful.

> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate.

Trivial? Yes. As trivial as intercepting plain HTTP? No.

The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect), it's about increasing the cost to attackers.

https://news.ycombinator.com/item?id=8625420

HTTPS with self-signed certificates remains better than plain HTTP. The fact that you can propose an unimplemented, unstandardized, theoretical scheme that would offer the same advantages as HTTPS with self-signed certificates does not make HTTPS with self-signed certificates worse than plain HTTP.

Because encryption with SSL without trust of the SSL cert is meaningless. It might as well be not encrypted.

I wonder if this is true.

If there's a man in the middle, then they can read the traffic. But others still have a problem.

With HTTP, you know that everyone can read the traffic.

I think unsigned certs, especially with pinning, can be used to make wholesale collection of internet traffic vastly more difficult.

Now you are talking about obscurity, not security. In my opinion.

Reddit discussion about this, with much of the same arguments there as here (and talking past each other just as much):

http://www.reddit.com/r/ProgrammerHumor/comments/2l7ufn/alwa...

Here's one thing that's NOT the solution: throwing out all encryption entirely. Secure vs insecurse is a gradient. The information that you're now talking to the same entity as you were when you first viewed the site is valuable. For example it means that you can be sure that you're talking to the real site when you log in to it on a public wifi, provided you have visited that site before. In fact, I trust a site that's still the same entity as when I first visited it a whole lot more than a site with a new certificate signed by some random CA. In practice the security added by CAs is negligible, so it makes no sense to disable/enable encryption based on that.

Certificates don't even solve the problem they attempt to solve, because in practices there are too many weaknesses in the chain. When you first downloaded firefox/chrome, who knows that the NSA didn't tamper with the CA list? (not that they'd need to)

Moxie Marlinspike's Perspectives addon for Firefox was a good attempt to resolve some of the problems with self-signed certs.

Unfortunately, no browsers adopted the project, and it is no longer compatible with Firefox. There are a couple forks which are still in development, but they are pretty underdeveloped.

I wonder if Mozilla would be more likely to accept this kind of project into Firefox today, compared to ~4 years ago when it was first released, now that privacy and security may be more important topic to the users of the browser.

The solution, at least for something decentralized, seems to be a web of trust established by multiple other identities signing your public key with some assumption of assurance that they have a reasonable belief that your actual identity is in fact represented by that public key.

That's what PGP/GPG people seem to do, anyway.

Why can't I get my personally-generated cert signed by X other people who vouch for its authenticity?

Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities.

But I agree with the sentiment. :)

It's interesting that your boogeyman in the NSA and not scammers. I think scammers are 1000X more likely. Escpecially since the NSA can just see the decrypted traffic from behind the firewall. There's no technology solution for voluntarily leaving the backdoor open.

> or to NSA which

Nah. The NSA, or any adversary remotely approaching them in resources, has the ability to generate certificates that are on your browser's trust chain. Self-signed and unknown-CA warnings suggest that a much lower level attacker may be interfering.

Just a small nitpick: I'm pretty sure the NSA has access to a CA to make it look legit.

> The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

We do have a solution that does accept self-signed certificates. The remaining pieces need to be finished and the players need to come together though:

https://github.com/okTurtles/dnschain

If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight:

http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18...

Let's Encrypt seems like the right "next step", but we still need to address the man-in-the-middle problem with HTTPS, and that is something the blockchain will solve.

Reply on news.ycombinator.com