20 ms·

Encrypted SNI Comes to Firefox Nightly

326 points by okket 8y ago

deleted 8y ago
[deleted]
e1ven 8y ago
I'm curious why this is tied to DNS-over-HTTPS. It looks like Cloudflare is including a public key in the DNS lookup, which is used to encrypt the SNI information. Couldn't this key be stored in a TXT record for normal DNS lookups as well?
- rickbutton 8y ago
  If the public key was stored in a TXT record and accessed via regular DNS, then someone snooping the connection could see that you made a DNS lookup for that domain, and could make the reasonable assumption that you were about to make a request to said domain.
  - markovbot 8y ago
    Not if you use DNS-over-HTTPS, as is required to turn this on in Firefox
    - rickbutton 8y ago
      right, DNS-over-HTTPS solves this particular problem.
  - erinnh 8y ago
    Could also use DoT - DNS over TLS. Otherwise, this sounds suspiciously a lot like DANE, which cert authorities hate, since there would be no use for them. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
    - tptacek 8y ago
      Except for DNS standards aficionados, pretty much everyone hates DANE, including people who hate CAs. Here's a level-headed take: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
      - tialaramex 8y ago
        One thing to pay attention to in Langley's post about DANE is that he says they can't do this reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups. This thread is about eSNI. Guess what, eSNI can't be done reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups. Fortunately, Firefox has a solution for that, DoH. Wait, which of those two identical problems does it solve? Oh right, both of them.
        tptacek 8y ago
        DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward. And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for themselves (it's good, and interesting!) and come to their own conclusions.
        dagenix 8y ago
        And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/. He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use and Verisign behaved badly - the browsers really couldn't do anything about it at all unless they wanted to stop supporting .com - which is impossible. "Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.
  - gpm 8y ago
    Not if that someone can intercept traffic from my computer -> public site and can't intercept my computer -> dns server. And since DNS queries are commonly cached locally (i.e. dns server == my computer a reasonable percentage of the time) that's not even a rare occurrence.
  - zzzcpan 8y ago
    Someone could still make a very reasonable assumption based on IP addresses and response sizes, which is where I believe the primary focus would shift if by some chance this encrypted SNI becomes impossible to circumvent. But also someone could just block DNS-over-HTTPS requests altogether and force Firefox into cleartext DNS and therefore circumvent encrypted SNI. It also centralizes DNS requests at Cloudflare's POPs (a company from a mass surveillance, secret orders happy, police country by the way). No, none of it addresses privacy and security, probably only makes it worse. It's time to admit there is no future for privacy and security without overlay networks.
    - codetrotter 8y ago
      > someone could just block DNS-over-HTTPS requests altogether If you are going to block DoH you’ll need to block all HTTPS traffic altogether, don’t you? I mean unless you are just blocking traffic to some list of known DoH providers.
      - zzzcpan 8y ago
        DoH must be bootstrapped somehow to get IP addresses to make requests to. This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server. It's very hard to hide that fact, you need to actively fight those blocking attempts. And if it's done by some government, corporations just bend over backwards to help censorship, like they did in cases of Signal and Telegram recently for example.
        zamadatix 8y ago
        >This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server. This works great in theory but if it takes off then Google and Cloudflare can simply decide to serve DNSoHTTPS requests over their existing service IP space and you're left with the choice of block the internet or allow encrypted DNS lookups. As far as government comments you're never going to deploy public infrastructure inside a state and be able to avoid the state so it's pointless to bring anything about that up.
- the8472 8y ago
  Are there even any DoH resolvers you can run yourself? unbound only supports DoT. It's a shame that they had to invent yet another standard. This makes things a lot more complex to run in a lan. Especially since you also need certificates and put them into the browser trust store. Just to avoid leaking SNI.
  - zamadatix 8y ago
    The problem was DoTLS was too easily blocked, even by accident with networks that only allowed their DNS server on 53, HTTP on 80, and HTTPS on 443. Easiest way to fix it without giving network administrators a choice unless they control both the devices and the network was to make it ride over HTTPs. Unfortunately I think that means DoTLS is likely to become unused even though it is technically a "cleaner" protocol implementation. As far as resolvers you can run yourself everyone and their brother has made one - facebook, cloudflare, cordens, dnscrypt, your cousin's brother's sister on Github. Literally all there is to it is rewriting well formed datagrams into well formed JSON and back.
    - vetinari 8y ago
      There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. Each client that wants to use DNS using any protocol will have to contact it by IP first, and that IP has to be provisioned somehow. The same mechanism used for provisioning can be used for blocking.
      - zamadatix 8y ago
        > There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. I'm going to split this up into two answers: 1) The problem for "coffee shop" guest style networks isn't so much that they care to purposefully block this type of DNS as much as it's already blocked by accident and it isn't going to get unblocked any time soon since (realistically) nobody manages these networks post deployment. At least until 8 years later when something breaks or it becomes to unreliable and then is replaced by the next in-a-box solution they bought for 80 dollars. 2) This assumption of blocking works somewhat decently until Google or Cloudflare just decide to enable DNSoHTTPS on their main service IPs. Then you have the choice of blocking most of the internet or not spying on your customer's data. Now as a business if you own the devices and the network you can manage your devices appropriately with an explicit proxy or SSL intercept but general ISP/guest wifi tracking becomes an order of magnitude more difficult to do cost effectively.
