4 ms·

Am I the only one who thinks the way we deal with certificates is just completely backwards? Why should there even be a CA at all for DV certs? We already have

by MertsA 9y ago

Am I the only one who thinks the way we deal with certificates is just completely backwards? Why should there even be a CA at all for DV certs? We already have to trust the registrar as ultimately they can get whatever DV certs they want so why not just limit our trust to them instead of adding hundreds of additional organizations that can compromise our security? And we pay them for the privilege of doing this?? I get CAs for EV and OV certs, of course you need an additional trusted party there, but the vast majority of websites out there do not use EV or OV certs and to be fair users by and large don't even notice the difference between a DV and an EV certificate in the first place. We already have DNS, we already trust DNS to issue certificates to people, why don't we just cut out the middle man since they serve no additional purpose?

BillinghamJ 9y ago
This is the idea behind DANE :) https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... Effectively, you’d serve a self-signed certificate, then use DNSSEC to state that the origin can use the self-signed cert. Then clients can use that without showing warnings. However, it does rely on DNSSEC not being a total failure, so not likely to end up in widespread use anytime soon unfortunately. Also, given the more recent growth of alternative solutions to the problems DANE solves, like Let’s Encrypt and CAA DNS records, I’m not sure we’re likely to see much more work being done on it sadly.
technion 9y ago
The thing is that "control of the DNS" can mean different things. I have control of the DNS on my network, and at the local coffee shop. I can use that to attack users, but I cannot use that to obtain a certificate. I still agree with you in a sense, an alternate solution would be great. But we that middleman is the best we have right now.
- josteink 9y ago
  > The thing is that "control of the DNS" can mean different things. In every way this discussion is related, "control of the DNS" should mean control of the one authoritative DNS source, in a way which means that if a service across the internet requests a DNS record, it won't be affected by whatever DNS-trick your neighbourhood cafe's wifi may apply. Trying to muddle the discussion of a fairly straight-forward, reliable scenario with consumer-space DNS resolution is IMO not very productive.
  - icebraining 9y ago
    But that's the point - the CA is needed to make a reliable verification of the data coming from the authoritative DNS source, since the consumer can't make that check themselves in an untrusted network.
  - technion 9y ago
    The discussion directly relates to a user typing google.com and knowing, via https, that they are talking to Google. The CA preventing the local DNS trick is entirely relevant.
- ams6110 9y ago
  So if I fix my DNS to 8.8.8.8 (or other well-known public DNS) does that not largely squash the coffee-shop attack vector?
  - technion 9y ago
    I could spoof the gateway and forward 8.8.8.8 to my own machine with my own rules.
- MertsA 9y ago
  I mean strictly in the sense that we already have root servers pointing to TLDs pointing to individual domains all the way down. I'm not suggesting DANE in particular here I'm suggesting trust one "Super CA" that signs a "sub CA" for a TLD that signs another sub CA for the domain which can keep doing the same thing. Basically just chain each CA together but all of the sub CAs would be further and further constrained such that .ly couldn't sign certs for .com and ycombinator.com could only sign certs for subdomains of ycombinator.com. In essence, we already trust the registrars to link a name to an entity, DV certs are just going to defer the judgement to the registrar so why bother trusting an additional entity to issue certs for every domain instead of just having the registrar sign your CA that can only issue for your domain and only until your domain expires. Right now AFAIK I can technically get a SSL cert for a domain I control and have it expire well past when the domain expired and was transferred to another party. I now have a valid certificate for a domain that I don't own.
