Certified Malice | Hacker News Reader

Certified Malice

textslashplain.com

107 pointsandygambles58 comments

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.

DV certificates are not meant to certify who operates a given site. They only certify that you are securely connected to the authorized server for the domain name, instead of being MITM-ed.

So, in effect, CAs issuing DV certs for websites, including phishing sites, is a feature, not a bug. If users are misinterpreting what a DV certificate means and doesn't mean, then it is up to browsers to make clear the difference between DV, OV, and EV.

A Domain-Validation certificate is just that. We shouldn't expect it to act like OV or EV.

We don't - but most of the rest of the browsing public doesn't know the difference.

That's why it's up to the browser to distinguish them.

The problem with that is that they haven't significantly done so yet - and people are well-trained to look for the green padlock to ensure the site is secure without much consideraton beyond that point.

So while I see your point, that's another transition that will take years to drill into public awareness - even if the browsers could agree on a meaningful and consistent representation, which seems like its own challenge

Safari has. There's no green on the address bar for a DV cert, just a little grey padlock. But with an EV cert you get the green text and the legal name (in addition to the domain). So that makes it easy - if there's green, you can trust it to tell you the legal entity that you're talking to.

The big reason that cert's are as unused as they have been for two decades is because of the stupid desire to incorporate identity along with encryption.

They've both useful- they've more useful together, and they're expensive and not used everywhere because of the identity problem.

This is just going to have to be accepted (for a while?) to get proper encryption.

Pointing out that this can happen is neither useful or news, and perpetuates this nonsense that's been holding us back.

stupid desire to incorporate identity along with encryption.

It's not a stupid desire. Encryption is pretty useless without authentication.

I think they mean lack of tying two notions of identity together: domain name and "real world" entity.

DV certs tie encryption to a purely digital identity while EV ties that identity to a real world identity as well.

The average blogger cares that their password is encrypted when logging in to their blog. They probably don't care very much whether someone can also verify their legal identity, and in fact quite a few bloggers probably explicitly don't want that.

The average banker, on the other hand, does care about the identity verification.

Why have we decided that everyone must have the banker's use case?

DV doesn't do legal identity. It does domain verification. And that's exactly what your blogger wants. A secure connection without domain verification means you can be trivially MitM'd.

So the browsers should show the right part of the domain name in the bar if the domain name doesn't fit, instead of the left part. Or perhaps not show it at all if it doesn't fit.

https://bugzilla.mozilla.org/show_bug.cgi?id=1236431

https://bugzilla.mozilla.org/show_bug.cgi?id=1271998

It's very unfortunate there isn't a way to force more responsibility/accountability onto CAs who issue phishing certificates.

Of course, the non-internet version of a CA, credit rating agencies, do not behave any better with the trust given to them by the public.

Maybe the creators of the Bitcoin alt coin "namecoin" had the right idea.

I don't believe it's reasonable to expect a CA to police the content of a domain that they have issued a certificate for.

As the original article points out, you can perform these kinds of attacks with any address by setting up sub domains ("https://www.paypal.com.safe.com" looks pretty similar to "https://www.paypal.com" to most users).

I personally think this is an issue with the browser UI/UX as it currently stands. "Secure" sends the wrong message to your average user. I would like to see something like the prominent display of the second/third level domain at the top of every browser tab (depending on the TLD). i.e. "ycombinator.com", "paypal.com", etc.

It's very unfortunate there isn't a way to force more responsibility/accountability onto CAs who issue phishing certificates.

It's very easy: get the browser vendors to remove them from the root store. It's exceedingly effective. The "problem" is that the browser vendors seem to agree that CAs shouldn't be content watchdogs.

Did you read the linked position paper from LetsEncrypt?

I think they're right - the CAs job (which they're not exactly nailing either) is to ensure that the browser is connected to the site it thinks it is. After that, it's the browser's job to ensure that the site it thinks it's connecting to and the site that the user thinks they're connecting to are the same.

That's very much a libertarian style nuclear option to remove a CA from the root store. Why can't the industry work out a fine to pay an ICANN-like org for root CAs when it happens?

A large percent of phishing sites are hacked wordpress sites.

So if a CA offers a certificate to a legitimate wordpress site, which then proceeds to let itself get hacked and host a phishing page, that CA now has to pay a fine?

I thought there was a plan to change browser ux to display DV https as simple white icon some time ago. Chrome and firefox. Unencrypted connections will show red icons and EV certificates will show as green. It makes sense in "encrypted by default" world

Google and others could easily look for domain names on the certificate transparency list and immediately add anything containing "PayPal" or "baidu" or whatever to the block list, until it can be checked manually.

In fact, the browser itself could do this...

So we ban paypalsucks.com?

1. Store the certificate directly in DNS, signed by DNSSEC

2. Have a way for user to easily and prominently display name or domain who is the certificate issued for, hardware button would be best IMO.

No participant in this CA racket has any interest for this to happen...

How is that different from DV certs?

> Users tend to be annoyed when you tell them only the truth– “This download was not reported as not safe.”.

First time that I am hearing users prefer a vague error explanation than truthful precise one.

And there is a silver bullet. Teach people - and most people already know it, don't assume people are idiots - how to recognize a domain name. Then the padlock. But, domaine names are infinte more important than padlocks. Always been the case and will likely never change in the near future.

> teach people how to recognize domain name

You say don't assume people are idiots. I agree, most are not. I will go further and say that, even among those who fall for these scam sites, most are not idiots (though the proportion is higher.)

But! You underestimate the scammers, and you underestimate the size of their toolkit. Sure, it's easy to look at an example like paypal.com.evil.com and think "I can teach users to read that properly". Maybe you can. But how about paypa1.com? And how about once we start playing games with Unicode? Can you tell a Latin lowercase A from the Cyrillic one? Are you going to teach users to copy and paste any suspicious URL into hex editor so as to make sure that its ASCII?

You're right about at least one thing: if you could get people to read domain names, that would be a silver bullet. And it's definitely possible to much better than now. But I worry that the scammers would simply up their game in response.

Definitely an issue. Chrome has already changed the SSL indicator to just read "secure" rather than naming the cert.

Not that I'm aware of. Still displays the verified identity name for sites using EV certificates, like https://paypal.com/ ("PayPal, Inc. [US]").

OP is talking about DV certificates. Showing the verified legal identity for EV certificates is correct behavior, otherwise there's not much point to having one.

If that's what they meant, I'm still confused. Chrome has never displayed a certificate name in the address bar for DV certificates -- the "Secure" text for DV certificates is completely new; older versions just displayed a lock icon there.

Chrome uses green for the DV lock, though, which is a bad idea. EV certs taught users that green means good, and then Chrome decided to use it for DV certs too. So users are taught that green is good, and when they go to a DV site they see green text and it says "Secure", so they think they're safe. This is absolutely terrible design on Google's part.

Reply on news.ycombinator.com