Bringing HSTS to www.google.com | Hacker News Reader

Bringing HSTS to www.google.com

security.googleblog.com

112 pointsejcx73 comments

Doesn't that mean that wifi captive portals using www.google.com won't be able to take over the connection and re-direct to the captive portal?

This was my immediate first thought too. A lot of subway stations got WiFi in NYC and for the one directly underneath my office I always had to load Google first to get the login portal to load. Any other websites I visit (including this one) just displayed a HSTS error instead.

I usually type in a random url, like askdjajrj.com

Only works if you don't use your own DNS.

...which only works if UDP traffic on port 53 isn't blanket-rerouted.

I use cnn.com. I know they support neither ipv6 nor https, and they don't trigger firewalls.

I use cnn.com too because the name is short and easy to type on my phone. Hopefully they won't switch to HTTPS any time soon. :)

I use xkcd.com for this. Short safe domain, no HSTS.

You can use http://example.com operated by the IANA, which is accessible though http and https.

Since an auto-upgrade to https would break a considerable number of examples, and there's no compelling business need on their part to promote https-only, it's much more likely to stay available through http than just about any other website run by commercial interests.

example.com just seems to point to localhost for me. Weird...

Possibly you have a config somewhere that has example.com in it... Could try example.org instead?

Same thing there. Oddly enough, `dig @8.8.8.8 example.com` seems to work. No mention of it in /etc/hosts. Guess my ISP must be up to some shenanigans. :/

With mine I get:

    Host example.com not found: 5(REFUSED)

http://http.rip will always be http only; it's the domain I use for this purpose.

Very nice, I didn't know there was a dedicated site for "I need just HTTP" purposes. Thanks for the tidbit!

Actually, there is https on the site, at least with a self-signed cert.

https://http.rip/

I use an old and otherwise unused vanity domain hosted on a private server for this.

I use the biggest newspaper website in the country I am from since they don't have any TLS at all yet.

We must thanks the wifi alliance for not having solved this problem in 15 years while they were busy releasing broken crypto implementations.

Instead, it looks like the IETF will be the one solving it. https://datatracker.ietf.org/wg/capport/documents/

Yeah. The wifi alliance track record is so bad that it's a real pity they run one of the most important protocols we have today. They are decades late on most required innovations, and when they try to design something, it's just so severely broken that requires many iterations to get to a decent status. Miracast is another example of being late and failing at producing something decent.

You can use the addresses that Google and Apple products use to detect captive portals.

Google uses http://connectivitycheck.gstatic.com/generate_204. Apple uses http://captive.apple.com/hotspot-detect.html and http://www.apple.com/library/test/success.html.

I was pretty sure that my Android Version uses google.com for the 204 generation. Without further updates, that would break.

Probably not; google.com will still reply on HTTP, it's just that if you have a browser that visits the HTTPS page, it'll record a rule to never visit the HTTP version. I doubt the code doing captive portal detection supports HSTS at all, so most likely it'll still work just fine.

But that would be exactly the use case here; browse google manually and then hsts kicks in from then on. Later, I get a captive portal wifi and it uses http://www.google.com/generate_204 and whoops, no request sent and no way for the wifi to redirect me to their login portal.

Both happens in chrome hence the same browser context.

