
Bringing HSTS to www.google.com - ejcx
https://security.googleblog.com/2016/07/bringing-hsts-to-wwwgooglecom.html
======
chinathrow
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?

~~~
jc4p
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.

~~~
AntiRush
[http://http.rip](http://http.rip) will always be http only; it's the domain I
use for this purpose.

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

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

~~~
chinathrow
Nope. [http://nosslsearch.google.com/](http://nosslsearch.google.com/) -> 404

~~~
the_mitsuhiko
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)

~~~
DanielDent
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.

~~~
stable-point
> 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.

~~~
zalmoxes
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](https://support.google.com/websearch/answer/186669?hl=en)

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

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

------
huula
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?

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

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

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

------
peterwwillis
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.

~~~
Buge
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.

~~~
kuschku
> 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?

~~~
icebraining
_I tried getting my personal blog added, it’s just impossible._

Why? [https://hstspreload.appspot.com/](https://hstspreload.appspot.com/)
didn't work?

~~~
kuschku
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?

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

