27 ms·

HSTS for new TLDs

85 points by tomkwok 12y ago

ejr 12y ago
I wish there was an alternative to the CA system we have now. I'm part of a private forum with a self-signed cert and while initially there was some hesitation to it, most members have added it to their browser exceptions.
- psz 12y ago
  There is a proposed solution for this scenario: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... It will allow for pinning certificates (self-signed too) to records in in DNS with DNSSEC.
  - ejr 12y ago
    That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.
  - mike-cardwell 12y ago
    If you're using a resolver which supports DNSSEC, and you're using Firefox with the DNSSEC-Validator addon from https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ (which supports DANE) and you visit https://grepular.com/ https://grepular.com/, you will see a nice little green icon in the address bar to show you that DNSSEC was used, and another green icon to show you that the SSL cert was validated using DANE.
  - y0ghur7_xxx 12y ago
    DNSSEC still relays on CAs. They were just renamed to "Trust Anchors". The trust anchor for .com is Verisign.
    - kilburn 12y ago
      > DNSSEC still relays on CAs. No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records. > They were just renamed to "Trust Anchors". You are thinking about DANE [1], which is what the a protocol on top of DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain domains. This allows you to restrict your domain to a specific well-known CA (such as Verisign), but it also allows you to authorize your own CA or even a specific certificate directly. It even works per-service, so you do not need to use the same CA/certificates for all your services. If you were suggesting that DANE does not solve the traditional CA issue you are wrong. [1] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 > The trust anchor for .com is Verisign. Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records...
      - 0x0 12y ago
        >> The trust anchor for .com is Verisign. >Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records... Verisign runs the "com." zone, so I guess they would have to admin any DNSSEC/DANE/TLSA stuff.
        kilburn 12y ago
        They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider). The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.
        schoen 12y ago
        That last property is what makes that entity a "trust anchor", and what DANE critics specifically don't like or want to get rid of.
        tptacek 12y ago
- csandreasen 12y ago
  Moxie Marlinspike created an alternative to the CA system called Convergence[1]. His DEFCON video[2] does a good job describing the problem and his proposed solution. There's a Firefox plugin for it, but Chrome has come out and said they will likely never support it[3]. [1] http://convergence.io/ http://convergence.io/ [2] https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ (you can skip the first 5 minutes; if you want to jump straight to his proposed solution, it's around 35 minutes in) [3] http://www.theregister.co.uk/2011/09/08/google_chrome_rejects_convergence/ http://www.theregister.co.uk/2011/09/08/google_chrome_reject...
- higherpurpose 12y ago
  There are alternatives - as long as you're willing to give up on regular DNS domains and use .dns or .bit domains: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain http://www.freespeechme.org/ http://www.freespeechme.org/
- gerbal 12y ago
  The university I work for uses Self-signed certs for everything but ssl. Apparently setting up properly signed certs is too expensive. And it's more effective to have the IT staff spend an inordinate amount of time convincing end-users that the warnings about invalid certs from various applications are nothing to worry about (I'm looking at you Andoid and OSX).
  - 13throwaway 12y ago
    Are you being sarcastic or do you really think they are nothing to worry about? If people just accept any cert they see anyone could just mitm them with a self signed cert.
    - gerbal 12y ago
      I'm being sarcastic. Also some departments use different self-signed certs than the university at large. Not a great situation.
  - anaphor 12y ago
    Couldn't they distribute the signatures to the faculty and students in some semi-secure way?
emehrkay 12y ago
"I can't speak for Firefox and Safari but I think it's safe to assume that Firefox" Maybe one of these Firefoxes should say Chrome
- cdh 12y ago
  It is a bit confusing, but I'm not sure that this is actually an error. It sounds like he may be in a position to directly make that change to Chrome, but is trying to clarify that his thoughts on Firefox and Safari are his, and he can't speak on their behalf. When you read it that way, it makes sense.
  - schoen 12y ago
    What's more, Firefox previously adopted a related thing that agl invented (HSTS preloads in general), so he has personal experience of their being amenable to this sort of thing.
- tptacek 12y ago
  The Chrome SSL team works very closely with that of Firefox.
  - iancarroll 12y ago
    not to mention Firefox pretty much uses the HSTS preload list that Chrome does.
