Google Chrome will begin to mark all HTTP sites as "not secure" starting in July 2018. This is just a warning displayed in the URL bar and won't stop users from loading the pages:
For the past several years, we've moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we've also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as "not secure". Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as "not secure".
Also at TechCrunch and The Verge.
(Score: 2) by unauthorized on Saturday February 10 2018, @03:02PM (6 children)
What AC said. HTTPS fully wraps the HTTP protocol including the specific URL path, your ISP only knows that you've made a DNS request for "certain.type.of.site" and that you've been exchanging data with the IP address associated with it. You can obfuscate your DNS requests by using a third party resolver [wikipedia.org], in which case your ISP will only know that you've exchanged a certain amount of data with a certain IP address, which might allow them to infer the site you've been visiting depending on whether there is only one website or it's a virtual host for 50 different domain names.
(Score: 2) by requerdanos on Saturday February 10 2018, @05:47PM (3 children)
Thank you both for the correction. Cisco [cisco.com] [PDF] describes the process as follows:
So, certain.type.of.site is necessarily in the clear (until we get anoymous encrypted DNS), in making step 1 happen, but the sensivive/subdir/or-page.php doesn't get communicated until step 4, during which there is encrypted communication.
Well, no, you aren't asking for DNS for random.site.on.that.provider.net, you are asking specificically for DNS for certain.type.of.site, and until you get that, you have no way of knowing what other sites might be hosted at the same address.
This is true and helpful in many disciplines. For example, not sure how to say something in a foreign language you're learning? Just speak your best guess to a native speaker and they'll correct you immediately and cheerfully...
(Score: 2) by unauthorized on Saturday February 10 2018, @07:09PM (1 child)
You missed my point there. You can use a third party DNS provider and some of them do provide encrypted DNS, so your ISP doesn't directly have a way to know which hostname you requested. The DNS server owner will know your request, but your ISP will not. If you are really paranoid, you could also run your own DNS server, it's not that hard to set up one and nobody will ever know which hostnames you lookup because only you have the logs.
What your ISP knows is the IP address you connect to. They can easily acquire the list of domain names associated with that IP address from their own DNS database. However, they don't know which hostname you are using unless there is exactly one domain name associated with the target server, which is not often the case for smaller websites.
Well, there you have the correct answer. Enjoy.
(Score: 3, Informative) by urza9814 on Monday February 12 2018, @02:22PM
You're forgetting that SSL encryption can't begin until it has the hostname. Even if you're using encrypted DNS, if there's multiple secure servers on the same IP you'll likely end up using something like SNI [wikipedia.org], which sends the domain you're requesting to the server in the clear. Either way your ISP knows what site you're looking at.
The only way you'd get multiple hosts on the same server without needing to send an unencrypted hostname is if the server uses a master SSL key that is valid on all of the hosts it can possibly serve. Which you might get if that server is a Google load balancer, but then you're still just connecting to one target -- Google. If that server is hosting a thousand peoples' personal homepages, then either you're sending the domain names in the clear, or the hosting company just MITMed every single one of their customers (which is probably even worse in terms of security).
As far as I can tell, the only even *theoretical* way to defend against this would be to fake your first request -- send a request for Jim's homepage, then once the encrypted connection is up you alter the HTTP headers to request Frank's homepage instead. But there's two problems -- first, you have to already know about a "benign" hostname on the same IP, and secondly a lot of servers (Apache included) would apparently drop your connection as soon as you tried that. Maybe you could authorize a specific subdomain -- like sni.mydomain.com -- and you'd give the common webhost a key for *only* that subdomain? That way they can get the encryption up without needing SNI, and then they can redirect you to whichever domain you actually need. But I've never heard of that actually being done, and I can't find any other way to mitigate that particular threat. Plus that's still a form of MITM, it's just a bit more limited...but you've still gotta trust the host to redirect everyone to the right place and give up their access to that connection. At least until it became a standard that browsers understood and could try to defend.
(Score: 2) by urza9814 on Monday February 12 2018, @02:01PM
It's more complicated than that even.
DNS must be in the clear...unless it isn't. You can always set it up locally, it could be cached, it could be encrypted...there's a lot of ways around that, although you do have to actually put some effort into it.
But once you've got the DNS encrypted, and the page served over HTTPS...you've still gotta worry about stuff like SNI. Often you'll have more than one website at the same IP (small sites because they're renting shared servers; large sites because of shared cloud caching or load balancing.) And since HTTPS is tied to the domain, the server can't encrypt anything until it knows exactly which (sub-)domain you want. So even if you encrypt the DNS and encrypt the website, you still have to send the domain to the web server in the clear when you establish the connection. And I'm not aware of any technology that can mitigate that. In fact, some servers (like Apache) seem to be specifically designed to prevent attempts to hide that information (ie, you could theoretically request one site, then once encrypted change the HTTP header to request a different site...but Apache would apparently block that.)
Fully encrypted browsing is not even possible in theory.
(Score: 1, Informative) by Anonymous Coward on Saturday February 10 2018, @07:07PM (1 child)
except we all use dnscrypt, right?
(Score: 2) by urza9814 on Monday February 12 2018, @02:25PM
Doesn't help much. Even if you use DNSCrypt, your browser is sending the domain you want to connect to in the clear thanks to SNI. The technology to secure that has not yet been invented, although I imagine IPv6 might make it redundant if that ever gets fully deployed...