markovbot 8y ago
This sounds great. Does anyone know if any web servers are planning on implementing it?
- erinnh 8y ago
  I have heard Googles boringssl already supports it, but I have found no actual evidence of that. Cloudflare apparently does support it already for all their websites though. (or at least the ones that use cloudflare dns also) https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/
- duskwuff 8y ago
  ESNI is primarily a feature of the SSL implementation, not of the web server. As far as I'm aware, it's not in OpenSSL yet, but is likely to be added once TLS 1.3 has been finalized.
seccess 8y ago
Hey I just recently complained about SNI on a recent HN thread (https://news.ycombinator.com/item?id=18223168 https://news.ycombinator.com/item?id=18223168). This is a lovely coincidence. Thanks Mozilla!
cremp 8y ago
Is it me or... > If they’re willing to convert all their customers to ESNI at once Why does it seem like this is over-engineering at it's finest? Not only are CDNs now part of the problem/solution space, but they are now dictating. It is now that much harder to diagnose issues when they do crop up, instead of checking ping or nslookup. Now, you've got to see if the DNS-over-HTTPS/The DNS record itself/Host/client/any number of other steps is broken. We've completely removed the ability for a poweruser to diagnose before calling their resident IT professional.
- drb91 8y ago
  I hope they add DNS resolution to the network activity tab.
  - lucb1e 8y ago
    DNS resolution is visible in one of the about: pages, iirc about:networking. But yeah, in dev tools would be much more convenient.
  - cremp 8y ago
    They can't, because that's handled at the OS level, not the application level. If a browser starts (purposefully) subverting the hosts file or not adhering to resolv addresses, then we've got a bigger problem. Think, a fat client resolving an address differently than a browser; then that's all sort of Pandora's Box.
    - drb91 8y ago
      DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes already visible to the system resolver.
      - 8y ago
mholt 8y ago
So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on centralized CDNs for adoption)? Edit: I realize ESNI and IPv6 are orthogonal, however, I wanted to ask since I know that lack of IP space and using NAT/SNI are correlated.
- StudentStuff 8y ago
  I do not think most webservers will be set up with one IPv6 address per website. As is, most IPv6 enabled sites that share an IPv4 with another site and also share their IPv6 address with those same sites. Assigning one IPv6 address per site would add complexity for little benefit.
  - pixl97 8y ago
    Does Apache or nginx still have issues with serving lots of ip's at once. I know a long, long time ago it could be a performance issue.
    - laumars 8y ago
      How long ago are we talking? Apache 1.3? That used to have a few nuances but it's now been superseded several times over. I didn't use 2.0 a whole lot but I don't recall it ever being an issue with 2.2 and we're onto yet another engine rewrite with version 2.4 (which has been available a few years now too).
- jeroenhd 8y ago
  I think SNI will remain in fashion even after IPv6 is introduced globally. SNI works fine for plain IPv6 address. If you run multiple websites on a single server for example you can move your server to another IP address / host / datacenter, update the IP address in your DNS settings and you're done. If you use IPv6 for this purpose, every domain and subdomain need to be configured with a new IP address and need a special line in the DNS config. This leads to administrative overhead, which leads to mistakes.
ex3ndr 8y ago
Does this mean that this change will add yet another roundtrip?
- caf 8y ago
  No, it's bootstrapped from an additional DNS record type (which presumably would be returned alongside the A record). See https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/ .
