Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.

Google Chrome Will Mark Non-HTTPS Sites as "Not Secure" Starting in July 2018

posted by mrpg on Friday February 09 2018, @06:39PM   Printer-friendly
from the what-about-ftp dept.

takyon writes:

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.

Original Submission

 
This discussion has been archived. No new comments can be posted.
Google Chrome Will Mark Non-HTTPS Sites as "Not Secure" Starting in July 2018 | Log In/Create an Account | Top | 45 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by unauthorized on Saturday February 10 2018, @07:09PM (1 child)

    by unauthorized (3776) on Saturday February 10 2018, @07:09PM (#636104)

    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.

    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.

    the best way to get correct answer on the Internet is to post the wrong one...

    Well, there you have the correct answer. Enjoy.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 3, Informative) by urza9814 on Monday February 12 2018, @02:22PM

    by urza9814 (3954) on Monday February 12 2018, @02:22PM (#636684) Journal

    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.

    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.