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?
> 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.
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.
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?
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.
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.
"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).
> 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.
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"
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.
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.
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.
Yeah,but now you're talking about browsers. You and others keep telling me how secure TLS and CA pki is,I never said otherwise. It's just not end to end. The subject here is dns over https and there certainly is no client auth here. TLS provides good transport security for the client. Not end to end,as in the CA infra for client auth isn't on par and even if it was CT is not TLS protocol feature and it's up to applications to verify CT,have only good root CAs and do client certs right
What is the difference between "the server I meant to communicate with" and a "server ... with authority to communicate on behalf of my intended peer"?
This seems like a distinction with no meaningful difference, outside of esoteric things like hardware-based attestation where you actually do want to identify a peer with the specificity of an actual physical piece of equipment. As soon as we introduce names that are not physically bound, we have a level of indirection that erases any distinction you were making.
The difference is that one is verified by trusting the peer while the other is verified by trusting a 3rd party. So trust is me-3rd party-them. As opposed to end to end where it is me-them.
> perfectly acceptable for a middleware with a valid cert from an authorized CA to intercept the traffic
Wow, that is a LOT easier said then done. With today’s Certificate Transparency Log requirements, any new certificate must have a cryptographically verifiable entry into at least two different public logs. If a bad actor at a CA were to generate this trusted cert you described, there would have to be a public record of it for it to be trusted. Beyond that, if the CA was found to be complicit, then they would lose their trusted status- looking at you Symantec.
If they own the device they can install trusted root CAs that are not public or have CT logs. Anyway,question is if you can call TLS end to end or not.
Yes, if you own the device, you can choose what to trust beyond valid cert requirements. To answer your question, yes, I do consider TLS end-to-end despite involvement of a 3rd party. I believe certificate transparency has removed a lot of the trust issues around CAs that previously existed. Trust is no longer required when there is public verifiable logs. Also, with the trend moving towards short cert lifespans, the risk of certs being stolen and used against you is more difficult- requiring regular updates. I hope to see the max cert validity periods become shorter and shorter
That's ridiculous. The popular CAs are not part of the TLS standard and neither is CT. Plenty of intranet TLS with intetnal CAs. CTs are good if the end client only uses root CAs that participate.
Let's say CT solves the server authentication issues,how does does the server authenticate the client? End to end means both parties authenticate,TLS supports client authnetication but a) DNS over HTTPs isn't doing that b) even if it did there isn't CT for client certs...
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.
27 comments
[ 3.4 ms ] story [ 68.8 ms ] threadWithout 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?
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.
Or are name servers like 1.1.1.1 and 8.8.8.8 what you mean by resolvers?
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.
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).
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
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"
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.
Either way,I'm all for it,just don't think the "end to end" label is warranted.
This seems like a distinction with no meaningful difference, outside of esoteric things like hardware-based attestation where you actually do want to identify a peer with the specificity of an actual physical piece of equipment. As soon as we introduce names that are not physically bound, we have a level of indirection that erases any distinction you were making.
Wow, that is a LOT easier said then done. With today’s Certificate Transparency Log requirements, any new certificate must have a cryptographically verifiable entry into at least two different public logs. If a bad actor at a CA were to generate this trusted cert you described, there would have to be a public record of it for it to be trusted. Beyond that, if the CA was found to be complicit, then they would lose their trusted status- looking at you Symantec.
Let's say CT solves the server authentication issues,how does does the server authenticate the client? End to end means both parties authenticate,TLS supports client authnetication but a) DNS over HTTPs isn't doing that b) even if it did there isn't CT for client certs...
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.