diafygi 12y ago
I'm confused on the implementation of something like this. HSTS is an HTTP header, so it is up to the HTTP server, not the DNS server. How is HSTS enforced at the domain layer?
- evilpie 12y ago
  Chrome and Firefox both have a preloaded list of sites that should always use HSTS. https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
  - bpatrianakos 12y ago
    Right but site owners need to request inclusion on that list only after they've enabled HSTS on the server. I've done this myself and I must say I'd be pretty angry if browsers forced an entire TLD to require HSTS. The result would be SSL warnings everywhere.
    - tptacek 12y ago
      That's why he's suggesting that the new TLDs do this, to start early, so that everyone's expectations are set properly.
    - iancarroll 12y ago
      A preload does not require the header to be set. It would obviously be the smart thing to do, but it's not required. HSTS is only a header.
      - rgbrenner 12y ago
        A preload does not require the header to be set. did you read evilpie's link? "Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list. ... We limit the list to hosts that send a large max-age under the assumption that these sites will not revert to non-HSTS status."
deleted 12y ago
[deleted]
- iancarroll 12y ago
  One, he is the person in charge of adding sites to the HSTS store. Two, he's asking TLD owners to talk to him, not saying "we're going to make this TLD require SSL".
dionyziz 12y ago
I'm surprised no one here is talking about Namecoin [1]. It has become obvious that the PKI system is failing, and the main issue is centralization. I don't know if Namecoin itself will be the solution, or some other blockchain-based method that achieves decentralization such as the more generic Ethereum [2], but as engineers we should be supportive of such systems, as they provide better security and true -not just delegated- domain name ownership. [1] http://namecoin.info/ http://namecoin.info/ [2] https://www.ethereum.org/ https://www.ethereum.org/
- M2Ys4U 12y ago
  >It has become obvious that the PKI system is failing, and the main issue is centralization. Actually, the problem is exactly the opposite. Any CA can sign a certificate for any domain. What compounds the problem with the CA system is that CA trust is sticky. When a new CA gets added to trust stores, they are effectively trusted for life. That's not how trust actually works. What we need is a system that is distributed and that allows for trust to be granted and - most importantly - revoked at will without causing collateral damage (i.e. for innocent sites that end up using a bad CA). Moxie Marlinspike's convergence[0] was a great idea, but it's never really taken off. TACK[1], also by Marlinspike, looks like nice feature to help transition away from the CA system when we come up with something better. [0] http://convergence.io/ http://convergence.io/ [1] http://tack.io/ http://tack.io/
reedloden 12y ago
This seems like a great idea for the new .trust gTLD [1] (formerly known as .secure), as they already want sites under it to be "secure". [1] https://www.nccgroupdomainservices.com/ https://www.nccgroupdomainservices.com/
santiagogo 12y ago
Good idea, especially for some tlds aimed at industries which rely on strong security like .bank. Will send the link to a couple of ngtld applicants.

85 points by tomkwok 12y ago

ejr 12y ago

I wish there was an alternative to the CA system we have now. I'm part of a private forum with a self-signed cert and while initially there was some hesitation to it, most members have added it to their browser exceptions.

psz 12y ago
There is a proposed solution for this scenario: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... It will allow for pinning certificates (self-signed too) to records in in DNS with DNSSEC.
- ejr 12y ago
  That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.
- mike-cardwell 12y ago
  If you're using a resolver which supports DNSSEC, and you're using Firefox with the DNSSEC-Validator addon from https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ (which supports DANE) and you visit https://grepular.com/ https://grepular.com/, you will see a nice little green icon in the address bar to show you that DNSSEC was used, and another green icon to show you that the SSL cert was validated using DANE.
- y0ghur7_xxx 12y ago
  DNSSEC still relays on CAs. They were just renamed to "Trust Anchors". The trust anchor for .com is Verisign.
  - kilburn 12y ago
    > DNSSEC still relays on CAs. No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records. > They were just renamed to "Trust Anchors". You are thinking about DANE [1], which is what the a protocol on top of DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain domains. This allows you to restrict your domain to a specific well-known CA (such as Verisign), but it also allows you to authorize your own CA or even a specific certificate directly. It even works per-service, so you do not need to use the same CA/certificates for all your services. If you were suggesting that DANE does not solve the traditional CA issue you are wrong. [1] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 > The trust anchor for .com is Verisign. Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records...
    - 0x0 12y ago
      >> The trust anchor for .com is Verisign. >Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records... Verisign runs the "com." zone, so I guess they would have to admin any DNSSEC/DANE/TLSA stuff.
      - kilburn 12y ago
        They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider). The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.
        schoen 12y ago
        That last property is what makes that entity a "trust anchor", and what DANE critics specifically don't like or want to get rid of.
        tptacek 12y ago
