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"
DNS Over TLS: Encrypting DNS End-To-end
11–20 of 28 posts
Re: DNS Over TLS: Encrypting DNS End-To-end
#12This 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 wil…
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).
Re: DNS Over TLS: Encrypting DNS End-To-end
#13Re: DNS Over TLS: Encrypting DNS End-To-end
#14Can 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…
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.
Re: DNS Over TLS: Encrypting DNS End-To-end
#15Can 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…
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.
Re: DNS Over TLS: Encrypting DNS End-To-end
#16I'd rather want to see DNS-over-QUIC
Re: DNS Over TLS: Encrypting DNS End-To-end
#17Can 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…
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…
Re: DNS Over TLS: Encrypting DNS End-To-end
#18This 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 wil…
"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 r…
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.
Re: DNS Over TLS: Encrypting DNS End-To-end
#19Can 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…
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 con…
Either way,I'm all for it,just don't think the "end to end" label is warranted.
Re: DNS Over TLS: Encrypting DNS End-To-end
#20Earlier quoted context omitted.
"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 r…
> 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