Ah, right; I was thinking about the detection mechanism (which probably doesn't use Chrome), not the redirection.

Right, the detection mechanism is part of the OS, not the browser.

https://developer.android.com/reference/android/net/Connecti...

I'm actually curious how anyone not a geek gets on Wifi at many coffee shops etc. Many captive portals don't seem to do anything and chrome just says "can't connect" or "cert bad". I used to go to test.com, now I go to foo.com. But I'm geek. What do all the non-geeks do?

Most operating systems have started detecting captive portals and presenting a notification. All of the modern consumer ones (OS X, Windows, Android, iOS) appear to have this detection. (I don't use it so not sure how well it works, though.)

Chromebook does as well. Works great.

Bugs will happen, but it's a very simply operation, they simply load an HTTP URL that has an expected response (Google's is just a 204 No Content) and check if it matches.

I used to stay a lot at a hotel that would "helpfully" exempt a good number of domains from the captive browser, including whatever macs and androids use to detect connectivity...

There should really be a standard for dealing with this, like a flag on DHCP saying "O HAI you need to login here", and providing a REST endpoint that will tell the OS the status of the connection at any given time.

As if such a standard would help for these WiFi providers that explicitly take steps to avoid captive portal detection?

Surely it's not in their interest to avoid captive portal detection, anyway? After all, it helps them advertise their product!

1. Complain that the internet isn't working. 2. Talk to friendly geek who explains going to non Secure site forces pop-up 3. Forget that this work around applied in all cafe and not just the one were problem solved. Goto 1.

Does this mean that "nosslsearch" is now no longer supported?

Nope. http://nosslsearch.google.com/ -> 404

That's always how it worked. nosslsearch only responds if you access it as "www.google.com" not as "nosslsearch.google.com".]

(As of writing it still works if you do it on a new browser. However once you have HSTS info it will always attempt to do an HTTPS connection I suppose)

I believe nossl was intended as a concession for schools that believe in censorship. It makes it relatively easy to configure things so Google doesn't go over SSL so that your existing MITM boxes which censor continue to function as before.

If they continue to support this use case, it may be hard to do without introducing bugs - one exposure to a 'real' service which spits out an HSTS header (or the preload list), and the machine loses the ability to conduct Google searches.

I think they'll either have to use some nasty workarounds, or they'll need to use a different domain - which isn't necessarily something you want to do when you are trying to provide simple rules which allow users to identify phishing.

More likely they'll simply force sites that want to continue to MITM to load their own CA roots.

Although I don't think this is their motivation, it also has the neat side-effect of making Google's Chromebook & device management services more useful.

> If they continue to support this use case, it may be hard to do without introducing bugs - one exposure to a 'real' service which spits out an HSTS header (or the preload list), and the machine loses the ability to conduct Google searches.

Those wishing to spy on their users with nossl could just disable HSTS in the browsers they provide.

Much easier to just load a root CA certificate - this use case is explicitly supported and does not require maintaining a browser fork & compile infrastructure.

But "just" doing either of these things turns out not to be simple for many organizations. It's bad enough needing to update your system image/deployment scripts (if you have any!). You also need to figure out what to do about all the devices you don't own. BYOD is a thing.

K12 schools are increasingly embracing BYOD and BYOD devices are sometimes resistant to this kind of meddling (iPads, Chromebooks).

In the US, they still have a legal obligation to censor the Internet or they lose federal funding.

Do you know how much funding is at stake nationwide? (It's E-Rate, as I recall.) How credible is it that an organization or wealthy individual or crowdfunding effort could offer a wholesale alternative? In San Francisco, SFPL chose to give up this funding several years ago in order to decline to install censorware.

Edit: a whole lot of money! https://en.wikipedia.org/wiki/E-Rate#Modernization

Libraries do tend to be bastions of extreme left-wing views on surveillance and censorship, so perhaps on the library side.

School boards, no way. I can't think of an easier way to torpedo a school board career (or indeed a "pillar of the community" parent's status in the neighborhood) than by mentioning that they think children should have easier access to pornography at school.

Call it "Internet Deregulation" and say that you will be able to lower taxes by X percent if you don't have to spend money on expensive internet filter solutions.

Libraries do tend to be bastions of extreme left-wing views on surveillance and censorship

By context I can guess what you mean, but by itself it's a very ambiguous statement :)

Eh, I don't think so. Civil Liberties over Family Values and all that.

Google has changed this almost a year ago

> Turn on SafeSearch VIP To force SafeSearch for your network, you’ll need to update your DNS configuration. Set the DNS entry for www.google.com (and any other Google ccTLD country subdomains your users may use) to be a CNAME for forcesafesearch.google.com.

>We will serve SafeSearch Search and Image Search results for requests that we receive on this VIP.

You can enforce safe search over https now https://support.google.com/websearch/answer/186669?hl=en

I used to work at Google, and I confirm the parent is correct. Things work this way so that schools can force safe search, while keeping HTTPS.

However, this means that schools can't see what pupils search for, and that any network operator can force safe search.

Schools almost ubiquitously use SSL -decrypting dpi devices with the device root installed on endpoints, bypassing both HSTS and HPKP.

Just curious, this looks like some already supported feature of nginx, only that it's supported through redirection. Is this a redirection too or a protocol change? How will that be reflected on the address bar?

No. If browser see HSTS header, then for specified time it will never even try to connect using http to this domain.

Uh, thanks, but 304 Moved Permanently also has a similar effect right?

No, 304 refer to specific URL, not whole domain.

HSTS will one day be remembered as the HTTPS version of SMS 2nd auth: A bad hack with good intentions. Sure, it can have some positive effect in the short term, but there are so many ways to subvert it that as its popularity grows, so will the attacks.

I'm interested in what these attacks are and what you think would be better. Especially with HSTS preloading (supported in Chrome, Firefox, IE, and Edge) I don't see any attacks really.

Potential security considerations identified by the authors of HSTS are manyfold [1]. The most obvious is (14.6) 'Bootstrap MITM Vulnerability' states that since a non-preloaded site's initial contact will be through a non-secure channel, a man-in-the-middle can tamper with the response and never set a HSTS policy, or set an intentionally misconfigured HSTS policy. Preload is designed to mitigate against this, but preloading every single website is... difficult.

[1] https://tools.ietf.org/html/rfc6797#section-14

You can't set a misconfigured policy over http, it needs to be HTTPS with a valid CA.

That's not entirely clear from the spec. Per section 11.3 [1], if HTST policy is enabled with a self-signed cert, then "then secure connections to that site will fail, per the HSTS design".

In my reading, it doesn't say that a compliant user-agent must not set HSTS policies for self-signed certs; rather, it says a compliant user-agent will show an un-remediable error upon attempt to visit the website.

[1] https://tools.ietf.org/html/rfc6797#section-11.3

Regardless of spec, none of the major browsers accept HSTS policies from sites with self-signed certs.

1. Target a Windows user older than Windows 7, or any version of IE older than 11, since HSTS is not supported there (RFC section 14.2)

2. Bootstrap MITM vulnerability (RFC section 14.6)

3. NTP attacks (RFC section 14.7) [1]

4. Send RSTs on all HTTPS traffic. Eventually the user will get fed up with the website not working and try plain HTTP on a different browser/client which doesn't have the HSTS policy cached.

4.1. After the new client connects, force some kind of error or warning on the connection, but still allow it to continue, and use SSL stripping for any initial plaintext connections. HSTS will not be set if any warnings or errors are found on the connection. (RFC section 14.3)

5. Phishing: Send non-secure URLs to your target with instructions that if the connection fails, try the same non-secure link on a different browser. (It may be easier to just register a fake-but-similar-sounding domain and give it a valid cert, and send links to that)

5.1. Phishing with a non-secure root domain cert (RFC section 14.8)

6. Develop a method to determine when a client's policy will expire - or just wait - and wait to attack the moment of the next request, which will [potentially] be in plain HTTP.

7. Invalid configuration, such as forgetting to include the 'includeSubDomains' flag.

8. Internationalized domain names (RFC section 14.10)

Pre-loaded HSTS lists are affected with some of the above attacks, and public-key lists are affected eventually because eventually you need to rotate a key.

[1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-By...

These are just the ten identified attacks so far, and they all stem from the design itself, which allows MITM on first connection or policy expiration. If your whole security feature is designed to allow MITM even once, it is guaranteed to happen at least once. This is why it's a well-intentioned bad hack.

The solution was - and still is - to design a protocol which will never allow insecure connections. This could be accomplished by forking SPDY or HTTP2.0 and naming the new protocol "SECURE", and passing out URLs like 'secure://google.com/'. This way it would be totally obvious to both the user and the browser that the connection should only ever be made using at least a valid signed cert, and HSTS would never be needed (but public-key pinning would still be needed). Mandatory DNS-based security would improve this further.

This almost happened with HTTP/2, but nobody proposed the new protocol name. Terrible missed opportunity.

A 'secure:' scheme sounds good, but I don't see how would it solve (1), (2), (5), (5.1) and (8); the scheme can't protect you if the attackers can switch it out or send the user to a domain they control.

None of these are an argument against HSTS. They are ways you can attack DESPITE it, IF you put in the extra effort or have specific favorable circumstances.

The only way your proposed solution (secure-only protocol) avoids your identified design flaw (non-secure connections are sometimes possible) is if everyone immediately switches it and retires HTTP. That's not going to happen.

Considering a number of your attacks rely on the user not looking at the site security level (or in some cases, even at the domain name spelling), I find it curious that you think another visual indicator will make a difference.

The argument against is it's a false sense of security.

And no, you don't have to retire http. and no, we don't have to switch to it immediately. You can simply add it as a new protocol and begin educating users.

No user that I personally know has ever been trained to identify markers on a browser, or the difference between 'http' and 'https'. It's all too complicated... What, is that a padlock? A check mark? Green? Blue? Yellow? What does "ache tee tee pee ess" mean anyway?

But what is very simple and intuitive is the word "secure". Just make sure the first word is "secure". It even rhymes!

You think users cannot be trained to recognize a green padlock, but they'll know to look for "secure://"? That seems a bit ... far-fetched.

Why "secure"? Why not "anquan"? Google tells me that is the Chinese word for secure and since there are about 3 times as many Chinese speakers in the world than English, shouldn't we be considering them first? Or maybe we should consider Spanish first?

> Especially with HSTS preloading

HSTS preloading is just distorting the market towards the already large sites.

A smaller site now will get ads injected by your ISP, but their larger competitor doesn’t.

Yet, you obviously can’t add every single private blog to the preloading list.

I tried getting my personal blog added, it’s just impossible.

So your solution is only good for the already huge websites.

What’s with democratizing the internet, giving every single personal blog the same tools as every huge site?

I tried getting my personal blog added, it’s just impossible.

Why? https://hstspreload.appspot.com/ didn't work?

Last I tried was a few years ago when that didn’t exist, nice that it does exist now.

I wonder what will happen once the preload lists are several billion pages long?

Hopefully by that time we've reached the point where we can deprecate HTTP without TLS and show appropriate warnings in browsers.

> I tried getting my personal blog added, it’s just impossible.

I got my personal blog, which gets less than 100 unique visitors a month, added with no problems at all.

I wanted to edit, but can’t edit anymore, and couldn’t answer comments due to the comment limit until now, but here it is:

Last I tried was a few years ago, when the official stance was "only the top 100 will be added".

Reply on news.ycombinator.com