5 ms·

DNS Over TLS: Encrypting DNS End-To-end

61 points by jgrahamc 8y ago

amaccuish 8y ago
FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.
- move-on-by 8y ago
  Thank you for this clarification. Its definitely an interesting decision. I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. Without a doubt, as far as security goes, DNSSEC would provide the security side - with DoT being a privacy provider. However, FB doesn't implement DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely understand why they do not implement it. This just leaves me in the dark a bit as to why they did this. Anyone have insights?
  - ilovecaching 8y ago
    > I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. You gain everything by this. Encrypting traffic from your stub resolver to the recursive resolver is meaningless if the recursive is going to send your request unencrypted to the authoritative. Recursive resolvers will send ECS data revealing your subnet and fingerprinting information, and open you up to active and passive mitm attacks. > Without a doubt, as far as security goes, DNSSEC would provide the security side You're comparing apple to oranges here, and DNSSEC is a far cry from total security. They are complementary; DoT provides a private and protected path to the authoritative, while DNSSEC proves origin authenticity and response correctness. But you're right in that DNSSEC is controversial and difficult to turn on.
    - vavrusa 8y ago
      From operational perspective, it may be easier to maintain a certificate (after all, that's what you already do for an HTTPS service) than a DNSSEC signed zone. It is also easier if you have a multiple DNS providers, since you don't have to coordinate zone resigning. On the other hand, DoT doesn't provide the same properties (like client-side revalidation) as record level DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect solution that isn't deployed. I see the two technologies as complementary, a fairly good DNSSEC deployment at the TLD level can provide a safe way for key discovery at SLD level. There are many facets to this, and it is still fairly early in resolver-to-authoritative DoT standardization process, this is just one of the first steps to show that it's feasible in real world.
- jolmg 8y ago
  Excuse my ignorance of DNS, but isn't the resolver a software component in most people's computers? For example, in GNU/Linux, I thought it'd be a part of libc and what read /etc/resolv.conf. What do you mean by connection between client and resolver? Or are name servers like 1.1.1.1 and 8.8.8.8 what you mean by resolvers?
  - ilovecaching 8y ago
    He means a recursive resolver. A stub resolver is also referred to as a client, so it's clear from context. When you connect to 1.1.1.1 you're using DoT, but not necessarily from the recursive to the authoritative.
deleted 8y ago
[deleted]
ilovecaching 8y ago
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
Avamander 8y ago
I'd rather want to see DNS-over-QUIC
- skrause 8y ago
  I don't understand the downvotes. Wouldn't QUIC be the perfect fit for a secure transport of DNS requests? The IETF already has a draft: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05 https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05
badrabbit 8y ago
Can a TLS connection ever be considered end-to-end secure? I mean,it's perfectly acceptable for a middleware with a valid cert from an authorized CA to intercept the traffic before the true endpoint,not to mention loadbalancers and other possible TLS terminators. As I understand it,end-to-end means application to application (endpoint to endpoint?) with assurance to the client that no middleware can intercept traffic successfully. Always thought TLS only assured the presenter of the ServerCertificate is authenticated for the subject,that is to say the client cannot say "I am sure this is the server I meant to communicate with",it can only say "The server I'm speaking with has authority to communicate on behalf of my intended peer"
- resonanttoe 8y ago
  If the DNS client has a pinned certificate/key this would break the MiTM/Middleware. But remember that you're only using the TLS connection for the DNS question and answer, so if you choose something like cloudflare/google/opendns then they'll configure their frontends/termination points with the respective pinned cert. Once the lookup has taken place, the connection is made with the proper endpoint and a new TLS connection takes place using traditional mechanisms. I feel that that most major providers have had enough of broken PKI infrastructure and bad uses that exposing DNS over TLS without something like Key pinning would be wise.
  - badrabbit 8y ago
    If you're pinning keys/certs,who needs a CA? If you don't need a CA,who needs the complicated TLS. I'd think wide adoption of TLS is the motivation,even then...DNS over QUIC? Either way,I'm all for it,just don't think the "end to end" label is warranted.
    - move-on-by 8y ago
      Just a note, chrome is removing HPKP (public key pinning) validation. So this is unfortunately not true. I’m not going to go into the details here, but they basically believe it does more harm then good and that cert transparency logs achieve the same goal of taking away trust from the CAs.
ubittibu 8y ago
Sorry for my ignorance, but didn’t we have Stubby ad the latest DNSCrypt for the same purpose? In what is this project different?
xte 8y ago
I trust more my ISP, witch is in my country, under my country laws that remote DNS under unknown laws, operate by super-big corps or by unknown guys... It's the same for VPNs: today to many people ask to "VPNs" without considering who host them on the other side and many other "encryption manias". Conceptually I fear far more modern browsers+webapps tracing capabilities than DNS-based monitoring so for me that's nice but certainly non important. Sorry for being rude.
- move-on-by 8y ago
  The connection discussed in this post is between FB’s DNS servers and CloudFlare- not end users. So ISP trust and VPN usage is a moot point here

61 points by jgrahamc 8y ago

FYI this is about the connection from a resolver to the authoritive name server, not the connection between a client and a resolver.

move-on-by 8y ago
Thank you for this clarification. Its definitely an interesting decision. I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. Without a doubt, as far as security goes, DNSSEC would provide the security side - with DoT being a privacy provider. However, FB doesn't implement DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely understand why they do not implement it. This just leaves me in the dark a bit as to why they did this. Anyone have insights?
- ilovecaching 8y ago
  > I wouldn't think there is much to gain privacy-wise between cloudflare and FB's DNS servers. You gain everything by this. Encrypting traffic from your stub resolver to the recursive resolver is meaningless if the recursive is going to send your request unencrypted to the authoritative. Recursive resolvers will send ECS data revealing your subnet and fingerprinting information, and open you up to active and passive mitm attacks. > Without a doubt, as far as security goes, DNSSEC would provide the security side You're comparing apple to oranges here, and DNSSEC is a far cry from total security. They are complementary; DoT provides a private and protected path to the authoritative, while DNSSEC proves origin authenticity and response correctness. But you're right in that DNSSEC is controversial and difficult to turn on.
  - vavrusa 8y ago
    From operational perspective, it may be easier to maintain a certificate (after all, that's what you already do for an HTTPS service) than a DNSSEC signed zone. It is also easier if you have a multiple DNS providers, since you don't have to coordinate zone resigning. On the other hand, DoT doesn't provide the same properties (like client-side revalidation) as record level DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect solution that isn't deployed. I see the two technologies as complementary, a fairly good DNSSEC deployment at the TLD level can provide a safe way for key discovery at SLD level. There are many facets to this, and it is still fairly early in resolver-to-authoritative DoT standardization process, this is just one of the first steps to show that it's feasible in real world.
jolmg 8y ago
Excuse my ignorance of DNS, but isn't the resolver a software component in most people's computers? For example, in GNU/Linux, I thought it'd be a part of libc and what read /etc/resolv.conf. What do you mean by connection between client and resolver? Or are name servers like 1.1.1.1 and 8.8.8.8 what you mean by resolvers?
- ilovecaching 8y ago
  He means a recursive resolver. A stub resolver is also referred to as a client, so it's clear from context. When you connect to 1.1.1.1 you're using DoT, but not necessarily from the recursive to the authoritative.

deleted 8y ago

[deleted]

ilovecaching 8y ago

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

Avamander 8y ago

I'd rather want to see DNS-over-QUIC

skrause 8y ago
I don't understand the downvotes. Wouldn't QUIC be the perfect fit for a secure transport of DNS requests? The IETF already has a draft: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05 https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05

badrabbit 8y ago

Can a TLS connection ever be considered end-to-end secure? I mean,it's perfectly acceptable for a middleware with a valid cert from an authorized CA to intercept the traffic before the true endpoint,not to mention loadbalancers and other possible TLS terminators. As I understand it,end-to-end means application to application (endpoint to endpoint?) with assurance to the client that no middleware can intercept traffic successfully. Always thought TLS only assured the presenter of the ServerCertificate is authenticated for the subject,that is to say the client cannot say "I am sure this is the server I meant to communicate with",it can only say "The server I'm speaking with has authority to communicate on behalf of my intended peer"

resonanttoe 8y ago
If the DNS client has a pinned certificate/key this would break the MiTM/Middleware. But remember that you're only using the TLS connection for the DNS question and answer, so if you choose something like cloudflare/google/opendns then they'll configure their frontends/termination points with the respective pinned cert. Once the lookup has taken place, the connection is made with the proper endpoint and a new TLS connection takes place using traditional mechanisms. I feel that that most major providers have had enough of broken PKI infrastructure and bad uses that exposing DNS over TLS without something like Key pinning would be wise.
- badrabbit 8y ago
  If you're pinning keys/certs,who needs a CA? If you don't need a CA,who needs the complicated TLS. I'd think wide adoption of TLS is the motivation,even then...DNS over QUIC? Either way,I'm all for it,just don't think the "end to end" label is warranted.
  - move-on-by 8y ago
    Just a note, chrome is removing HPKP (public key pinning) validation. So this is unfortunately not true. I’m not going to go into the details here, but they basically believe it does more harm then good and that cert transparency logs achieve the same goal of taking away trust from the CAs.

ubittibu 8y ago

Sorry for my ignorance, but didn’t we have Stubby ad the latest DNSCrypt for the same purpose? In what is this project different?

xte 8y ago

I trust more my ISP, witch is in my country, under my country laws that remote DNS under unknown laws, operate by super-big corps or by unknown guys... It's the same for VPNs: today to many people ask to "VPNs" without considering who host them on the other side and many other "encryption manias". Conceptually I fear far more modern browsers+webapps tracing capabilities than DNS-based monitoring so for me that's nice but certainly non important. Sorry for being rude.

move-on-by 8y ago
The connection discussed in this post is between FB’s DNS servers and CloudFlare- not end users. So ISP trust and VPN usage is a moot point here