comesee 8y ago
As a cancer survivor, using the example of someone spying on your cancer.org visit as a motivation for encrypted SNI seems a bit excessive and insensitive. There are definitely more neutral ways of motivating eSNI than invoking the fear of a stranger finding out you or a loved one has cancer. Shame on Mozilla.
- dagenix 8y ago
  That example does make a very strong case for the feature - which I guess was the point. But, the audience for the post already knows that encrypted SNI is and why it's important. And if they don't, a much more light-hearted example would do. And it's not like there is much of an anti-encrypted-SNI movement that warrants a powerful response. So, yeah, I'd agree it seemed both jarring and unnecessary.
  - comesee 8y ago
    Yeah not sure why I'm being downvoted. Imagine if the example was HIV.org or ebola.org, totally doesn't seem necessary.
    - Simon_says 8y ago
      You're being downvoted because your own statement contradicts itself. You're so touchy about the cancer thing that you're complaining about it.
      - comesee 8y ago
        I'm touchy about the cancer thing because I had my leg amputated and went through chemo for a year.
        Simon_says 8y ago
        Getting agitated over a hypothetical example is a bit of an overreaction.
nykolasz 8y ago
I would love to understand why Firefox keep adding support for CloudFlare specific features.
- dagenix 8y ago
  Thats not remotely true. ESNI is a draft IETF spec - https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/. It just so happens, that right now CloudFlare and Firefox are the ones that implement it. But any particular feature, regardless of how great it is or how well specified by a standards body, must have a first implementation by someone. And it's really not that shocking that a group like CloudFlare wants to be at the forefront of new web technologies AND also has the resources to pay for it. What does boggle the mind that is that everyone freaks out when a draft IETF standard is implemented. What do people want? For it to spring into existence fully formed implemented by all browsers, operating systems, DNS software and providers, etc all that once? That would be ridiculous - and worse, if there aren't a few experimental implementations to work out the issues, even if that could happen, what would be implemented would probably have significant issues that we'd then be stuck with forever.
- jgrahamc 8y ago
  This isn't a Cloudflare-specific feature. It's an IETF draft standard: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 https://tools.ietf.org/html/draft-rescorla-tls-esni-00 Just as we've done with other standards in progress (QUIC, TLS 1.3) we've implemented on our network. That helps get the standard tested and adopted quickly. Literally, anyone can implement that standard, there's nothing "Cloudflare" about it.

326 points by okket 8y ago

deleted 8y ago

[deleted]

I'm curious why this is tied to DNS-over-HTTPS. It looks like Cloudflare is including a public key in the DNS lookup, which is used to encrypt the SNI information. Couldn't this key be stored in a TXT record for normal DNS lookups as well?

rickbutton 8y ago
If the public key was stored in a TXT record and accessed via regular DNS, then someone snooping the connection could see that you made a DNS lookup for that domain, and could make the reasonable assumption that you were about to make a request to said domain.
- markovbot 8y ago
  Not if you use DNS-over-HTTPS, as is required to turn this on in Firefox
  - rickbutton 8y ago
    right, DNS-over-HTTPS solves this particular problem.
