Stories
Slash Boxes
Comments

SoylentNews is people

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

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.
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, @03:02PM (6 children)

    by unauthorized (3776) on Saturday February 10 2018, @03:02PM (#636011)

    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.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by requerdanos on Saturday February 10 2018, @05:47PM (3 children)

    by requerdanos (5997) Subscriber Badge on Saturday February 10 2018, @05:47PM (#636071) Journal

    Ya sure about that? I remember reading... that for https, only the domain name (https://certain.type.of.site/) is visible to middlemen... (embarassing/subdir/certain-type-of-content.php?user=you) is transmitted inside of the encrypted request.

    What AC said. HTTPS fully wraps the HTTP protocol including the specific URL path

    Thank you both for the correction. Cisco [cisco.com] [PDF] describes the process as follows:

    1. The client’s browser checks the certificate of the requested web server to ensure that the site is trusted.
    2. The browser and the web server determine the best common encryption type they can both use to send
    and receive the SSL data stream....

    3. The browser and server exchange public and private encryption keys to use when encrypting the
    information that is sent and received.

    4. The browser and server start communicating using the encryption and the browser provides an indication
    to the user that the web pages are being processed securely.

    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.

    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.

    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.

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

    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)

      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.

      • (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.

    • (Score: 2) by urza9814 on Monday February 12 2018, @02:01PM

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

      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.

      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)

    by Anonymous Coward on Saturday February 10 2018, @07:07PM (#636103)

    except we all use dnscrypt, right?

    • (Score: 2) by urza9814 on Monday February 12 2018, @02:25PM

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

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