17 ms·

Certified Malice

107 points by andygambles 10y ago

nailer 10y ago
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.
- jmount 10y ago
  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.
  - eridius 10y ago
    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.
    - BoorishBears 10y ago
      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...
    - dTal 10y ago
      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).
      - eridius 10y ago
        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).
        dijit 10y ago
        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) https://en.wikipedia.org/wiki/Convergence_(SSL)
        10y ago
  - SomeStupidPoint 10y ago
    Wouldn't DV validate that your DNS resolved correctly, which non-certificate methods dont?
    - gcp 10y ago
      Not only that, it also guarantees there's no MITM. HTTPS without certs means you are talking securely to your attacker :-)
      - tremon 10y ago
        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.
        gcp 10y ago
        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).
  - skybrian 10y ago
    We need certificates because network traffic can be redirected. For example, once you've saved a bookmark to https://example.com 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?)
  - Buge 10y ago
    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.
    - willstrafach 10y ago
      > 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?
      - pfg 10y ago
        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.
        willstrafach 10y ago
        I do not see how that would be possible.
        pfg 10y ago
        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.
- matthewbauer 10y ago
  Do any of the browsers try to differentiate EV and DV?
  - ameliaquining 10y ago
    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.
- andreareina 10y ago
  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.
  - closeparen 10y ago
    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.
    - bravura 10y ago
      Then browsers don't need to accept EVs from small countries that don't adhere to a certain level of common decency.
    - tonyztan 10y ago
      That's why the EV indicator includes the 2-letter country code. "PayPal, Inc. [RO]" would be displayed instead of "PayPal, Inc. [US]".
      - closeparen 10y ago
        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.
        nailer 10y ago
        I'd support using flags or full names rather than country codes here, they're much more distinct.
        tonyztan 10y ago
        That's a good point. Browsers could definitely have better UI to highlight this information to users.
djyaz1200 10y ago
Definitely an issue. Chrome has already changed the SSL indicator to just read "secure" rather than naming the cert.
- duskwuff 10y ago
  Not that I'm aware of. Still displays the verified identity name for sites using EV certificates, like https://paypal.com/ https://paypal.com/ ("PayPal, Inc. [US]").
  - eridius 10y ago
    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.
    - duskwuff 10y ago
      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.
      - eridius 10y ago
        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.
pokemon-trainer 10y ago
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.
- gcp 10y ago
  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?
  - pokemon-trainer 10y ago
    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?
    - Buge 10y ago
      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?
  - caf 10y ago
    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.
- n0w 10y ago
  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" https://www.paypal.com.safe.com" looks pretty similar to "https://www.paypal.com" 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.
dethswatch 10y ago
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.
- gcp 10y ago
  stupid desire to incorporate identity along with encryption. It's not a stupid desire. Encryption is pretty useless without authentication.
  - SomeStupidPoint 10y ago
    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.
  - ubernostrum 10y ago
    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?
    - eridius 10y ago
      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.
tonyztan 10y ago
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.
- GrinningFool 10y ago
  We don't - but most of the rest of the browsing public doesn't know the difference.
  - eridius 10y ago
    That's why it's up to the browser to distinguish them.
    - GrinningFool 10y ago
      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
      - eridius 10y ago
        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.
rini17 10y ago
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...
- wmf 10y ago
  How is that different from DV certs?
tinus_hn 10y ago
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.
- gcp 10y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=1236431 https://bugzilla.mozilla.org/show_bug.cgi?id=1236431 https://bugzilla.mozilla.org/show_bug.cgi?id=1271998 https://bugzilla.mozilla.org/show_bug.cgi?id=1271998
jwatte 10y ago
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...
- gcp 10y ago
  So we ban paypalsucks.com?
hartator 10y ago
> 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.
- marvy 10y ago
  > 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.
hamilyon2 10y ago
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

107 points by andygambles 10y ago

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.

jmount 10y ago
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.
- eridius 10y ago
  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.
  - BoorishBears 10y ago
    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...
  - dTal 10y ago
    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).
    - eridius 10y ago
      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).
      - dijit 10y ago
        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) https://en.wikipedia.org/wiki/Convergence_(SSL)
      - 10y ago
- SomeStupidPoint 10y ago
  Wouldn't DV validate that your DNS resolved correctly, which non-certificate methods dont?
  - gcp 10y ago
    Not only that, it also guarantees there's no MITM. HTTPS without certs means you are talking securely to your attacker :-)
    - tremon 10y ago
      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.
      - gcp 10y ago
        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).
- skybrian 10y ago
  We need certificates because network traffic can be redirected. For example, once you've saved a bookmark to https://example.com 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?)
- Buge 10y ago
  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.
  - willstrafach 10y ago
    > 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?
    - pfg 10y ago
      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.
      - willstrafach 10y ago
        I do not see how that would be possible.
        pfg 10y ago
        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.
matthewbauer 10y ago
Do any of the browsers try to differentiate EV and DV?
- ameliaquining 10y ago
  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.
andreareina 10y ago
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.
- closeparen 10y ago
  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.
  - bravura 10y ago
    Then browsers don't need to accept EVs from small countries that don't adhere to a certain level of common decency.
  - tonyztan 10y ago
    That's why the EV indicator includes the 2-letter country code. "PayPal, Inc. [RO]" would be displayed instead of "PayPal, Inc. [US]".
    - closeparen 10y ago
      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.
      - nailer 10y ago
        I'd support using flags or full names rather than country codes here, they're much more distinct.
      - tonyztan 10y ago
        That's a good point. Browsers could definitely have better UI to highlight this information to users.

djyaz1200 10y ago

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

duskwuff 10y ago
Not that I'm aware of. Still displays the verified identity name for sites using EV certificates, like https://paypal.com/ https://paypal.com/ ("PayPal, Inc. [US]").
- eridius 10y ago
  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.
  - duskwuff 10y ago
    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.
    - eridius 10y ago
      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.

pokemon-trainer 10y ago

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.

gcp 10y ago
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?
- pokemon-trainer 10y ago
  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?
  - Buge 10y ago
    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?
- caf 10y ago
  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.
n0w 10y ago
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" https://www.paypal.com.safe.com" looks pretty similar to "https://www.paypal.com" 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.

dethswatch 10y ago

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.

gcp 10y ago
stupid desire to incorporate identity along with encryption. It's not a stupid desire. Encryption is pretty useless without authentication.
- SomeStupidPoint 10y ago
  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.
- ubernostrum 10y ago
  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?
  - eridius 10y ago
    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.

tonyztan 10y ago

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.

GrinningFool 10y ago
We don't - but most of the rest of the browsing public doesn't know the difference.
- eridius 10y ago
  That's why it's up to the browser to distinguish them.
  - GrinningFool 10y ago
    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
    - eridius 10y ago
      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.

rini17 10y ago

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

wmf 10y ago
How is that different from DV certs?

tinus_hn 10y ago

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.

gcp 10y ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1236431 https://bugzilla.mozilla.org/show_bug.cgi?id=1236431 https://bugzilla.mozilla.org/show_bug.cgi?id=1271998 https://bugzilla.mozilla.org/show_bug.cgi?id=1271998

jwatte 10y ago

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

gcp 10y ago
So we ban paypalsucks.com?

hartator 10y ago

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

marvy 10y ago
> 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.

hamilyon2 10y ago

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