4 ms·

This is absolutely wonderful. DNS has long been an easy target for attackers, and its design has been nothing but painful to retrofit with better security mecha

This is absolutely wonderful. DNS has long been an easy target for attackers, and its design has been nothing but painful to retrofit with better security mechanisms the have led to incredibly low adoption (I'm looking at you DNSSEC) of better protections against forgery. Worse still, clients that believe themselves secure using HTTPS are essentially voiding their warranty by using UDP DNS. DNSCrypt, DoH, and DoT will hopefully change all of this, and I think it says something about Facebook that they're working with Cloudflare to protect their users from the dangers of DNS. Nicely done CF and FB.

petronio 8y ago
"Worse still, clients that believe themselves secure using HTTPS are essentially voiding their warranty by using UDP DNS." I wouldn't go that far. It's true that if the browser has never gone to a website before you can MITM to have the client connect to a server that doesn't support SSL and basically be left with a MITM'd HTTP connection. It's not fool-proof, but there's various measures that are being deployed to reduce such attacks: * Chrome has started adding "Not Secure" to proactively alert users of websites not using SSL. If a user sees a major website and "Not Secure" is visibly displayed, hopefully that'll serve as a good warning to not continue. * HSTS won't protect the initial connection, but will protect from future downgrade attacks by telling the browser to not accept insecure connections from the domain. * Unless it has been otherwise tampered with, the HTTPS connection will still be encrypted and the certificate verified regardless of whether DNS has been tampered with. At that point the attacker would need a valid certificate from a trusted CA for the domain, which is outside of most threat models and they could likely get a certificate to MITM the DNS over TLS requests as well. * In more secure settings, applications can be forced to only accept specific CAs, oftentimes a self-generated one. The above attack wouldn't work in that occasion. Generally speaking, the biggest gains in DNS over TLS come in privacy, not security (although there are some, especially for applications that don't enforce SSL).
- newscracker 8y ago
  > HSTS won't protect the initial connection, but will protect from future downgrade attacks by telling the browser to not accept insecure connections from the domain. But HSTS preload [1] is meant to protect even the initial connection, right? If a site serves HSTS headers, it could (potentially) choose to be added to the preload list that’s used by many browsers. [1]: https://hstspreload.org https://hstspreload.org
  - petronio 8y ago
    I hadn't heard of that service before, very interesting, thanks for pointing it out.

petronio 8y ago

"Worse still, clients that believe themselves secure using HTTPS are essentially voiding their warranty by using UDP DNS." I wouldn't go that far. It's true that if the browser has never gone to a website before you can MITM to have the client connect to a server that doesn't support SSL and basically be left with a MITM'd HTTP connection. It's not fool-proof, but there's various measures that are being deployed to reduce such attacks: * Chrome has started adding "Not Secure" to proactively alert users of websites not using SSL. If a user sees a major website and "Not Secure" is visibly displayed, hopefully that'll serve as a good warning to not continue. * HSTS won't protect the initial connection, but will protect from future downgrade attacks by telling the browser to not accept insecure connections from the domain. * Unless it has been otherwise tampered with, the HTTPS connection will still be encrypted and the certificate verified regardless of whether DNS has been tampered with. At that point the attacker would need a valid certificate from a trusted CA for the domain, which is outside of most threat models and they could likely get a certificate to MITM the DNS over TLS requests as well. * In more secure settings, applications can be forced to only accept specific CAs, oftentimes a self-generated one. The above attack wouldn't work in that occasion. Generally speaking, the biggest gains in DNS over TLS come in privacy, not security (although there are some, especially for applications that don't enforce SSL).

newscracker 8y ago
> HSTS won't protect the initial connection, but will protect from future downgrade attacks by telling the browser to not accept insecure connections from the domain. But HSTS preload [1] is meant to protect even the initial connection, right? If a site serves HSTS headers, it could (potentially) choose to be added to the preload list that’s used by many browsers. [1]: https://hstspreload.org https://hstspreload.org
- petronio 8y ago
  I hadn't heard of that service before, very interesting, thanks for pointing it out.