josteink 9y ago
> but the vast majority of websites out there do not use EV or OV certs and to be fair users by and large don't even notice the difference between a DV and an EV certificate in the first place. You could also say the same for HTTP vs HTTPS (except HTTPS being considerably slower on unreliable networks). So what's the value add in forcing everyone (even those who don't want to and have no need) to use HTTPS?
- tialaramex 9y ago
  The "no need" case is pretty thin. People seriously underestimate how little you are promised in the plaintext HTTP scenario over a potentially hostile network (ie almost any network) Everything you say, or the site says, can be read and changed by any third party between you on the network and there'd be no sign they did so, no trace left. That's almost never what you actually wanted, so, why should we keep allowing indeed arguably encouraging this practice?
ams6110 9y ago
> Am I the only one who thinks the way we deal with certificates is just completely backwards? No. https://www.tedunangst.com/flak/post/moving-to-https https://www.tedunangst.com/flak/post/moving-to-https

by MertsA 9y ago

BillinghamJ 9y ago

This is the idea behind DANE :) https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... Effectively, you’d serve a self-signed certificate, then use DNSSEC to state that the origin can use the self-signed cert. Then clients can use that without showing warnings. However, it does rely on DNSSEC not being a total failure, so not likely to end up in widespread use anytime soon unfortunately. Also, given the more recent growth of alternative solutions to the problems DANE solves, like Let’s Encrypt and CAA DNS records, I’m not sure we’re likely to see much more work being done on it sadly.

technion 9y ago

The thing is that "control of the DNS" can mean different things. I have control of the DNS on my network, and at the local coffee shop. I can use that to attack users, but I cannot use that to obtain a certificate. I still agree with you in a sense, an alternate solution would be great. But we that middleman is the best we have right now.

josteink 9y ago
> The thing is that "control of the DNS" can mean different things. In every way this discussion is related, "control of the DNS" should mean control of the one authoritative DNS source, in a way which means that if a service across the internet requests a DNS record, it won't be affected by whatever DNS-trick your neighbourhood cafe's wifi may apply. Trying to muddle the discussion of a fairly straight-forward, reliable scenario with consumer-space DNS resolution is IMO not very productive.
- icebraining 9y ago
  But that's the point - the CA is needed to make a reliable verification of the data coming from the authoritative DNS source, since the consumer can't make that check themselves in an untrusted network.
- technion 9y ago
  The discussion directly relates to a user typing google.com and knowing, via https, that they are talking to Google. The CA preventing the local DNS trick is entirely relevant.
ams6110 9y ago
So if I fix my DNS to 8.8.8.8 (or other well-known public DNS) does that not largely squash the coffee-shop attack vector?
- technion 9y ago
  I could spoof the gateway and forward 8.8.8.8 to my own machine with my own rules.
MertsA 9y ago
I mean strictly in the sense that we already have root servers pointing to TLDs pointing to individual domains all the way down. I'm not suggesting DANE in particular here I'm suggesting trust one "Super CA" that signs a "sub CA" for a TLD that signs another sub CA for the domain which can keep doing the same thing. Basically just chain each CA together but all of the sub CAs would be further and further constrained such that .ly couldn't sign certs for .com and ycombinator.com could only sign certs for subdomains of ycombinator.com. In essence, we already trust the registrars to link a name to an entity, DV certs are just going to defer the judgement to the registrar so why bother trusting an additional entity to issue certs for every domain instead of just having the registrar sign your CA that can only issue for your domain and only until your domain expires. Right now AFAIK I can technically get a SSL cert for a domain I control and have it expire well past when the domain expired and was transferred to another party. I now have a valid certificate for a domain that I don't own.

josteink 9y ago

> but the vast majority of websites out there do not use EV or OV certs and to be fair users by and large don't even notice the difference between a DV and an EV certificate in the first place. You could also say the same for HTTP vs HTTPS (except HTTPS being considerably slower on unreliable networks). So what's the value add in forcing everyone (even those who don't want to and have no need) to use HTTPS?

tialaramex 9y ago
The "no need" case is pretty thin. People seriously underestimate how little you are promised in the plaintext HTTP scenario over a potentially hostile network (ie almost any network) Everything you say, or the site says, can be read and changed by any third party between you on the network and there'd be no sign they did so, no trace left. That's almost never what you actually wanted, so, why should we keep allowing indeed arguably encouraging this practice?

ams6110 9y ago

> Am I the only one who thinks the way we deal with certificates is just completely backwards? No. https://www.tedunangst.com/flak/post/moving-to-https https://www.tedunangst.com/flak/post/moving-to-https