- erinnh 8y ago
  Could also use DoT - DNS over TLS. Otherwise, this sounds suspiciously a lot like DANE, which cert authorities hate, since there would be no use for them. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
  - tptacek 8y ago
    Except for DNS standards aficionados, pretty much everyone hates DANE, including people who hate CAs. Here's a level-headed take: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
    - tialaramex 8y ago
      One thing to pay attention to in Langley's post about DANE is that he says they can't do this reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups. This thread is about eSNI. Guess what, eSNI can't be done reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups. Fortunately, Firefox has a solution for that, DoH. Wait, which of those two identical problems does it solve? Oh right, both of them.
      - tptacek 8y ago
        DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward. And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for themselves (it's good, and interesting!) and come to their own conclusions.
        dagenix 8y ago
        And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/. He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use and Verisign behaved badly - the browsers really couldn't do anything about it at all unless they wanted to stop supporting .com - which is impossible. "Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.
- gpm 8y ago
  Not if that someone can intercept traffic from my computer -> public site and can't intercept my computer -> dns server. And since DNS queries are commonly cached locally (i.e. dns server == my computer a reasonable percentage of the time) that's not even a rare occurrence.
- zzzcpan 8y ago
  Someone could still make a very reasonable assumption based on IP addresses and response sizes, which is where I believe the primary focus would shift if by some chance this encrypted SNI becomes impossible to circumvent. But also someone could just block DNS-over-HTTPS requests altogether and force Firefox into cleartext DNS and therefore circumvent encrypted SNI. It also centralizes DNS requests at Cloudflare's POPs (a company from a mass surveillance, secret orders happy, police country by the way). No, none of it addresses privacy and security, probably only makes it worse. It's time to admit there is no future for privacy and security without overlay networks.
  - codetrotter 8y ago
    > someone could just block DNS-over-HTTPS requests altogether If you are going to block DoH you’ll need to block all HTTPS traffic altogether, don’t you? I mean unless you are just blocking traffic to some list of known DoH providers.
    - zzzcpan 8y ago
      DoH must be bootstrapped somehow to get IP addresses to make requests to. This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server. It's very hard to hide that fact, you need to actively fight those blocking attempts. And if it's done by some government, corporations just bend over backwards to help censorship, like they did in cases of Signal and Telegram recently for example.
      - zamadatix 8y ago
        >This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server. This works great in theory but if it takes off then Google and Cloudflare can simply decide to serve DNSoHTTPS requests over their existing service IP space and you're left with the choice of block the internet or allow encrypted DNS lookups. As far as government comments you're never going to deploy public infrastructure inside a state and be able to avoid the state so it's pointless to bring anything about that up.
the8472 8y ago
Are there even any DoH resolvers you can run yourself? unbound only supports DoT. It's a shame that they had to invent yet another standard. This makes things a lot more complex to run in a lan. Especially since you also need certificates and put them into the browser trust store. Just to avoid leaking SNI.
- zamadatix 8y ago
  The problem was DoTLS was too easily blocked, even by accident with networks that only allowed their DNS server on 53, HTTP on 80, and HTTPS on 443. Easiest way to fix it without giving network administrators a choice unless they control both the devices and the network was to make it ride over HTTPs. Unfortunately I think that means DoTLS is likely to become unused even though it is technically a "cleaner" protocol implementation. As far as resolvers you can run yourself everyone and their brother has made one - facebook, cloudflare, cordens, dnscrypt, your cousin's brother's sister on Github. Literally all there is to it is rewriting well formed datagrams into well formed JSON and back.
  - vetinari 8y ago
    There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. Each client that wants to use DNS using any protocol will have to contact it by IP first, and that IP has to be provisioned somehow. The same mechanism used for provisioning can be used for blocking.
    - zamadatix 8y ago
      > There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. I'm going to split this up into two answers: 1) The problem for "coffee shop" guest style networks isn't so much that they care to purposefully block this type of DNS as much as it's already blocked by accident and it isn't going to get unblocked any time soon since (realistically) nobody manages these networks post deployment. At least until 8 years later when something breaks or it becomes to unreliable and then is replaced by the next in-a-box solution they bought for 80 dollars. 2) This assumption of blocking works somewhat decently until Google or Cloudflare just decide to enable DNSoHTTPS on their main service IPs. Then you have the choice of blocking most of the internet or not spying on your customer's data. Now as a business if you own the devices and the network you can manage your devices appropriately with an explicit proxy or SSL intercept but general ISP/guest wifi tracking becomes an order of magnitude more difficult to do cost effectively.

markovbot 8y ago

This sounds great. Does anyone know if any web servers are planning on implementing it?

erinnh 8y ago
I have heard Googles boringssl already supports it, but I have found no actual evidence of that. Cloudflare apparently does support it already for all their websites though. (or at least the ones that use cloudflare dns also) https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/
duskwuff 8y ago
ESNI is primarily a feature of the SSL implementation, not of the web server. As far as I'm aware, it's not in OpenSSL yet, but is likely to be added once TLS 1.3 has been finalized.

seccess 8y ago

Hey I just recently complained about SNI on a recent HN thread (https://news.ycombinator.com/item?id=18223168 https://news.ycombinator.com/item?id=18223168). This is a lovely coincidence. Thanks Mozilla!

cremp 8y ago

Is it me or... > If they’re willing to convert all their customers to ESNI at once Why does it seem like this is over-engineering at it's finest? Not only are CDNs now part of the problem/solution space, but they are now dictating. It is now that much harder to diagnose issues when they do crop up, instead of checking ping or nslookup. Now, you've got to see if the DNS-over-HTTPS/The DNS record itself/Host/client/any number of other steps is broken. We've completely removed the ability for a poweruser to diagnose before calling their resident IT professional.

drb91 8y ago
I hope they add DNS resolution to the network activity tab.
- lucb1e 8y ago
  DNS resolution is visible in one of the about: pages, iirc about:networking. But yeah, in dev tools would be much more convenient.
- cremp 8y ago
  They can't, because that's handled at the OS level, not the application level. If a browser starts (purposefully) subverting the hosts file or not adhering to resolv addresses, then we've got a bigger problem. Think, a fat client resolving an address differently than a browser; then that's all sort of Pandora's Box.
  - drb91 8y ago
    DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes already visible to the system resolver.
    - 8y ago

mholt 8y ago

So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on centralized CDNs for adoption)? Edit: I realize ESNI and IPv6 are orthogonal, however, I wanted to ask since I know that lack of IP space and using NAT/SNI are correlated.

