The fascinating world of HTTP Strict-Transport-Security
ergomake.dev
ergomake.dev
I get that ergomake has to bend to the whim of their customers, but TLS certs are free so engineering your systems to allow non-TLS http in 2023 is a huge regression
Or was Google so caught up in their good guy complex that they felt justified to perform a pedagogical intervention on the entire industry?
To be honest, people should've never used `.dev` for testing in the first place, given that IANA has reserved the `.test` domain specifically for that.
By making HTTPS the default for `.dev` they can save a few MS in rewriting the requests and a few bytes for the preload header.
In any case, I think it'd be okay for it to be the default, but I think it's not okay for it to be immutable. I should be able to remove my .dev domain from the preload list if I want to.
TL;DR: Ok default but IMO it should be possible to opt-out.
The problem with standards is no one ever reads them. This was published in 1999.
The TLD namespace was effectively frozen for a long time until ICANN got greedy and decided to sell parts of it off.
By forcing HSTS for .dev they broke setups of people who hijacked a domain name they didn't own and that wasn't made for that purpose (and, as others pointed out, there are TLDs reserved for testing that you can use). So they forced those people to fix their stuff. If they hadn't done that .dev probably would have gained the reputation of the TLD that doesn't work, because all kinds of people redirected it to some testing hosts.
It's their TLD, they do whatever they want.
e.g. we use `https://www.splitgraph.test` for local development, which is nice because we avoid a whole class of "works in dev" bugs that you get with `http://localhost:3001`
For the certificate, we use a self-signed certificate signed by a root cert generated by mkcert [1] locally on each developer's machine (to avoid sharing a root cert that could be used to MITM each other).
I wanted to suggest using a .test domain but managing the hosts file is always really clunky, even with a slick tool like hostess[1].
The internal DNS server masks the public one, so that I can assign local IPs at will, use HTTP or HTTPS at will, and when I'm outside of the network, the devices will contact the public DNS server and use the actual public IP of the network to access a limited set of servers (like ejabberd). These servers then stay accessible on the inside but through the local IPs, so that they don't have to leave the local network touching the edge router (which also solves some NAT issues on WebSocket connections).
This isn't exactly accurate. The HSTS RFC explicitly contemplates the preload list: https://www.rfc-editor.org/rfc/rfc6797#section-12.3
* author forgot to renew the cert like, day before
* author also set up HSTS and both browsers said "nope, we won't even let you add exception for this one".
The alternative is that if I can mess up their HTTPS connections to your site with HSTS, users just click the "exception" button and it undoes all the benefits of HSTS.
My favourite issue I stumbled upon is that Apple HomePods can't complete their first setup. Couldn't be bothered dumping what exactly they're doing, but it does raise a few questions. Though there are quite a few other things that break, like Debian/Ubuntu/apt repositories, Windows Update and Store and some games.
That is exactly why I was pushing to remove the keys from the mirrors but unofficially it's too late as any changes could cause disruptions for people that have private internal mirrors. I suggested just communicating the change for a year prior which would have occurred years in the past as of now.
Sure you can do some form of fingerprinting with request sizes over https, but that's another step and no guarentee (which of two identical length files did they get for example)
What the risk is to this information is another matter.
Sure, they can't modify the .deb without failing signature verification, but they _can_ inject arbitrary delays in downloads or interfere with anything else which isn't signed (e.g. HTTP headers)
Plus, if a vulnerability was discovered in the signing tool which enabled signature verification bypass with a certain signature format, HTTP makes it easy for attackers to perform that attack.
TLS shouldn't be optional for installing packages today IMO - the extra guarantees it provides are worth it even with signature verification enabled.
https://www.debian.org/security/2016/dsa-3733
https://justi.cz/security/2019/01/22/apt-rce.html
I really don't see how anyone can still defend not using TLS for debian packages.
This worked really well when I did some work at a uni and we wanted to avoid the onslaught of Apple devices all downloading updates at the same time from overwhelming our network.
This kind of "friendly MITM" is sort of the baby that goes out with the bathwater on mandatory HTTPS, although I am personally of the opinion that it's not a big enough deal to block mandatory HTTPS---but there is debate there.
I am betting one of those checks fails because its on a network that blocks port 80.
It is quick interesting to see what is not HTTPS. One common one I have seen is tracking links in emails are often not HTTPS. I have even see password reset links wrapped in tracking links that redirect through HTTP. So these could be intercepted and used to reset your password before you do.
There's the Kaminsky attack, if your ISP's DNS server doesn't properly randomize query ids and source ports (and query case, for a few extra bits)
But you can also get unintentionally wrong information cached, if something flips a bit on the way, as DNS doesn't have end to end integrity.
I don't agree with this position. I'd summarize my position as "if you want to do something stupid and dangerous, I don't want to be involved in it."
Imagine if Google did not have and control its own browser, Chrome. In theory then Google could not force the author to purchase a .dev.domain. What's sad here is that according to the author Mozilla has followed Google's lead. Note this has nothing to do with fact that Mozilla's main source of income is Google, and Chrome was developed by former Mozilla employees who went to work for Google.
It is possible to use a browser other than Chrome or Firefox (or Safari, Edge, Brave, etc.) that has no XSS risk because the browser does not auto-load resources. This alleviates need for HSTS as a means to prevent XSS (NB. there are other purported justifications for using HSTS besides preventing XSS). How do I know it is possible. Because I use one. For recreational web use, like reading sites submitted to HN. Freedom of choice.
It's also possible to run a localhost-bound forward proxy where one can set HSTS to whatever value one desires, or remove the header entirely. Instead of relying on an advertising company, one can use the proxy to "upgrade" http:// to https://. All outgoing HTTP requests can be encrypted and connections to local port 80 can be forwarded to remote 443. I know it's possible because this is what I do. Unlike HSTS, the proxy "fixes" any application sending HTTP requests, not only a browser that supports HSTS. The proxy can also limit the sites the user wishes to trust.^1
That is the real issue I have with HSTS. It further removes (i.e., makes more difficult) the ability of the user to determine what sites she will trust, placing that decision in the hands of third parties, namely those that control the "CA system". It's already annoying enough that Chrome forces users to type a shibboleth into a keylogger to get past certificate warnings. HSTS makes it even more annoying. It is unfriendly for users who in some situations trust their own decision-making more than they trust Google and CAs.
"At first, we thought we could opt out of HSTS preload, but it doesn't seem like that'd be possible. Even if you access your Chrome's HSTS settings via chrome://net-internals/#hsts, you'll see Google doesn't allow you to remove preloaded HSTS entries."
This is telling. The risk of a user inadvertently disabling HSTS is close to zero. This is plain and simple removal of the ability of the user to control the program.
One option for users is to remove the entries in the Chromium source then re-compile.