Hacker News Reader

Comment by rufb | Hacker News Reader

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.

View on HN

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

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.

It's actually more like this:

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

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

Reply on news.ycombinator.com