StudentStuff 8y ago
I do not think most webservers will be set up with one IPv6 address per website. As is, most IPv6 enabled sites that share an IPv4 with another site and also share their IPv6 address with those same sites. Assigning one IPv6 address per site would add complexity for little benefit.
- pixl97 8y ago
  Does Apache or nginx still have issues with serving lots of ip's at once. I know a long, long time ago it could be a performance issue.
  - laumars 8y ago
    How long ago are we talking? Apache 1.3? That used to have a few nuances but it's now been superseded several times over. I didn't use 2.0 a whole lot but I don't recall it ever being an issue with 2.2 and we're onto yet another engine rewrite with version 2.4 (which has been available a few years now too).
jeroenhd 8y ago
I think SNI will remain in fashion even after IPv6 is introduced globally. SNI works fine for plain IPv6 address. If you run multiple websites on a single server for example you can move your server to another IP address / host / datacenter, update the IP address in your DNS settings and you're done. If you use IPv6 for this purpose, every domain and subdomain need to be configured with a new IP address and need a special line in the DNS config. This leads to administrative overhead, which leads to mistakes.

ex3ndr 8y ago

Does this mean that this change will add yet another roundtrip?

caf 8y ago
No, it's bootstrapped from an additional DNS record type (which presumably would be returned alongside the A record). See https://blog.cloudflare.com/encrypted-sni/ https://blog.cloudflare.com/encrypted-sni/ .

comesee 8y ago

As a cancer survivor, using the example of someone spying on your cancer.org visit as a motivation for encrypted SNI seems a bit excessive and insensitive. There are definitely more neutral ways of motivating eSNI than invoking the fear of a stranger finding out you or a loved one has cancer. Shame on Mozilla.

dagenix 8y ago
That example does make a very strong case for the feature - which I guess was the point. But, the audience for the post already knows that encrypted SNI is and why it's important. And if they don't, a much more light-hearted example would do. And it's not like there is much of an anti-encrypted-SNI movement that warrants a powerful response. So, yeah, I'd agree it seemed both jarring and unnecessary.
- comesee 8y ago
  Yeah not sure why I'm being downvoted. Imagine if the example was HIV.org or ebola.org, totally doesn't seem necessary.
  - Simon_says 8y ago
    You're being downvoted because your own statement contradicts itself. You're so touchy about the cancer thing that you're complaining about it.
    - comesee 8y ago
      I'm touchy about the cancer thing because I had my leg amputated and went through chemo for a year.
      - Simon_says 8y ago
        Getting agitated over a hypothetical example is a bit of an overreaction.

nykolasz 8y ago

I would love to understand why Firefox keep adding support for CloudFlare specific features.

dagenix 8y ago
Thats not remotely true. ESNI is a draft IETF spec - https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/. It just so happens, that right now CloudFlare and Firefox are the ones that implement it. But any particular feature, regardless of how great it is or how well specified by a standards body, must have a first implementation by someone. And it's really not that shocking that a group like CloudFlare wants to be at the forefront of new web technologies AND also has the resources to pay for it. What does boggle the mind that is that everyone freaks out when a draft IETF standard is implemented. What do people want? For it to spring into existence fully formed implemented by all browsers, operating systems, DNS software and providers, etc all that once? That would be ridiculous - and worse, if there aren't a few experimental implementations to work out the issues, even if that could happen, what would be implemented would probably have significant issues that we'd then be stuck with forever.
jgrahamc 8y ago
This isn't a Cloudflare-specific feature. It's an IETF draft standard: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 https://tools.ietf.org/html/draft-rescorla-tls-esni-00 Just as we've done with other standards in progress (QUIC, TLS 1.3) we've implemented on our network. That helps get the standard tested and adopted quickly. Literally, anyone can implement that standard, there's nothing "Cloudflare" about it.