• TiffyBelle@feddit.uk
    link
    fedilink
    English
    arrow-up
    98
    arrow-down
    2
    ·
    1 year ago

    All well and good, but sadly this relies on the hosts managing DNS to include specific entries in their DNS configuration for keys to use during the encryption process. Unfortunately the vast majority of hosts probably won’t be bothered to do this, similar to DNSSEC.

    • LastYearsPumpkin@feddit.ch
      link
      fedilink
      English
      arrow-up
      137
      arrow-down
      1
      ·
      1 year ago

      And HTTPS relies on hosts managing SSL certificates. Web services don’t use them until it hits a critical mass, then it becomes weird and broken when you aren’t using it.

      This just needs some time to settle in.

      • DarkThoughts@kbin.social
        link
        fedilink
        arrow-up
        76
        ·
        1 year ago

        I remember when absolutely no one used https and then in a matter of a couple years things got really fast. Now you can easily browse with https required and only occasionally find the odd website that doesn’t use it (mostly some internet relic). That was such a great transition when it happened though.

            • kautau@lemmy.world
              link
              fedilink
              arrow-up
              26
              ·
              1 year ago

              Yes. Thank these folks:

              Mozilla employees Josh Aas and Eric Rescorla, together with Peter Eckersley at the Electronic Frontier Foundation and J. Alex Halderman at the University of Michigan. Internet Security Research Group, the company behind Let’s Encrypt, was incorporated in May 2013.

              They created the ACME standard, the open source community got on board, and soon enough everyone bought in, a massive step forward for Internet security and the benefit of open source.

              • jazir5@lemmy.ml
                link
                fedilink
                arrow-up
                13
                ·
                1 year ago

                So Firefox is basically the GOAT when it comes to internet security and privacy? They should team up with the signal guys.

        • Rade0nfighter@lemmy.world
          link
          fedilink
          arrow-up
          28
          ·
          1 year ago

          Google preferring https sites was the motivator I saw for client demands.

          SEO scores feed into the PPC cost in AdWords so all of a sudden people were crying out for their sites to “have the padlock icon” because what’s 20 bucks for a cert when you’re spending thousands of dollars a month

        • Chobbes@lemmy.world
          link
          fedilink
          arrow-up
          11
          ·
          1 year ago

          HTTPS is pretty much ubiquitous these days. It’s mostly an issue on a few smaller websites and blogs that people haven’t cared enough about to bother getting a cert for… But even that is rapidly going away. Even if a website has HTTPS, it’s not entirely uncommon for some resources to be loaded over regular HTTP, and sometimes websites don’t properly redirect you to the HTTPS version, making it possible to end up on the unencrypted version by accident.

          HTTPS is great, and Let’s Encrypt has been such a godsend for it… That said it’s not perfect, and also has some limitations on its own, and not every website implements all of the mitigations that help HTTPS do its job, so HTTPS adoption is a bit of a mixed bag. A big issue is that when you try to secure a previously insecure protocol this often makes downgrade attacks possible. For instance, if you just type “lemmy.world” into your web browser, and if somebody is able to intercept those packets, they could just reply “hey, I’m the lemmy.world, I don’t do HTTPS, let’s talk unencrypted” and your browser would have no idea that it should be talking HTTPS instead of HTTP. One way to avoid this problem is just by explicitly telling your browser to use HTTPS by going to “https://lemmy.world”, which tells it to talk over HTTPS, and in that case the man-in-the-middle wouldn’t be able to tell you to use HTTP instead and won’t be able to provide a valid certificate for lemmy.world (hopefully, anyway :P). This is also what HSTS is used for… It’s a header that the webserver sends to your browser saying “only talk to me with HTTPS”, so once you’ve visited a site your browser will remember that it should only use HTTPS with it in the future. This only applies to websites which you’ve visited before, though… To improve the protections a little bit there’s HSTS preload lists (basically your browser can have a list of HTTPS websites baked into it, so it knows when to only use HTTPS before you even do), https://hstspreload.org/… Or we could just solve this problem with DNSSEC and DANE, which allows you to look up the TLS certificates that should be used for the domain in DNS.

          That’s probably more of a rant than you wanted 😅… But basically, HTTPS adoption is really good these days in the sense that most websites will have a TLS certificate available (probably from Let’s Encrypt!), and will speak HTTPS. But, there’s still areas where we can improve internet security. I’m not sure how the adoption of HSTS is going, but I think it’s pretty low. DNSSEC adoption is abysmal and we should probably fix that.

          • dan@upvote.au
            link
            fedilink
            arrow-up
            6
            ·
            1 year ago

            HTTPS is pretty much ubiquitous these days.

            It never used to be, though. The same will happen with ECH/ESNI eventually, especially if browsers push for it like they did with TLS.

            • Chobbes@lemmy.world
              link
              fedilink
              arrow-up
              3
              ·
              1 year ago

              Yeah, especially before Let’s Encrypt recently it was a complete disaster. Definitely will be better support for ECH soon.

              • dan@upvote.au
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                Cloudflare helped quite a bit too, although I wouldn’t call that “true” TLS as part of the connection was unencrypted. In the old Cloudflare days before Let’s Encrypt existed and before Cloudflare had their self signed origin certs, often the connection between the end user and Cloudflare was encrypted, but the connection from Cloudflare to the origin server wasn’t. People were celebrating Cloudflare as a way to easily add TLS to a site, but in the background it was still plain text!

          • towerful@programming.dev
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            Even if a website has HTTPS, it’s not entirely uncommon for some resources to be loaded over regular HTTP

            I think all browsers will refuse to load a resource over HTTP if the website is served over HTTPS.

            • Chobbes@lemmy.world
              link
              fedilink
              arrow-up
              4
              ·
              1 year ago

              This is not true. Browsers will happily use http even if https is available, and without other mitigations like HSTS or DANE there is no way for your browser to even know that a site supports https. Many websites will forcibly redirect you to https, but this is the server telling you “hey connect with https instead”. A man-in-the-middle can simply not tell you to use https. Browsers have started marking http sites as insecure and will warn you about sending passwords, however.

              • towerful@programming.dev
                link
                fedilink
                arrow-up
                4
                ·
                1 year ago

                I think I phrased it wrong, or there is a confusion with terms.
                If a page is loaded with HTTPS, then images/CSS/JS/iFrames (resources) will not load over HTTP. The resources also have to be served via HTTPS.
                If a page is loaded over HTTP, then resources (images/CSS/JS/iFrames) can be loaded over HTTPS.

                My objection was to the “even if a server has HTTPS, some resources will still load over HTTP”

                • Chobbes@lemmy.world
                  link
                  fedilink
                  arrow-up
                  4
                  ·
                  1 year ago

                  As far as I know, this is not strictly true either. I believe most browsers currently block mixed active content like JavaScript or iframes, but will happily load images and such over HTTP (although I would not be surprised if this is changing).

        • 4am@lemm.ee
          link
          fedilink
          arrow-up
          6
          ·
          1 year ago

          The only place (other than old unmaintained sites) I’ve seen no TLS has been promotional sites for video games. Possibly something hastily thrown together?

      • TiffyBelle@feddit.uk
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 year ago

        You’re right, but HTTPS implementation added real, tangible benefits that everyone could understand. I think ECH is a little more abstract for the average user, which is why I compared it to DNSSEC which has notoriously poor buy-in.

        Obviously I hope ECH becomes a well-implemented standard. I’m just rather cynical that it’ll be the case.

    • Gestrid@lemmy.ca
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      Apparently, Cloudflare already supports ECH, and a not-insignificant number of websites use them.

    • pazukaza@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Wouldn’t it be better if reverse proxies simply had a “default key” meant to encrypt the SNI after an unencrypted “hello” is received?

      Including DNS in this seems weird.

      • p1mrx@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        What would stop a MITM attacker from replacing the key? The server can’t sign the key if it doesn’t know which domain the client is trusting.

    • jsdz@lemmy.ml
      link
      fedilink
      arrow-up
      81
      arrow-down
      1
      ·
      1 year ago

      Sort of. They can still see which IP address you’re connecting to, which by itself or in combination with some minor traffic analysis is quite often enough to identify which website you’ve visited. Perhaps it isn’t if the website puts absolutely everything through a giant CDN like Cloudflare, but in that case it’s Cloudflare which gets to see all the sites you visit which isn’t a whole lot better than the status quo.

      Still, it’s a little less information given away at least some of the time. Better to do it than not do it.

      • Atemu@lemmy.ml
        link
        fedilink
        arrow-up
        23
        ·
        1 year ago

        in that case it’s Cloudflare which gets to see all the sites you visit

        That’s the status quo. CF holds the private keys to all reverse proxy’d sites hosted on it.

        • jsdz@lemmy.ml
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          1 year ago

          To be more precise, my belief is that the main thing ECH does is make it more difficult some of the time (depending on the details of how the site works) for observers of network traffic to directly see which website you’ve visited if it’s one of those that have chosen to give all that data to Cloudflare or some similar system instead.

          There also do still exist some simple web hosting setups that share many independent domain names on the same IP, but I think it’s not as common as it probably was when they first came up with the idea of encrypting the tls server name many years ago. Maybe it’ll make a comeback for sites whose users need to avoid censorship in this way if it’s true that domain fronting has generally become more difficult.

          • kautau@lemmy.world
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            1 year ago

            Well they can see your browsing history, sure. But HTTPS will stop them from seeing the content you actually see on the web. At this point we are just getting into discussions of layers of trust, which are generally impossible to solve if you don’t trust anyone. If you don’t trust anyone don’t use the internet, ever. I do trust mullvad. They’re explicit about who is involved, I have the name of every team member, and through peer review I consider them trustworthy.

            https://mullvad.net/en/about

            For more info about how they are transparent, you can read their article about how they responded to a search warrant earlier this year:

            https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-subject-to-a-search-warrant-customer-data-not-compromised/

            In line with our policies such customer data did not exist. We argued they had no reason to expect to find what they were looking for and any seizures would therefore be illegal under Swedish law. After demonstrating that this is indeed how our service works and them consulting the prosecutor they left without taking anything and without any customer information.

            • patatahooligan@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              But HTTPS will stop them from seeing the content you actually see on the web.

              Sure, but that was true for your ISP as well. I’m not questioning what data you’re leaking. I’m saying that it’s the same data and you only change who you leak it to if you choose to use a VPN.

              It seems like you’ve thought about it and you have made an informed choice. That’s great and I don’t have anything to argue against here. The only reason I commented is that there seems to be a trend of “just use VPN and your data is protected” mentality, especially with all the ads in gaming/tech related content. There was no way for me to know if you or the other users who would read your initial comment were aware that using a VPN doesn’t magically protect your data if you don’t know who your provider is, so I though I’d point it out.

    • hillbicks@feddit.de
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      Yes and no. If your isp is still providing unencrypted DNS for you, then they can still see the domain name you’re visiting.

        • Ullebe1@lemmy.ml
          link
          fedilink
          arrow-up
          8
          ·
          1 year ago

          Ordinary DNS requests are always plaintext and readable to anyone between you and the DNS server. So regardless of which DNS server you use, your ISP can see all your DNS lookups. For any amount of privacy for DNS, the minimum is something like DNS-over-TLS or DNS-over-HTTPS, the latter of which Firefox uses by default in some countries and supports everywhere.

          • morrowind@lemmy.ml
            link
            fedilink
            arrow-up
            6
            ·
            1 year ago

            I mean with this + DNS over HTTPS can we guarantee the isp can no longer see anything?

          • dan@upvote.au
            link
            fedilink
            arrow-up
            5
            ·
            1 year ago

            Ordinary DNS requests are always plaintext and readable to anyone between you and the DNS server.

            Not just readable… The ISP can inject their own responses too. Regular DNS is both unencrypted and unauthenticated, with most clients not enforcing DNSSEC.

            • dan@upvote.au
              link
              fedilink
              arrow-up
              4
              ·
              1 year ago

              It’s easy to setup something like AdGuard Home that provides malware blocking, ad blocking if you’re interested in that, and supports DNS-over-HTTPS out of the box (unlike PiHole, which needs a bunch of manual setup)

            • vsh@lemm.ee
              link
              fedilink
              English
              arrow-up
              3
              ·
              1 year ago

              If you can protect it from leaks than why not, but beware the fines are big

    • DarkThoughts@kbin.social
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      That’s how I understood it. With regular https your doing on those websites is already encrypted, but your ISP or whoever sits in between can still se which sites you’re visiting. As far as I understand this standard would encrypt this step too.

    • sloppy_diffuser@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      It’s been a couple years since I was involved with ECH, but the implementations at the time were:

      The one by the draft’s authors in golang (Cloudflare). This is the actual test server. It uses Cloudflare’s fork of golang with an enhanced crypto library. https://gist.github.com/cjpatton/da8814704b8daa48cb6c16eafdb8e402

      BoringSSL used for chrome. There are nginx builds with BoringSSL, but I don’t know if the setting are exposed.

      https://boringssl.googlesource.com/boringssl/+/refs/heads/master/ssl/encrypted_client_hello.cc

      WolfSSL which I never got around to playing with.

      https://www.wolfssl.com/encrypted-client-hello-ech-now-supported-wolfssl/

      NSS which is Mozilla’s TLS library. There is a test server buried in there some place for unit testing.

      https://firefox-source-docs.mozilla.org/security/nss/index.html

      With that, you ALSO need a DNS server that supports DNS over HTTP (DoH) and HTTPS service binding records (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/).

      Bind9 had branches for both and I was able merge the two to satisfy that requirement.

      When connecting to such a server, you MUST NOT use a DNS resolver hosted by any origination along the path from client to server as they can correlate the host from the DNS request with your encrypted client hello. You can actually man-in-the-middle ECH to decrypt the client hello by overriding the hosts record when controlling the DNS resolver. My project was testing this for parental controls.

      Keep in mind, ECH really only benefits users connecting to a CDN. That is, when multiple services are behind the same IP. It masks which host the user is going to for any hop between the client and server.

      Any data mining company worth their evils will have an IP to DNS index to figure out the host when only one is behind an IP.

      This marginally gives some privacy to users. It hides the host from your ISP. It REALLY benefits browser companies and CDN hosts. What hosts a user is visiting now becomes exclusive data for those companies thereby driving up the value of the data. Assuming you aren’t being stupid with your addons.

  • miss_brainfart@lemmy.ml
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_can-i-use-ech-alongside-other-security-tools-like-ad-blockers

    Users using DNS-based filtering may need to tweak their configuration in order to make use of ECH. Firefox needs to be configured with a DNS-over-HTTPS server in order to make use of ECH. Depending on whether the DNS filter is locally hosted or hosted by an online provider, instructions for connecting to it over DoH will differ and users of these services will need to check their accompanying documentation.

    Sooo, I’m a bit lost here. How do I ensure everything’s working when I’m using a pihole? I don’t think I’m understanding everything correctly

    • TheKaul@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      It sounds like you’ll have to set your Pihole as the DNS server in Firefox’s settings, and then maybe from there it’ll work itself out? Or maybe the Pihole documentation will be updated in the next few days with some instructions on enabling this. I’m unsure myself to be honest.

      • miss_brainfart@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        That would make sense, wouldn’t it? I think I’m going to wait for the pihole team to inform about this.

    • DarkenLM@kbin.social
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      1 year ago

      I don’t think so, that’d be straight up impossible unless you’re behind a VPN. Your ISP can see every connection made between you and any other server, but a VPN uses encrypted payloads between their servers and you, and they make the requests using their servers, and pass the results to you. That way, your ISP only sees that you’re using a VPN, but can’t see anything else.

      As far as I understand it, ECH uses DoH (DNS Over HTTPS) to encrypt the domain name of your connections, but a direct IP address is always required, and most of the times, it’s enough to determine the website, as the ISPs can locate just about anything easily. However, the ISP won’t be able to (easily) know anything else about the connection, which remains unbroken between you and the server you’re connecting with.

      But still a very good feature nonetheless.

  • Karna@lemmy.ml
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    In my opinion, Firefox should give an option to enable ECH forcefully for users like me who has AdGuardHome/Pi-Hole running on Home Network. Currently, if DOH is disabled in Firefox setting, ECH won’t work, as per Firefox. 😦