Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Chrome Encryption Security The Internet

Chrome Promises 'No More Mixed Messages About HTTPS ' (chromium.org) 46

Posted by EditorDavid from the mixed-content-sending-mixed-messages dept.
"Today we're announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources," promises an announcement on the Chromium blog.

It notes that Chrome users already make HTTPS connections for more than 90% of their browsing time, and "we're now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date." In a series of steps outlined below, we'll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users...

HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users' privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between. In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites...
Starting in December of 2019, Chrome 79 will include a new setting to unblock mixed content on specific sites. "This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default..."

Then in Chrome 80, mixed audio and video resources will be autoupgraded to https://, and if they fail to load Chrome will block them by default.
This discussion has been archived. No new comments can be posted.

Chrome Promises 'No More Mixed Messages About HTTPS ' More

Chrome Promises 'No More Mixed Messages About HTTPS '

Comments Filter:

  • Croupier, put my $50 on that!

  • HTTPS doesn't mean a thing. Certificates are cheap these days, even for criminals with thousands of domains. A strict Content Security Policy is what Google should be pushing for.

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      But with a certificate in place you have yet one more tool for adblock software to use - put up a "not wanted" list of certificates that you can block.

      So it's not entirely bad.

      • Re: (Score:3)

        by Zocalo ( 252965 )
        The problem is that when a bad actor can get a HTTPS padlock for a couple of dollars, quite possibly using a stolen credit card, it's well within the realms of "cost of doing business". Using a cert blacklist is like using a hostfile to block domains - fine when you only have a few hundred, or even thousand, domains that are mostly static. Once you get to the point where you're adding hundreds, or even thousands, of domains a day - each of which probably is only in use for that a few days you need a bette

        • Re: (Score:3)

          by AmiMoJo ( 196126 )

          The problem is that when a bad actor can get a HTTPS padlock for a couple of dollars

          Google, and Mozilla for that matter, have addressed that. They no longer care about enhanced certificates that proclaim to verify the identity of the site. They have reduced the padlock, merely using HTTPS, to the absolute minimum that a site should offer.

          You can get HTTPS certs for free, by the way, from Let's Encrypt and a number of other sources. There's really no excuse not to use them now.

          Site identity verification is dead now.

          • You can get HTTPS certs for free, by the way, from Let's Encrypt and a number of other sources. There's really no excuse not to use them now.

            True of publicly available websites. But for sites on a home local area network (LAN), the excuse is not owning a domain name. Neither Let's Encrypt or any other CA/Browser Forum accredited CA will issue a certificate for a hostname under .local (the mDNS TLD) any or any other non-public TLD. What is the fully qualified domain name of your home router, printer, or network attached storage (NAS) box? Or do major smart TV and streaming box brands let the owner add a private CA's certificate to a device's trus

            • Re: (Score:2)

              by AmiMoJo ( 196126 )

              Why would this affect home network sites? Why would you have a mixture of HTTPS and HTTP on the same page if you don't use personal certs anyway?

              • Plex self-hosted media server software uses a server-browsing web application operated by the software's publisher to find the streaming servers run by a Plex user, and then once the user has selected a server from which to stream, the web application's client side streams the video from the server. But the publisher was running into mixed content blocking and had to spend a lot of money becoming a DigiCert reseller [filippo.io] in order to provide certificates on demand at no charge to Plex users. This is money that th

                • Re: (Score:2)

                  by AmiMoJo ( 196126 )

                  Your own link says:

                  Finally, it's meaningful that they were able to provide all this for free (as in, for their non-paying users). The era of paying for basic certificates is coming to an end.

                  So it sounds like free solutions are available.

                  The cost can't be that high anyway, if they are offering it for free to non-paying customers. Do we know the actual cost?

                  • So it sounds like free solutions are available.

                    The linked page implies that the solution works for Plex. Any application other than Plex that tries to use Plex's dynamic DNS and arrangement with DigiCert would probably end up with access denied. The developer of any other application would thus need to provide at least their own dynamic DNS. And even in the era of Let's Encrypt, it takes months to get a new dynamic DNS service's domain name added to the Public Suffix List (PSL) in order to avoid the rate limit of 20 certificates per registrable domain p

            • What is the fully qualified domain name of your home router, printer, or network attached storage (NAS) box?

              There are a couple of options that don't involve each end-user having their own person domain: 1) The manufacturer could provide a FQDN for each device (serialnumber.myprinter.com) and act as a proxy to complete the ACME DNS challenge. 2) Browsers could simply accept self-signed certificates for the .local TLD, with a warning the first time the domain is visited and any time the certificate changes. 3) Devices could encode the fingerprint of their self-signed certificate into the domain name itself (e.g. sh

              • The manufacturer could provide a FQDN for each device (serialnumber.myprinter.com) and act as a proxy to complete the ACME DNS challenge.

                This is a recipe for planned obsolescence and e-waste, as the manufacturer has an incentive to terminate dynamic DNS service to each customer effective the day the device's warranty expires. Another is that I fail to see how a service like this could be made to work for a software application that the end user installs on a NUC, Raspberry Pi, or other general-purpose computer. To take your manufacturer angle, would Raspberry Pi Foundation provide dynamic DNS for applications installed on a Raspberry Pi comp

          • Re: (Score:2)

            by Agripa ( 139780 )

            You can get HTTPS certs for free, by the way, from Let's Encrypt and a number of other sources. There's really no excuse not to use them now.

            Site identity verification is dead now.

            How does that help in off-line and embedded applications where certificates cannot be renewed?

        • Re: (Score:2)

          by Agripa ( 139780 )

          On the flipside, enforcing this mostly lipservice-to-security policy breaks another tranche of poorly designed but entirely legitimate sites, lame corporate intranet sites, and web-based appliance admin GUIs that don't comply and/or use self-signed certificates.

          It also breaks embedded administration pages which use real certificates because they eventually expire.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        But with a certificate in place you have yet one more tool for adblock software to use - put up a "not wanted" list of certificates that you can block.

        Won't work, especially with services like Lets Encrypt basically providing certificates for everyone for free. Unless you want to ban Lets Encrypt, that is. Especially since Lets Encrypt certificates expire quickly, making any blacklist grow extremely quickly. I'm sure the process can be entirely automated, too.

    • Re: (Score:1)

      by Anonymous Coward

      That's not important, which is why Google hides the front of the URL, makes it many clicks to see CERT info, abstracts away many parts of what users used to see. The result is, few even know what https is, that it's special, that there's a cert involved.

      Hell, firefox isn't better. It's 5 or 6 clicks from the url bar, clicking, to get to see the actual, real cert. And let's encrypt? The worst. As you said, what's the point? By abstracting away, most state actors, loads of hacking groups, can generate c

      • 3 clicks in Firefox - click the green padlock, click the "secure connection >" and then click the "more information" at the bottom of the panel that shows you the summary info of the certificate.

        Google can try to hijack the DNS system, but Firefox has already got DNSoH setup and runnign with Cloudflare so Google's attempt to control all the infrastructure has been foiled.

    • Thatâ(TM)s not an issue. This is to prevent mitm attacks on insecure content loaded by secure pages.

  • Just disable HTTPS.

  • ok pay supermico and others to give updates ipmi's for at least 5 YEARS with certs updates and don't error on self singed ones

    • And network switches, multi-function copiers, and anything Cisco more that a few years old! I think they forgot who owns the computer!

      • Re: (Score:2)

        by Agripa ( 139780 )

        And network switches, multi-function copiers, and anything Cisco more that a few years old! I think they forgot who owns the computer!

        And RAID hardware. And anything embedded.

    • Re: (Score:2)

      by sjames ( 1099 )

      Or make the browser accept a user approved self-signed cert without nagging or 'forgetting' that the user explicitly approved of the cert. Perhaps even make it easy for the user to add a signing cert for tyheir own things (for example in a small office environment or when using IOT devices).

  • Let's drop this "HTTPS" nonsense. It's garbage and doesn't work, just like unicode. And it sure as hell isn't secure, expect maybe for mass media moguls that want control of the internet like they have on broadcast.

  • ... public static images and html. It's public and static. Everyone can access it anyway, what benefit does encryption provide it ?

    • Re: (Score:2)

      by jeek ( 37349 )

      The thought here is preventing a man-in-the-middle (or your ISP, even) from knowing what HTML and images you are looking at.

      And, for HTML, also from it being modified in-transit.

      • Re: (Score:2)

        by sjames ( 1099 )

        Interestingly, Chrome complains bitterly about mixed content from LOCALHOST. If someone manages to MITM the loopback interface, the war is already lost. Blocking there will only induce migraines for people with a legitimate use.

        • Re: (Score:1)

          by rlwinm ( 6158720 )
          Chrome is already a nightmare for doing development on. The hillarity is all these silicon valley companies talking about improving privacy. They are the biggest privacy violators. Not the ISPs. Not the content serving side. It's the client edge where the weakness is.

      • Re: (Score:1)

        by rlwinm ( 6158720 )
        This is just overboard. I trust my ISP far more than I would trust Google. What's the point unless Google thinks they are so "trusted?"

      • Re: (Score:2)

        by RedK ( 112790 )

        The thought here is preventing a man-in-the-middle (or your ISP, even) from knowing what HTML and images you are looking at.

        Do business with a ISP you trust, don't foist a browser that can't do something simple like loading static ressources from plain old HTTP unto the rest of us ?

        That doesn't sound like a good reason to force encryption, the "muh tin foil ISP is bad" stuff. I don't care that you see I'm loading my bank's images and logos. I just don't want you to see my bank account number and balance.

        The browser should not force HTTPS in any scenario, it's software, not your mom.

        • Do business with a ISP you trust

          For those who live within the service area of only untrustworthy fiber, cable, or DSL ISPs, does this extend as far as moving to a different city served by an ISP you trust just to be within its service area?

          I don't care that you see I'm loading my bank's images and logos. I just don't want you to see my bank account number and balance.

          That doesn't help when an SVG image extends outside its bounding box and covers up your bank account balance in such a way as to falsify it, or when a CSS stylesheet uses analogous tricks to falsify your balance. Or when the ISPs serving your city are all complying with a government phishing expedition.

          • Re: (Score:2)

            by RedK ( 112790 )

            So you use a browser made by a third party that will just send back your entire Visa or Mastercard purchase history into a database.

            Seems legit. If your ISP is truly shady, theyâ(TM)ll MITM your HTTPS session anyway, forcing you to install their root CA to even get access to begin with, enabling them to terminate and proxy any HTTPS.

    • Without HTTPS, you have no way of knowing whether a man in the middle has faisified said "public static images and html." Or would you prefer HTTPS with a signing-only cipher suite that provides integrity but not confidentiality?

      • Without HTTPS, you have no way of knowing whether a man in the middle has faisified said "public static images and html." Or would you prefer HTTPS with a signing-only cipher suite that provides integrity but not confidentiality?

        Network ignorance question: I thought HTTPS allowed the site to verify the user, not the user to verify the site. Or have I mis-remembered something?

        • Re: (Score:2)

          by _merlin ( 160982 )

          The HTTPS site presents a certificate. You can verify that the certificate matches the domain name (and potentially IP address) that you connected to and was signed by a certificate authority that you trust. The certificate authorities are supposed to be audited to ensure they don't hand out certificates to people who don't control the domain/address they're requesting a certificate for.

      • Re: (Score:2)

        by Agripa ( 139780 )

        Without HTTPS, you have no way of knowing whether a man in the middle has faisified said "public static images and html." Or would you prefer HTTPS with a signing-only cipher suite that provides integrity but not confidentiality?

        If my local network or computer hardware is compromised, then HTTPS is not going to save me.

        • Many public hotspots' networks, such as those found in restaurants and coffee shops, are in fact compromised. HTTPS has become widespread in part to protect users' session cookies from attackers using Firesheep over those networks.

          I'm aware that your home network is not exactly the same as a public hotspot. I'd be interested to read how a web browser could reliably programmatically tell the difference between the two.

    • If your ISP could access the information, they could also sell this information! But then the fact that Google knows which sites you access would be less valuable!

      Google can also argue that it is a privacy issue (which it is to some extend in that it is easier for others to know what you are accessing).

    • Perhaps there should be an exception when the file name matches the SHA-256 sum of the file contents. This would give you assurances that the file was not modified in transit while giving you the promptness of unsecured HTTP.

    • I suspect it is so Google's money making ads and youtube and whatever are not blocked by corporate firewalls quite as easily. Then again, a lot of corporate firewalls now have ways of sniffing https / SSL by encouraging corporation IT departments to put what amounts to a man in the middle attack cert on the client computers. It's really annoying for everyone... I wish there was a good way for all.

  • From server to browser to GUI.
    Back to server again, fully protected from any advanced ad blocker all the way.

    That kind of clearer browser security for ads.
    HTTPS pages commonly suffer from a problem called ad blocking.
    Browsers block many types of ads.
    Which threatens ad sales.
    An ad blocker could tamper with ads.
    Will gradually move to blocking all ad blockers.
    So ads will continue to work.

Slashdot Top Deals

"When it comes to humility, I'm the greatest." -- Bullwinkle Moose

Close