4 ms·

It's a good point, but it is preventable by the network admin. For example, I bypass that by tunneling everything out over a VPN, and the local resolver attempt

It's a good point, but it is preventable by the network admin. For example, I bypass that by tunneling everything out over a VPN, and the local resolver attempts to use HTTPS to connect to upstream anyway. Obviously not every user is in a position to protect themselves in such a way, so I get why the browser is attempting to protect them. Just seems very wrong to me to take the control away from the user/network-admin in any way. I mean, if you're gonna do it, go whole-hog. Delete HTTP from the browser entirely, right? I don't think that would go over well either, although it could certainly be justified by the same logic. Maybe I'm misunderstanding something about the issue, there has been a fair bit of FUD, but I simply don't feel good about the browser taking authority outside it's "please render this code into a webpage" scope.

tptacek 7y ago
If you're going to the trouble of VPN'ing your DNS, you're fine in the Chrome scenario and could I suppose reasonably just disable DoH everywhere. Your ISP absolutely does not want you to do this, but they don't want you DoH'ing either. DoH is, after all, just a VPN for DNS.
glennpratt 7y ago
> take the control away from the user/network-admin You are confusing the network admin and the user. Most users have little reason to trust their router, they often don't own it, update it or have any clue about it. Even experts change roles here when they use any other entities network. I understand your use case, but I personally think the end devices should increasingly allow interception by network devices only with user consent, not implicitly. In other words, opt-in on the device with DNS settings and certificates. If you don't own the device (e.g. have root/admin/etc), you don't get to control it - beyond blocking it.
comex 7y ago
> Delete HTTP from the browser entirely, right? It’s not being deleted, but Chrome at least has been gradually phasing in a warning in the address bar whenever you visit an HTTP site. [1] (Firefox will apparently do the same starting soon.) I wouldn’t be surprised if the warning UIs get more aggressive a few years down the line, as HTTPS adoption continues to increase. [1] https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html https://blog.chromium.org/2018/05/evolving-chromes-security-...
- tialaramex 7y ago
  Firefox currently shows a red crossed out padlock for HTTP sites with form elements, but not yet for HTTP sites without form elements which for now get neutral treatment. The rationale is that you definitely shouldn't be using insecure forms, what could you possibly be writing where you really don't care about at least confidentiality (to prevent eavesdroppers from reading it) or integrity (to prevent a MitM from changing it) ? If you set HSTS and then subsequently remove HTTPS from a site it should (will for Firefox, kind of for Chrome) brick wall you, saying that it isn't able to reach the HTTPS site without offering to let you see the insecure and perhaps compromised HTTP site even if you spell out the HTTP URL. Unlike HPKP this isn't considered a foot gun because you can fix it by just enabling HTTPS, and why didn't you have HTTPS anyway? The biggest forward pressure for HTTPS is that newer protocol versions (after HTTP/1.1) do not in practice exist for plain HTTP. The way to do plain HTTP/2 is documented but nobody has plans to implement it, and there isn't even intent to document a plain HTTP/3 because the stuff it's built on is all encrypted from the ground up. From my point of view this is good news.

tptacek 7y ago

If you're going to the trouble of VPN'ing your DNS, you're fine in the Chrome scenario and could I suppose reasonably just disable DoH everywhere. Your ISP absolutely does not want you to do this, but they don't want you DoH'ing either. DoH is, after all, just a VPN for DNS.

glennpratt 7y ago

> take the control away from the user/network-admin You are confusing the network admin and the user. Most users have little reason to trust their router, they often don't own it, update it or have any clue about it. Even experts change roles here when they use any other entities network. I understand your use case, but I personally think the end devices should increasingly allow interception by network devices only with user consent, not implicitly. In other words, opt-in on the device with DNS settings and certificates. If you don't own the device (e.g. have root/admin/etc), you don't get to control it - beyond blocking it.

comex 7y ago

> Delete HTTP from the browser entirely, right? It’s not being deleted, but Chrome at least has been gradually phasing in a warning in the address bar whenever you visit an HTTP site. [1] (Firefox will apparently do the same starting soon.) I wouldn’t be surprised if the warning UIs get more aggressive a few years down the line, as HTTPS adoption continues to increase. [1] https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html https://blog.chromium.org/2018/05/evolving-chromes-security-...

tialaramex 7y ago
Firefox currently shows a red crossed out padlock for HTTP sites with form elements, but not yet for HTTP sites without form elements which for now get neutral treatment. The rationale is that you definitely shouldn't be using insecure forms, what could you possibly be writing where you really don't care about at least confidentiality (to prevent eavesdroppers from reading it) or integrity (to prevent a MitM from changing it) ? If you set HSTS and then subsequently remove HTTPS from a site it should (will for Firefox, kind of for Chrome) brick wall you, saying that it isn't able to reach the HTTPS site without offering to let you see the insecure and perhaps compromised HTTP site even if you spell out the HTTP URL. Unlike HPKP this isn't considered a foot gun because you can fix it by just enabling HTTPS, and why didn't you have HTTPS anyway? The biggest forward pressure for HTTPS is that newer protocol versions (after HTTP/1.1) do not in practice exist for plain HTTP. The way to do plain HTTP/2 is documented but nobody has plans to implement it, and there isn't even intent to document a plain HTTP/3 because the stuff it's built on is all encrypted from the ground up. From my point of view this is good news.