19 ms·
Bringing HSTS to www.google.com
- chinathrow 10y agoDoesn'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 10y agoThis 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.
- batbomb 10y agoI usually type in a random url, like askdjajrj.com
- d33 10y agoOnly works if you don't use your own DNS.
- mappu 10y ago...which only works if UDP traffic on port 53 isn't blanket-rerouted.
- scrollaway 10y agoI use cnn.com. I know they support neither ipv6 nor https, and they don't trigger firewalls.
- cpeterso 10y agoI 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. :)
- roywiggins 10y agoI use xkcd.com for this. Short safe domain, no HSTS.
- niftich 10y agoYou can use http://example.com 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.
- Nullabillity 10y agoexample.com just seems to point to localhost for me. Weird...
- toast0 10y agoPossibly you have a config somewhere that has example.com in it... Could try example.org instead?
- Nullabillity 10y agoSame 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. :/
- cocotino 10y agoWith mine I get: Host example.com not found: 5(REFUSED)
- AntiRush 10y agohttp://http.rip http://http.rip will always be http only; it's the domain I use for this purpose.
- jevinskie 10y agoVery nice, I didn't know there was a dedicated site for "I need just HTTP" purposes. Thanks for the tidbit!
- chinathrow 10y agoActually, there is https on the site, at least with a self-signed cert. https://http.rip/ https://http.rip/
- inopinatus 10y agoI use an old and otherwise unused vanity domain hosted on a private server for this.
- monorailz 10y agoI use the biggest newspaper website in the country I am from since they don't have any TLS at all yet.
- giovannibajo1 10y agoWe must thanks the wifi alliance for not having solved this problem in 15 years while they were busy releasing broken crypto implementations.
- TD-Linux 10y agoInstead, it looks like the IETF will be the one solving it. https://datatracker.ietf.org/wg/capport/documents/ https://datatracker.ietf.org/wg/capport/documents/
- giovannibajo1 10y agoYeah. 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.
- atdt 10y agoYou can use the addresses that Google and Apple products use to detect captive portals. Google uses http://connectivitycheck.gstatic.com/generate_204 http://connectivitycheck.gstatic.com/generate_204. Apple uses http://captive.apple.com/hotspot-detect.html http://captive.apple.com/hotspot-detect.html and http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html.
- chinathrow 10y agoI was pretty sure that my Android Version uses google.com for the 204 generation. Without further updates, that would break.
- icebraining 10y agoProbably 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.
- chinathrow 10y agoBut 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 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.
- icebraining 10y agoAh, right; I was thinking about the detection mechanism (which probably doesn't use Chrome), not the redirection.
- chinathrow 10y ago
- greggman 10y agoI'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?
- ckuehl 10y agoMost 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.)
- cmdrfred 10y agoChromebook does as well. Works great.
- icebraining 10y agoBugs 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.
- mseebach 10y agoI 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.
- praseodym 10y agoAs if such a standard would help for these WiFi providers that explicitly take steps to avoid captive portal detection?
- 10y ago
- deleted 10y ago[deleted]
- the_mitsuhiko 10y agoDoes this mean that "nosslsearch" is now no longer supported?
- chinathrow 10y agoNope. http://nosslsearch.google.com/ http://nosslsearch.google.com/ -> 404
- the_mitsuhiko 10y agoThat'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 10y agoI 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 10y ago> 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.
- peterwwillis 10y agoHSTS 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 10y agoI'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.
- niftich 10y agoPotential 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 https://tools.ietf.org/html/rfc6797#section-14
- mkj 10y agoYou can't set a misconfigured policy over http, it needs to be HTTPS with a valid CA.
- niftich 10y agoThat'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 https://tools.ietf.org/html/rfc6797#section-11.3
- huula 10y agoJust 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 10y agoNo. If browser see HSTS header, then for specified time it will never even try to connect using http to this domain.
- huula 10y agoUh, thanks, but 304 Moved Permanently also has a similar effect right?
- garaetjjte 10y agoNo, 304 refer to specific URL, not whole domain.