I still don’t get why HTTPS not just TLS. Because of the server coalescing? Don’t like the sound of that much, in practice maybe lots of sites do get served from a few CDNs, but is that the centralising/monopoly-operation-normalising kind of thing we want to be enshrining in open source browsers? Oh Cloudflare are helping to push it? Hmmmm
DNS over TLS also a thing that’s been spec’d. The problem is that so many pieces of networking hardware have ossified over the years that there are real challenges to introducing new protocols on the internet. Using an existing protocol is a solution to that.
Ah right, that does make some sense. Even though the server coalescing etc is HTTP/2 which ossified hardware is hardly going to support. But even still, HTTPS seems like a complex & possibly heavyweight protocol to use as a carrier for comparatively simple payloads, no?
If “block any and all DNS” is a viable approach for censorship, it’s pretty easy to change the port. There’s no reason to use a nearly unimplementably complex protocol stack to serve DNS.
That’s the best argument I’ve heard for it, by far. I wonder if there’d be some way to smart-multiplex protocols over 443 though. Mongrel2 used to do it I seem to recall.
But it’s not a new protocol – it’s TLS. If a middlebox can tell what is going over TLS in order to treat it differently, we refer to the situation as an “attack”.
There are plenty of situations in which TLS interception is consented to – corporate MITM boxes are the popular example – and they absolutely cause problems with deployment of new protocols (TLS 1.3 is filled with examples).
(I should note that TLS MITM boxes in my experience are all hot garbage and people shouldn’t use them, but there’s nothing wrong with them from a TLS threat modeling perspective.)
There are plenty of situations in which TLS interception is consented to – corporate MITM boxes are the popular example
Yes, but at that point, changes to DNS don’t help – you have a social problem, not a technical one. The group that is putting in the MITM boxes has the ability to force you to reveal your traffic regardless of what technology you put in. You’ve lost by default.
This isn’t a problem that throwing HTTP into the mix solves.
You really don’t need to convince me.
My first thought when I read about this was: where is the hypertext? I can’t think of me explaining to my grandchildren 20 years from now why we decided to use something designed to distribute HTML for DNS responses.
The problem is that so many pieces of networking hardware have ossified over the years that there are real challenges to introducing new protocols on the internet.
While I understand your argument, I always think of what ancient Egyptians would think of our “real challenges”.
Compared to people from 5000 years ago, we are all sissies.
The Egyptians never tried to coordinate hundreds of vendors, tens of thousands of deployments, and a billion users to update their network protocols.
I’m sure we could do better, but there are legitimate challenging technical problems, combined with messy incentive problems (no individual browser vendor wants to cause a perceived breakage, since the browser is generally blamed, and that would give an advantage to their competitors, or cause people to not upgrade, which for a modern browser would be catastrophic to security).
I still don’t get why HTTPS not just TLS. Because of the server coalescing? Don’t like the sound of that much, in practice maybe lots of sites do get served from a few CDNs, but is that the centralising/monopoly-operation-normalising kind of thing we want to be enshrining in open source browsers? Oh Cloudflare are helping to push it? Hmmmm
DNS over TLS also a thing that’s been spec’d. The problem is that so many pieces of networking hardware have ossified over the years that there are real challenges to introducing new protocols on the internet. Using an existing protocol is a solution to that.
Ah right, that does make some sense. Even though the server coalescing etc is HTTP/2 which ossified hardware is hardly going to support. But even still, HTTPS seems like a complex & possibly heavyweight protocol to use as a carrier for comparatively simple payloads, no?
Port 853 (DNS over TLS) is easy to block (in collateral freedom sense). Port 443 (HTTPS) can’t be blocked.
If “block any and all DNS” is a viable approach for censorship, it’s pretty easy to change the port. There’s no reason to use a nearly unimplementably complex protocol stack to serve DNS.
That’s the best argument I’ve heard for it, by far. I wonder if there’d be some way to smart-multiplex protocols over 443 though. Mongrel2 used to do it I seem to recall.
Years ago I used a reverse proxy to do exactly that. Unfortunately I can not remember the tools I used.
Probably stunnel and iptables on the server were used but I cannot really remember the tricks. I also had to do some tricks on the client, probably.
I have experience with both sniproxy and sslh. I never looked whether or not they support DNS+TLS or could easily be taught DNS+TLS.
But it’s not a new protocol – it’s TLS. If a middlebox can tell what is going over TLS in order to treat it differently, we refer to the situation as an “attack”.
There are plenty of situations in which TLS interception is consented to – corporate MITM boxes are the popular example – and they absolutely cause problems with deployment of new protocols (TLS 1.3 is filled with examples).
(I should note that TLS MITM boxes in my experience are all hot garbage and people shouldn’t use them, but there’s nothing wrong with them from a TLS threat modeling perspective.)
Yes, but at that point, changes to DNS don’t help – you have a social problem, not a technical one. The group that is putting in the MITM boxes has the ability to force you to reveal your traffic regardless of what technology you put in. You’ve lost by default.
You don’t have to be trying to defeat that person, the goal would simply be to make sure it doesn’t break when deployed.
The middle box knows the node ips.
It might be enough, for censorship.
You might be onto something, scarily enough. They are actling like Cloudflare is a reputable middleman.
You mean, like
1.1.1.1, which is used to serve TLS over HTTP?This isn’t a problem that throwing HTTP into the mix solves.
You really don’t need to convince me.
My first thought when I read about this was: where is the hypertext? I can’t think of me explaining to my grandchildren 20 years from now why we decided to use something designed to distribute HTML for DNS responses.
While I understand your argument, I always think of what ancient Egyptians would think of our “real challenges”.
Compared to people from 5000 years ago, we are all sissies.
The Egyptians never tried to coordinate hundreds of vendors, tens of thousands of deployments, and a billion users to update their network protocols.
I’m sure we could do better, but there are legitimate challenging technical problems, combined with messy incentive problems (no individual browser vendor wants to cause a perceived breakage, since the browser is generally blamed, and that would give an advantage to their competitors, or cause people to not upgrade, which for a modern browser would be catastrophic to security).
You should really visit Giza.
None of your arguments is false. But they are peanuts compared to building a Pyramid with the tools available 5000 years ago.
We should really compare to such human endeavours before celebrating our technical successes and before defining an issue as a “real challenge”.
Is it really wise to solve something as high-volume as name resolutions with TCP with all its overhead? If so, why HTTP? What do you need headers for?
HTTP is necessary because you can’t assume any ports other than 80 and 443 to be open.
Thankfully, we have
--portoptions for the daemons.