csandreasen 12y ago
Moxie Marlinspike created an alternative to the CA system called Convergence[1]. His DEFCON video[2] does a good job describing the problem and his proposed solution. There's a Firefox plugin for it, but Chrome has come out and said they will likely never support it[3]. [1] http://convergence.io/ http://convergence.io/ [2] https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ (you can skip the first 5 minutes; if you want to jump straight to his proposed solution, it's around 35 minutes in) [3] http://www.theregister.co.uk/2011/09/08/google_chrome_rejects_convergence/ http://www.theregister.co.uk/2011/09/08/google_chrome_reject...
higherpurpose 12y ago
There are alternatives - as long as you're willing to give up on regular DNS domains and use .dns or .bit domains: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain http://www.freespeechme.org/ http://www.freespeechme.org/
gerbal 12y ago
The university I work for uses Self-signed certs for everything but ssl. Apparently setting up properly signed certs is too expensive. And it's more effective to have the IT staff spend an inordinate amount of time convincing end-users that the warnings about invalid certs from various applications are nothing to worry about (I'm looking at you Andoid and OSX).
- 13throwaway 12y ago
  Are you being sarcastic or do you really think they are nothing to worry about? If people just accept any cert they see anyone could just mitm them with a self signed cert.
  - gerbal 12y ago
    I'm being sarcastic. Also some departments use different self-signed certs than the university at large. Not a great situation.
- anaphor 12y ago
  Couldn't they distribute the signatures to the faculty and students in some semi-secure way?

emehrkay 12y ago

"I can't speak for Firefox and Safari but I think it's safe to assume that Firefox" Maybe one of these Firefoxes should say Chrome

cdh 12y ago
It is a bit confusing, but I'm not sure that this is actually an error. It sounds like he may be in a position to directly make that change to Chrome, but is trying to clarify that his thoughts on Firefox and Safari are his, and he can't speak on their behalf. When you read it that way, it makes sense.
- schoen 12y ago
  What's more, Firefox previously adopted a related thing that agl invented (HSTS preloads in general), so he has personal experience of their being amenable to this sort of thing.
tptacek 12y ago
The Chrome SSL team works very closely with that of Firefox.
- iancarroll 12y ago
  not to mention Firefox pretty much uses the HSTS preload list that Chrome does.

diafygi 12y ago

I'm confused on the implementation of something like this. HSTS is an HTTP header, so it is up to the HTTP server, not the DNS server. How is HSTS enforced at the domain layer?

evilpie 12y ago
Chrome and Firefox both have a preloaded list of sites that should always use HSTS. https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
- bpatrianakos 12y ago
  Right but site owners need to request inclusion on that list only after they've enabled HSTS on the server. I've done this myself and I must say I'd be pretty angry if browsers forced an entire TLD to require HSTS. The result would be SSL warnings everywhere.
  - tptacek 12y ago
    That's why he's suggesting that the new TLDs do this, to start early, so that everyone's expectations are set properly.
  - iancarroll 12y ago
    A preload does not require the header to be set. It would obviously be the smart thing to do, but it's not required. HSTS is only a header.
    - rgbrenner 12y ago
      A preload does not require the header to be set. did you read evilpie's link? "Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list. ... We limit the list to hosts that send a large max-age under the assumption that these sites will not revert to non-HSTS status."

deleted 12y ago

[deleted]

iancarroll 12y ago
One, he is the person in charge of adding sites to the HSTS store. Two, he's asking TLD owners to talk to him, not saying "we're going to make this TLD require SSL".

dionyziz 12y ago

I'm surprised no one here is talking about Namecoin [1]. It has become obvious that the PKI system is failing, and the main issue is centralization. I don't know if Namecoin itself will be the solution, or some other blockchain-based method that achieves decentralization such as the more generic Ethereum [2], but as engineers we should be supportive of such systems, as they provide better security and true -not just delegated- domain name ownership. [1] http://namecoin.info/ http://namecoin.info/ [2] https://www.ethereum.org/ https://www.ethereum.org/

M2Ys4U 12y ago
>It has become obvious that the PKI system is failing, and the main issue is centralization. Actually, the problem is exactly the opposite. Any CA can sign a certificate for any domain. What compounds the problem with the CA system is that CA trust is sticky. When a new CA gets added to trust stores, they are effectively trusted for life. That's not how trust actually works. What we need is a system that is distributed and that allows for trust to be granted and - most importantly - revoked at will without causing collateral damage (i.e. for innocent sites that end up using a bad CA). Moxie Marlinspike's convergence[0] was a great idea, but it's never really taken off. TACK[1], also by Marlinspike, looks like nice feature to help transition away from the CA system when we come up with something better. [0] http://convergence.io/ http://convergence.io/ [1] http://tack.io/ http://tack.io/

reedloden 12y ago

This seems like a great idea for the new .trust gTLD [1] (formerly known as .secure), as they already want sites under it to be "secure". [1] https://www.nccgroupdomainservices.com/ https://www.nccgroupdomainservices.com/

santiagogo 12y ago

Good idea, especially for some tlds aimed at industries which rely on strong security like .bank. Will send the link to a couple of ngtld applicants.