[TonnyGaric]

According to https://get.dev/#benefits: >The .dev top-level domain is included on the HSTS preload list, making HTTPS required on all connections to .dev websites and pages without needing individual HSTS registration or configuration.

What browser are you using that you are not redirected to https://yc.dev?

>Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.)

[dooglius]

A somewhat out-of-date Chromium (69). I should upgrade, but I'm surprised the change is that recent.

[CydeWeys]

In Chromium, the whole HSTS preload list is expired if it gets too out of date, as domains are both added to and removed from the list. So you're giving up real security by running an out-of-date browser. Not only are HSTS-preloaded TLDs not secured, but even, say, gmail.com or yourbank.com aren't. See: https://chromium.googlesource.com/chromium/src/+/lkgr/compon...

I think it'd be better to use an out-of-date list instead of nothing; I should go push for that again.

[peterwwillis]

HSTS only works if (1) the endpoint properly supports it, (2) the browser supports it, (3) the list is up to date, (4) there is no attacker ever waiting for you to hit the page for the first time or when HSTS expires.

(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.

The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.

Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.

A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.

[CydeWeys]

(4) is solved by HSTS preloading. The request is upgraded to https before any traffic hits the network, even if you've never visited the domain before. The list of HSTS preloaded domains and TLDs is hard-coded into your browser. For more info: https://hstspreload.org/

[peterwwillis]

Clearly it's not solved by preloading, since an old list invalidates the preload, and not every site supports HSTS, and I imagine they would have individual expire times (but perhaps not as a preload)

Also, does that site even work?

  Status: google.com is not preloaded.
  Status: microsoft.com is not preloaded.
  Status: duckduckgo.com is not preloaded.
  Status: news.ycombinator.com is not preloaded.
  Status: aws.amazon.com is not preloaded.
  Status: bankofamerica.com is not preloaded.
  Status: capitalone.com is not preloaded.

Well right off the bat, I'm screwed... I hope nobody else on the internet is visiting these sites.

[styfle]

The source code says the data is only valid for 10 weeks. If Google releases a new version of Chrome every 6 weeks, then a user could never skip a single version of Chrome without becoming vulnerable.

That doesn't seem like it's enough time. I would expect one year or at least 6 months.

[CydeWeys]

I agree. Unfortunately I'm not on the Chrome team.

[owens99]

Chrome Version 71.0.3578.98, did not load as HTTPS

The "About" link at the top links to HTTPS, but it's a 404, because it points to //about instead of /about

[gbear605]

iOS Safari (and other iOS browsers) auto redirects to http://ycombinator.dev/

[CydeWeys]

Can you confirm that it's not rewriting the URL to https://yc.dev first before issuing a request to the network? It's possible that Safari has suffered some kind of regression. This definitely used to work at some point.

I can confirm here in Chrome and Firefox that the URL is rewritten internally to https://yc.dev (which then redirects to https://ycombinator.dev), so no unencrypted traffic is ever sent over the network.

[gbear605]

Unfortunately I’m not in a situation where I can test that. It’s very possible that that’s the case, but it then leaves the question of why the non-https ycombinator.dev is what we eventually end up on.

[CydeWeys]

Separate from HSTS, they should also be redirecting http to https. Hopefully they'll get around to that soon. The domain is still recent so they're probably not finished with configuration.

[TonnyGaric]

Strange. I wouldn't expect that, because according to https://caniuse.com/#feat=stricttransportsecurity, the latest versions of Chrome and Safari for iOS do support Strict Transport Security.

[gbear605]

I’m on iOS 12.2, which that site says supports Strict Transport Security.