DNS Over TLS: Encrypting DNS End-To-end
code.fb.com
code.fb.com
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?
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?
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.
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.
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...