HSTS preload requirements

[crwatkins]

Over three years ago @jameshilliard proposed to add HSTS preload on web pages as a requirement for wallet downloads. I argued at the time to make it a transitional optional criteria giving web sites an opportunity to update. It might be near time to make this criterion required. Some web sites that still need to be updated:

• bitcoinknots.org @luke-jr
• ~bither.net @bithernet @songchenwen~
• bitpay.com @matiu @cmgustavo
• btc.com @jiangjinyuan ~@lsgrep~
• ~coin.space @jspeigner @nikashitsa~
• ~electrum.org @ecdsa~
• keepkey.com @dstanchfield @keepkeyjon
• ledgerwallet.com @EricLarch
• ~trezor.io @prusnak~

Could we get some feedback from the above contributors whether this is an issue for them or if the websites have been updated?

[jspeigner]

UPDATE: Coin.Space already has HSTS enabled. Has been this way for 4 years. Please let us know if there are any updates needed after you confirm.

Status: coin.space is pending submission to the preload list.

[crwatkins]

@jspeigner Thanks for the quick reply! Here we are talking about HSTS preload in browsers. See https://hstspreload.org/ for more information on this and let us know here if you have any questions. This is particularly important for web wallets.

[songchenwen]

@crwatkins we just moved bither.net to GitHub Pages recently. However we figured that Github Pages does not support HSTS headers for now. I think we will move the site back to our own server. An ssllab A+ server is already configured, and we just need to move the content now.

[songchenwen]

@crwatkins HSTS deployed for bither.net now.

[crwatkins]

@songchenwen Thanks 宋辰文 Take a look at https://hstspreload.org/ and be sure register bither.net for preloading.

[jspeigner]

coin.space is pending submission to the preload list.

[crwatkins]

@jspeigner Yay! Thanks Jonathan.

[songchenwen]

@songchenwen Thanks 宋辰文 Take a look at https://hstspreload.org/ and be sure register bither.net for preloading.

OK. I'll look into this.

[songchenwen]

bither.net is pending submission to the preload list. @crwatkins

[ecdsa]

ok, I just submitted electrum.org

[crwatkins]

@ecdsa Thanks Thomas!

[crwatkins]

@songchenwen Thanks 宋辰文 looks good to me.

[lsgrep]

Hi @crwatkins , @jiangjinyuan is in charge of btc.com wallet now. He will provide feedback on the matter soon.

[crwatkins]

@lsgrep thanks

[luke-jr]

HSTS is harmful. TLS doesn't provide real security, merely tricks users into thinking they are secure. HSTS forces TLS and breaks downloads from non-TLS-capable clients.

Concept NACK

[luke-jr]

It's been clarified that HSTS doesn't actually create problems, but only HSTS preloading; and the latter only because Google bullies people into useless redirections to qualify for their preload lists.

At the end of the day, requiring HSTS preloading is essentially giving Google a rubber stamp to approve or not approve. Strong NACK on that.

[jameshilliard]

HSTS forces TLS and breaks downloads from non-TLS-capable clients

In practice this should be a non-issue, downloads can also be excluded from being redirected to https.

Google bullies people into useless redirections to qualify for their preload lists

You really should just redirect everything to https as it has for a long time been considered best practices to protect against users from accidentally using the http version.

[midnightmagic]

I would offer that it would be better in that scenario to disable HTTP entirely rather than force a redirect—even though it would cause errors in user browsers.

I would also offer my (limited) observation that supporting a Google-pushed scheme such as this tends to drag implementors down to lowest-common-denominator constraints, as Google refuses to implement superior technology because it won't work for a very small number of users. (E.g. IIRC they did an experiment where they tried to do TXT lookups and concluded that DNS-based non-standard lookups couldn't be relied on to support keying because some users' DNS is total garbage.) :-(

[jameshilliard]

I would offer that it would be better in that scenario to disable HTTP entirely rather than force a redirect—even though it would cause errors in user browsers.

I don't see how that could possibly be a good idea, it causes usability issues without increasing security. Merely disabling HTTP would not prevent downgrade attacks while HSTS preloading does by forcing the browser to never attempt to connect to the HTTP site at all.

I would also offer my (limited) observation that supporting a Google-pushed scheme such as this tends to drag implementors down to lowest-common-denominator constraints, as Google refuses to implement superior technology because it won't work for a very small number of users.

The way HSTS preloading works is quite secure, more so than a DNS based scheme since there's less attack surface due to using hard coded preload lists, it's just making a centralization trade-off, but one that IMO isn't that big a deal since users are already trusting the web browser vendor for the most part.

IIRC they did an experiment where they tried to do TXT lookups and concluded that DNS-based non-standard lookups couldn't be relied on to support keying because some users' DNS is total garbage.

It's not really practical to break compatibility for any significant amount of users, especially when there are alternatives like HSTS preloading that don't do that. It's also the case that downgrade attacks are more likely to be an issue for users with messed up DNS(since networks/countries that mess with DNS are more likely to MITM a connection).

[crwatkins]

1. The preload list is used in all major browsers
2. I believe redirecting http is useful for informing any browser about HSTS status that does not support preload; not supporting redirection does not (substantially, if at all) decrease the attack surface
3. It's unfortunate that the list is centralized, but it is shared by all major browsers which are currently a major centralization of trust
4. If at any point we as a community disagree with the requirements to preload, we can change. I'm OK with it for now.

[midnightmagic]

I don't see how that could possibly be a good idea, it causes usability issues without increasing security. Merely disabling HTTP would not prevent downgrade attacks while HSTS preloading does by forcing the browser to never attempt to connect to the HTTP site at all.

