Hacked in a public space? Thanks, HTTPS | Hacker News Reader

Hacked in a public space? Thanks, HTTPS

theregister.co.uk

27 pointsblowski29 comments

As long as you visited Gmail within the last 126 days, your browser won't allow you to visit the HTTP version of Gmail because they have HSTS[1] enabled:

> strict-transport-security:max-age=10886400; includeSubdomains

This sensational article fails to mention that.

To protect your website visitors, enable the HSTS header on your web server. Basically just use SSL Labs[2] and fix everything until you have an A+ rating.

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

[2] https://www.ssllabs.com/ssltest/analyze.html?d=wakatime.com

The article does mention HSTS. And for many sites on several browsers you don't have to have previously visited them because the HSTS list is preloaded.

More info here, also you can submit your own site: https://hstspreload.appspot.com/

I did this a while back for several of my domains and it was easy and fast. One new problem I have is that after getting on the list and moving the static HTML sites over to CloudFront's free HTTPS offering, I see Chrome 50+ will require that you keep sending the 'preload' header directive, which is impossible to do with CloudFront. Bummer.

If anyone from AWS sees this, please note this is one more reason your users want the ability to send extra headers. Even if it's only a select few headers chosen from a dropdown list, this added functionality would come as very welcome news.

My personal grief with HSTS is that it pretty much requires you to have installed and trusted one random 400 CA collection or the other. If you have uninstalled/distrusted most of them, no current browser will allow you to access a HSTS enabled domain using one of those distrusted CAs.

There is no override to skip and accept an encryption-only connection. Which is what I would have gotten with HSTS as well, because without independent verification the CA system is a lot, but not the mutually trusted third party it claims to be.

I'm quite happy that there's no way to bypass the intersitial for HSTS sites. Preventing non-technical users from clicking through SSL warnings (which is very common) is definitely more important than supporting a use-case that only affects a very, very small subset of users. If there's enough demand, I'm sure someone's going to introduce a hidden flag or some kind of extension that allows you to do this.

I understand why it is done; and that the new error pages that are not filled with technical details are a net win overall. But there are people out there that need those technical details, so that other people do not have to see them.

Chrome at least, does allow HSTS errors to by overridden (and "safe browsing" warnings). It's just not exposed visibly. There is a deliberately undocumented "cheat code" that you need to type.

If you mean the one starting with D, then I may have mistyped and need to try that again. Thought that did not work for the HSTS block.

They've changed the code from that, the new one starts with B.

What is this code?

I intentionally didn't mention it. You should be able to find it from what I said if you really need it.

You don't even need Gmail in your HSTS set if you have HTTPS Everywhere installed in your browser.

>If a site provides only HTTPS then sslstrip would fail as it can't fall back to HTTP

I don't believe this is true. Sslstrip would get the site in HTTPS and serve it to you in HTTP, right? Only pinning or hsts would prevent that, HTTPS only servers wouldn't help.

I guess they could mean hsts by HTTPS only, but the end of the article implies otherwise.

>Certificate pinning, though, is limited to Google sites at present

This is also false.

I'd also hope they'd mention something like HTTPS everywhere which also mitigates this.

MITM tools such as [0] can also generate new certificates on the fly. So, unless HSTS is enabled, the user will still see the green padlock. This, obviously is only possible if the signing authority is in the device's trusted CAs. But I'd assume that corporate systems would have local CAs trusted by their admins.

[0] MITM Proxy https://mitmproxy.org

Also it should be noted that Chromium will ignore certificate pinning if a private root certificate is used. So this will do nothing to prevent corporate snooping.

Which makes sense, because anyone who could install a root certificate on your system could easily disable any such check, backdoor Chrome, install a keylogger, etc.

This would lead to a false sense of security, which I believe would be worse than the status quo.

exactly the comment I was going to write :)

I don't want to sound like a jerk, but The Register is IT equivalent of Daily Mail more or less. Sensationalist clickbaity titles, misleading content, making news from non-news. Every time I click a link to it, I regret. This article is yet another example.

Please make a favor to fellow HNers and do not upvote ElReg stories. If you find something truly interesting there and want to submit, probably there's a better-written equivalent available on ArsTechnica or other page already.

I disagree. This article had several interesting points.

El Reg have a wide ( tech ) audience. Some articles are for noobs, fine. Like other places they need filler content when there is nothing organic happening.

They also have their finger on the pulse a lot more than stars-in-their-eyes tech coverage elsewhere.

Rather than Daily Mail I think of them more as New Scientist

This document goes to imply that corporations installing a private CA on your machine for SSL interception within business networks, somehow means any using any wifi anywhere compromises all communications. This is quite a leap.

What a pointless article. Nothing news-worthy.

It's in The Register.

Is there any way on the client side to pin the certificate you are expecting a website to be served under ?

I use SimpleNote a lot, and don't want my work snooping on the contents. Nothing dodgy, just a little tin-foil hatty. If they do snoop, and I have no mechanism to know when they are, then I'll stop using it.

So SimpleNote use a Comodo certificate ( by inspection ).

How can I personally instruct my browser to reject any cert from a different provider just for SimpleNote.com ?

Besides the fact that the author is a fucking dunce, the more important fallacy in this article is that there's a hacker running Kali on a laptop in a coffee shop just trying to steal your Facebook credentials, or GMail. Nobody gives a shit about your private data (other than the government, and advertisers)

How exactly does a "hacker in a coffesshop" spoof a Google cert without Chrome complaining? These certs are pinned. Or is that just an implementation detail that if they had to explain would prevent them from writing such click bait?

The "fun" thing about this article is that pretty much every claim they make is debunked one or two paragraphs later, but that doesn't seem to be stopping them from making click-baitish claims.

I'd almost be willing to accept this, because while we do have tons of new mechanisms such as HSTS and HPKP that prevent most of this from happening, and while most big sites have adopted at least HSTS, the same thing certainly cannot be said for every single financial institution and many other sites out there. So I guess there is some truth to the statement that HTTPS is no silver-bullet for public networks ... yet.

Except that it pretty much is. Redirects from HTTP to HTTPS are not. But they failed to mention the one actually useful piece of information: If you visit a website where security is important, enter the URI with the https:// protocol specifier (or use a bookmark with that URI) to prevent attackers from hijacking the connection.

Carrying a supercomputer with internet connectivity via a network with largely known vulnerabilities in my pocket, allows me to forgo public wireless networks and tether the Thinkpad instead.

It ain't perfectly secure but odds are I'm not the slowest wildebeest.

Hmm, does DNScrypt helps here too to increase security?

Reply on news.ycombinator.com