4 ms·

Can anyone expand on what advantage HTTPS has over raw SSL/TLS? Why tunnel over another application-level protocol? What's the value-add of throwing GET and POS

by dTal 7y ago

Can anyone expand on what advantage HTTPS has over raw SSL/TLS? Why tunnel over another application-level protocol? What's the value-add of throwing GET and POST etc into the mix? Truth be told, I don't even really understand why we didn't adopt "DNSs" decades ago along with HTTPS. Encrypt at socket level, done. What's the catch?

dqv 7y ago
Here's what the RFC[0] says about it: >Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...] [0]: https://tools.ietf.org/html/rfc8484#page-3 https://tools.ietf.org/html/rfc8484#page-3
- dTal 7y ago
  I don't see how on-path devices could distinguish between DNS-over-HTTPS and DNS-over-TLS, provided they were run on the same port. It's just an encrypted socketed connection. As for web apps... well, that's horrifying enough to be the real reason. Javascript should not be running its own DNS queries, outside of the system DNS settings - it's a layering violation that looks a lot like an end run around the "user agent" concept (i.e. the web app, rather than the browser itself, is the "trusted endpoint" and the user is considered an adversary). If web browsers actually wanted such functionality to be available, they could easily expose an API for it.
- catalogia 7y ago
  > "allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...]" What justifications for this exist?
zokier 7y ago
There is RFC 7858 Specification for DNS over Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7858 https://tools.ietf.org/html/rfc7858
tptacek 7y ago
It's actually quite simple: DoT runs over a separate TCP port and is trivial for network operators to filter, and DoH is deliberately more tricky to filter; it's designed to provide a measure of DNS privacy even on networks that users don't totally trust. DoT is DoH with a kill switch for network operators.
- jeltz 7y ago
  While DoH is in theory hard to filter it is right now trivial to filter due to being ran at only a small set of known servers.
- dTal 7y ago
  Okay, but if that's the reason... why not just run DoT on port 443? It's still less complicated than layering an entire protocol, which the network operators never get to see because it's encrypted...
jlgaddis 7y ago
This is basically the DoH versus DoT argument. I'd prefer DNS-over-TLS myself but apparently DNS-over-HTTPS has more backing and is "winning". One big advantage that is argued is that DoH is much harder to block.

by dTal 7y ago

dqv 7y ago

Here's what the RFC[0] says about it: >Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...] [0]: https://tools.ietf.org/html/rfc8484#page-3 https://tools.ietf.org/html/rfc8484#page-3

dTal 7y ago
I don't see how on-path devices could distinguish between DNS-over-HTTPS and DNS-over-TLS, provided they were run on the same port. It's just an encrypted socketed connection. As for web apps... well, that's horrifying enough to be the real reason. Javascript should not be running its own DNS queries, outside of the system DNS settings - it's a layering violation that looks a lot like an end run around the "user agent" concept (i.e. the web app, rather than the browser itself, is the "trusted endpoint" and the user is considered an adversary). If web browsers actually wanted such functionality to be available, they could easily expose an API for it.
catalogia 7y ago
> "allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...]" What justifications for this exist?

zokier 7y ago

There is RFC 7858 Specification for DNS over Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7858 https://tools.ietf.org/html/rfc7858

tptacek 7y ago

It's actually quite simple: DoT runs over a separate TCP port and is trivial for network operators to filter, and DoH is deliberately more tricky to filter; it's designed to provide a measure of DNS privacy even on networks that users don't totally trust. DoT is DoH with a kill switch for network operators.

jeltz 7y ago
While DoH is in theory hard to filter it is right now trivial to filter due to being ran at only a small set of known servers.
dTal 7y ago
Okay, but if that's the reason... why not just run DoT on port 443? It's still less complicated than layering an entire protocol, which the network operators never get to see because it's encrypted...

jlgaddis 7y ago

This is basically the DoH versus DoT argument. I'd prefer DNS-over-TLS myself but apparently DNS-over-HTTPS has more backing and is "winning". One big advantage that is argued is that DoH is much harder to block.