Comment by nailer | Hacker News Reader

Comment by nailer | Hacker News Reader

Parent Full thread

This is domain validation (DV). A DV HTTPS/TLS cert doesn't make any assertions about a certificate representing any particular legal entity. Authentication is to a domain: you have an encrypted channel to whatever that domain is. Some CAs used to do extra checks for suspect domains on DV certs but they're not required and they don't scale for automated systems.

    openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
     OU=Domain Control Validated
     CN=example.com
     DNS:example.com

As opposed to EV which does. Authentication is to a legal entity, you have a encrypted channel to that legal entity:

  openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
    jurisdictionOfIncorporationCountryName=GB
    businessCategory=Private Organization
    serialNumber=09378892
    C=GB
    ST=City of London
    L=London
    O=example Limited
    CN=example.com
    DNS:example.com -

(Domains are also required to be reviewed by a human for EV)

Disclaimer: work for CertSimple, who only does EV certificates (which match a cert to a legal entity). Though I use DV for my personal site.

I would ask: if DV is an acceptable weaker alternative to EV then why do we need certificates at all? Why doesn't anyone allow HTTPS without a certificate- it would allow you to establish you are talking to the same server you thought you were 5 seconds ago. The reason, of course, is: that certificate-less HTTPS and DV are pretty much useless and huge net-negatives as they are confusing and imitate stronger certifications.

Why is DV useless? DV asserts that you are securely talking to whomever controls that domain. That's very valuable. If they're confusing, that's on the browsers.

Edit: You also cannot just discard certificates and use HTTPS as an "I'm talking to the same server I was 5 seconds ago", because that does literally nothing to prevent MitM attacks. If you can't assert that you're talking securely to the domain owner, then there's nothing at all stopping someone in a privileged network position from intercepting and altering your traffic, because they could simply proxy it through their own server.

This is the same argument as "self-signed certificates are useless". They aren't. Not all interception is MitM. With spy agencies operating passive taps on infrastructure, as a fraction of your intercepted traffic, virtually none of it us. Completely unsigned, unverified encryption is still a massive roadblock to dragnet surveillance.

>does literally nothing to prevent MitM attacks

It does more than nothing. Especially if you make the reasonable assumptions that 1) the user is not being MitMed most of the time and 2) the user is likely to have connected to the (small) set of sensitive sites before they experience their first MitM.

Example: my home internet is unadulterated. I check my mail. My computer saves the certificate. I go to a coffee shop. I check my mail again. Somone tries to MitM me. My computer instantly spots a changed certificate.

Obviously we should still use and verify certificates. But I notice a nasty trend of making the perfect the enemy of the good in security. There's a perception that if it's not perfect, it's worse than useless and should be shunned (probably due to historical bad experiences with false senses of security).

Your computer can't simply remember the certificate that was used for the last connection, because then sites can never change their certificates (which would be a huge issue).

Moxie mentioned before that using notaries would work, of course you have to worry about notaries being compromised but that's a much easier threat model.

https://en.wikipedia.org/wiki/Convergence_(SSL)

They could, for example, sign the new cert with the old one.

What if the certificate's private key is compromised? How would revocation work?

I think the parent post is saying that you'd know that you're talking to the "same server" in a very literal sense (ie. if you were MITM'd, you'd know you're talking to the same server that MITM'd you the entire session).

Not exactly sure what that'd buy...

We need certificates because network traffic can be redirected. For example, once you've saved a bookmark to https://example.com, the certificate ensures that clicking on the link connects you to a server that has the private key for example.com.

That's worth something. But as the article points out, it doesn't help if you started out with the wrong domain name. (How do you get the bookmark in the first place?)

DV is better than no certificate because it guarantees no one is MITMing just you. It could hypothetically be possible an attacker MITMed both the CA and you, but that's quite hard.

EV has the security benefit over DV in that you can use HPKP to pin EV CA public keys, so no DV certificates will ever be trusted for your site.

> It could hypothetically be possible an attacker MITMed both the CA and you, but that's quite hard.

This statement does not make sense. Could you explain what you are implying here?

I assume what's meant is that the CA could be MitM'd during the domain ownership verification process, thus issuing a certificate for the attacker, which the attacker can then use to MitM you.

Presumably, MitM'ing the CA's traffic to the domain owner is significantly harder than MitM'ing a random user, though certainly not impossible.

I do not see how that would be possible.

Anything from cache poisoning of the CA's DNS server, BGP hijacking or pwning any network hop between the CA and the victim would be sufficient. Domain validation is nothing but a DNS query or a HTTP request.

Wouldn't DV validate that your DNS resolved correctly, which non-certificate methods dont?

Not only that, it also guarantees there's no MITM.

HTTPS without certs means you are talking securely to your attacker :-)

It doesn't guarantee that, not without an explicit out-of-band certificate statement such as DANE. It only guarantees that the MitM you're talking to has gone through the additional trouble of getting an "official" certificate for the site you're trying to connect to.

Getting this "official" certificate is in principle impossible. Of course, in practice sometimes it is possible, but so would reasonably be attacks against DANE (if anyone were using it).

The use-case for proving integrity is different from the use-case for proving both integrity and identity, thus the UI should be different as well.

This attack should work on EV too. Register a company with PayPal in its name in some small country. There is no "avoid name conflicts between companies" system with as much reach as the Internet itself.

That's why the EV indicator includes the 2-letter country code. "PayPal, Inc. [RO]" would be displayed instead of "PayPal, Inc. [US]".

Would you notice? There's so much crap in company suffixes, I probably wouldn't.

This attack also requires the user to ignore the suffix.

That's a good point. Browsers could definitely have better UI to highlight this information to users.

I'd support using flags or full names rather than country codes here, they're much more distinct.

Then browsers don't need to accept EVs from small countries that don't adhere to a certain level of common decency.

Do any of the browsers try to differentiate EV and DV?

Yes. This website has a DV cert, so in Firefox it has the green lock icon but nothing else. By contrast, if you go to twitter.com, which has an EV cert, you'll see "Twitter, Inc. (US)" in green text next to the lock icon, because that's the legal entity that the EV cert was issued for.

I think Chrome used to do this too, but it doesn't for me right now; I'm not sure why.

Reply on news.ycombinator.com