If the browser HSTS preload list is not being used, then it doesn't matter whether the HTTP port is open or not because the MITM attack envisioned can Just Work anyway. Google (apparently) demands a redirect to be added to the preload list. There is no point to the redirect.

The way HSTS preloading works is quite secure, more so than a DNS based scheme since there's less attack surface due to using hard coded preload lists, it's just making a centralization trade-off, but one that IMO isn't that big a deal since users are already trusting the web browser vendor for the most part.

Literally Bitcoin's envisioned adversaries are powerful enough to backdoor hardware via package interdiction, sit Stingrays on the streets in Flower Delivery vans, and kidnap people. Handing control over an HSTS preload list to a corp who disabled uBlock because it was messing with their revenue and is defacto forcing themselves into a position of cloudflare-like power—Google themselves are the kind of opponent envisioned. Open Source means Chromium and Iron(?) and others exist. The browser itself is a monolithic horror, sure: but the main benefit of an HTTP redirect is user experience. Which not uncoincidentally is the only reason why they were accommodating people whose Internet is broken in the first place.

It's not really practical to break compatibility for any significant amount of users, especially when there are alternatives like HSTS preloading that don't do that. It's also the case that downgrade attacks are more likely to be an issue for users with messed up DNS(since networks/countries that mess with DNS are more likely to MITM a connection).

HSTS preloading would simply be supplanted in those countries anyway—I mean if we're trusting the browser, the browser could have just notified the user: "Sorry your internet is broken and can't be used securely get a VPN." It's literally just UX in that case. Google thinks lazy implementors give them a reason to punish all server implementors; everyone can't do it right so Google takes that away from them as an option. It's literally creeping turnkey totalitarianism. They're an ad company, not a user privacy company who cares at all about any of our requirements as Bitcoin users.

If we cared about HSTS preload then why are we bothering with gitian sigs..?

[midnightmagic]

If at any point we as a community disagree with the requirements to preload, we can change. I'm OK with it for now.

This is the only point of contention I (mildly) have; the fact we are lending our (perhaps meager okay) weight behind the use of HSTS preloading provides additional inertia and momentum for a corporation which in my view has basically left behind their do-no-evil a long time ago.

They could instead have used their weight to push a DANE-like user-operated system through, but they chose not to because they seem to me to think the Internet is comprised of small incompetent operators who shouldn't be running their own systems. DANE would allow at least site-based self-signed which could kill most of the PKI. Google could have simply made cert form one of the requirements the way some other vendors did and optionally given people a good reason to develop something else. Instead (and I mean no offence to you) we get just another nanny-state diktat which reduces us all to LCD because There Are No Other Browsers.

P.S. (edit) I won't throw a hissy when this goes through. :-) I just wanted to voice opposition to it. It's not a terrible idea. I just think there are better ways. IMO. (edit#2) Uh. These better ways don't realistically exist yet. So. Not like I'm able to even suggest any alternatives for direct implementation yet.

[jameshilliard]

If the browser HSTS preload list is not being used, then it doesn't matter whether the HTTP port is open or not because the MITM attack envisioned can Just Work anyway.

I think for non-preload HSTS you need to connect to the https version for your browser to accept the HSTS header, so a redirect is helpful there.

Google (apparently) demands a redirect to be added to the preload list. There is no point to the redirect.

It's mostly to prevent misconfigured sites from being added to the preload list accidentally.

Handing control over an HSTS preload list to a corp who disabled uBlock because it was messing with their revenue and is defacto forcing themselves into a position of cloudflare-like power—Google themselves are the kind of opponent envisioned. Open Source means Chromium and Iron(?) and others exist.

The situation is not really that bad IMO, the preload list helps your browser have the correct defaults for sites not seen before but your browser will still use normal HSTS headers for seen sites. I agree there are issues with google but I just don't see how refusing to enable HSTS preloading would help with that at all.

Google thinks lazy implementors give them a reason to punish all server implementors; everyone can't do it right so Google takes that away from them as an option.

A lot of technology needs to be designed for people who aren't very tech savvy so you need to make trade-offs sometimes that negatively impact move tech savvy users(although this can often be minimized by providing advanced potentially dangerous options that are hidden from normal users).

If we cared about HSTS preload then why are we bothering with gitian sigs..?

https://en.wikipedia.org/wiki/Defense_in_depth_(computing)

[luke-jr]

If at any point we as a community disagree with the requirements to preload, we can change.

There is already disagreement.

Google (apparently) demands a redirect to be added to the preload list. There is no point to the redirect.

It's mostly to prevent misconfigured sites from being added to the preload list accidentally.

Choosing not to redirect is not a misconfiguration. It is explicitly allowed by the HSTS spec.

I agree there are issues with google but I just don't see how refusing to enable HSTS preloading would help with that at all.

It's Google refusing to enable HSTS preloading for sites that don't bend over when they make demands.

[jameshilliard]

Choosing not to redirect is not a misconfiguration. It is explicitly allowed by the HSTS spec.

It's mostly to prevent certain misconfiguration issues such as having a site enabling HSTS preloading without properly supporting https.

It's Google refusing to enable HSTS preloading for sites that don't bend over when they make demands.

Redirecting to https is widely considered to be best practices regardless, I don't see how this is controversial, especially when it's trivial to exclude specific pages for backwards compatibility.

[crwatkins]

@jameshilliard

Redirecting to https is widely considered to be best practices regardless, I don't see how this is controversial, especially when it's trivial to exclude specific pages for backwards compatibility.

I tend to agree with that. Also, note that this has been required since our first itemized wallet criteria list about five years ago

• Website supports HTTPS and 301 redirects HTTP requests

[prusnak]

Trezor HSTS: https://hstspreload.org/?domain=trezor.io

[crwatkins]

@prusnak Yay!