Hacker News Reader

Comment by cdancette | Hacker News Reader

Maybe someday browsers won't accept http connections by default (except for a few domaines defined for test purpose, or for some specific tld like .local)

Only then we can have 100% of the web encrypted.

View on HN

It's moving that direction. As it stands, any website can opt-in to this behavior for future visitors with HSTS[0], or even for first time visitors with HSTS preload[1]. And Google has been doing HSTS preload on their .google TLD for several years, and recently rolled it out to their .foo and .dev [2] TLDs

[0] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[1] https://hstspreload.org/

[2] https://security.googleblog.com/2017/09/broadening-hsts-to-s...

There were a lot of complaints about Google doing that with .dev given the number of other companies and developers that use .dev for random LAN things, but an HSTS Preload for random LAN things isn't a bad idea in that it can prevent some types of mistakes going to production like bad HTTPS->HTTP redirects in an application. Obviously, Google themselves thought it a good idea to test that in their development environments.

The people doing random things with fake .dev domains were going to get bit in the ass one way or another. You can't just make up your own domain and hope no one ever does anything conflicting with it.

> You can't just make up your own domain and hope no one ever does anything conflicting with it.

Actually you can! You just need to use one reserved for that purpose:

> In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System.

https://en.wikipedia.org/wiki/.test

Sure, but you should NEVER use a domain that isn’t delegated to you or explicitly reserved by the IANA for local purposes. Plenty of people used .int as well which is now a gTLD, you can’t complain about a name you don’t own breaking down the line.

I was excited until I realized that HSTS Preload is just a hardcoded list in the Chrome source!? Ugh, that's sort of disappointing :(

Couldn't something like a TXT record also address this, but on a cross-client, scalable fashion? Like how SMTP with SPF or DKIM works right now.

(And yes, I know DNS also has trust problems!)

At the very worst, a central, programmatic source of truth, like DNSBL and company... just like how Google offers their "malware sites" hash table for all to use.

Using a TXT record for this purpose would achieve nothing. Just like an SSLStrip attack would strip https:// links and redirects, an attacker can simply block or spoof the DNS response. This doesn't add anything that you don't get with regular header-based HSTS.

DNSSEC has no practical impact on this due to a lack of adoption both on the domain and end-user resolver side. (Not to mention that it's a terrible protocol.)

Note that the HSTS preload list is not only used by Chrome, but practically all major browsers. For all intents and purposes it currently is the central source of truth. I imagine if the size ever becomes a problem, browsers will switch to a mechanism like Safe Browsing to distribute the list.

While I understand why HSTS makes sense I hate it and I think it comes from poorly tooling around it. Two examples:

1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list.

2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers...

For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/

Yeah, until that happens we won't ever be really secure.

I mean, take this case; lets say NatWest DID put their landing page behind SSL... well, lots of people are going to try to go to http://<url> instead of https://<url>. Most site will redirect the user to the https version, but if an attacker hijacks the initial request, they could easily serve up a fake version of the landing page that has a 'login' link to the malicious site.

Now, at least if NatWest was redirecting http to https, a savvy user could notice that their session wasn't being redirected to https and could be aware something was wrong, but if you didn't know to check, you could be fooled.

There is nothing the site owner can do to prevent that sort of hijacking.

HSTS Preloading solves that problem.

Huh, didn't know about that. Glad to see.

At that point, will we start seeing attackers targeting DNS instead?

You need to get to global DNS to get a valid cert. When certificate transparency logs become mandatory, that case will be detectable though not preventable.

Surely good enough detection is just one step from prevention? Detect fraudulent cert, revoke it. Or have I missed a layer?

Certainly, but depending on the type of attack, that might not be of much use. In a targeted attack, the damage might already be done by the time the certificate is detected. Additionally, revocation as a whole is broken in various ways[1], not to mention that even with hard-fail revocation checking[2], you have a window of several days during which you can staple a "good" OCSP response, from before the certificate was revoked. (The exact lifetime is up to the CA - I think the maximum allowed is 7 or 10 days.)

CT, as currently implemented, is good at two things: Detecting misbehaving CAs, and detecting certificates issued by attackers after a server is compromised or domain is hijacked, assuming the domain owner is monitoring logs for such certificates. The Web PKI does not provide many tools that actually mitigate damage for the second scenario (unless you've deployed HPKP, which is on its way out).

[1]: https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

[2]: Practically no mainstream browser uses hard-failing OCSP. Firefox supports the X.509 Must-Staple extension, which enables hard-failing OCSP, but Must-Staple has a glaring hole: If the attacker gains the ability to issue a certificate for the targeted domain, they can simply request a certificate without the Must-Staple extension. Must-Staple's usefulness is mostly limited to key-compromise scenarios.

Reply on news.ycombinator.com