Encrypted SNI

[Madis0]

https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/

TL;DR: prevents leaking the domains you request on sites that support it, including Cloudflare sites (which is what a big amount of websites uses).

network.security.esni.enabled = true

Test page

[meliurwen]

ESNI is actually enabled if and only if you are specifically using the Firefox integrated DoH "feature".

It's an arbitrary constraint that has never been lifted and looking at this 2 years old still open issue, probably will not in the near future.

In other words: that option to work would require to use the FF integrated DoH tunnel which is an undesired thing in many use cases. Imho only when Mozilla will decide to remove this artificial limitation then it will make sense to add this option.

[allo-]

Isn't this part of the TLS 1.3 standard?

Original decision was made because the plain DNS was not encrypted and host names are already leaked.

I think this is bullshit. Eavesdropping on DNS queries and eavesdropping on the TLS handshake may happen in totally different networks.

[meliurwen]

I think this is bullshit.

I restrained to carry here the drama and assertions made in that convo but yeah, I completely share your disappointment.

[allo-]

Yes, but maybe they are open to change it in the (near?) future. And maybe using DoH will become more feasible as ISPs offer DoH servers and there may be some way to automatically configure them, so ESNI support is still interesting. Or did you mean, that the setting is not needed when DoH is enabled and won't do anything when DoH is not used?

[meliurwen]

Yes, but maybe they are open to change it in the (near?) future.

I have doubts for the near future looking at the direction Mozilla took in the last years but I hope so.

Or did you mean, that the setting is not needed when DoH is enabled and won't do anything when DoH is not used?

I mean that at the moment having only network.security.esni.enabled = true or network.security.esni.enabled = false in Firefox is exactly the same. It's a dummy option that does literally nothing until you specifically activate the their integrated tunnel (you cannot use other DoT/DoH tunnels).

# Not actual code, it's just to be more clear :P
if network.security.esni.enabled and FF_DoH.enabled:
    esni_enabled = True
else:
    esni_enabled = False

So integrating network.security.esni.enabled only is misleading because gives the illusion that something is activated but it doesn't. If you want to add this option, at the moment, I suggest you to add mandatory options for their integrated DoH engine in order to make it available to be toggled.

And maybe using DoH will become more feasible as ISPs offer DoH servers and there may be some way to automatically configure them, so ESNI support is still interesting.

It's not the point, having esni enabled or not shouldn't be related to your DNS solution. DoH/DoT are double edged swords because you cut every eavesdropper out (especially ISPs) and sometimes (like in this case) that "everyone" includes you/your organization because the perimeter starts from the engine integrated within the application and not from the border of your network or your machine.

Usually you want to read the traffic of your machine(s) in your network and maybe you also want to add custom resolutions for your intranet and filter out unwanted domains with a DNS at the border of the network with a DoH/DoT tunnel to some external DNS service(s).

[allo-]

Maybe a dropdown would be useful

• DoH (value 1?) + ESNI
• DoH default + ESNI
• DoH disabled (I think value 5)

But it mixes two settings.

It's not the point, having esni enabled or not shouldn't be related to your DNS solution. DoH/DoT are double edged swords because you cut every eavesdropper out (especially ISPs) and sometimes (like in this case) that "everyone" includes you/your organization because the perimeter starts from the engine integrated within the application and not from the border of your network or your machine.

What may be an advantage for many users. That's why the browsers are trying to establish it, because too many middle boxes are messing with traffic, also see why QUIC makes sure that no firewall tries to change its packets. For the user DoH would be a huge privacy feature, if there would be more privacy friendly servers. And from the infrastructure point of view is having application level DNS harder to debug.

But in the end we're discussing another setting here. I guess when ESNI is not a default yet, Mozilla will make it a default (for DoH users) sooner or later.

Another idea could be improving the website infrastructure to allow coupled settings ("you can only choose this when you activate DoH") but it isn't easy to get right the right UX:

• Do I need to go back and enable DoH?
• Should the new setting choose the right value for DoH?
• Should the generator make sure the options are ordered such that DoH comes before / after the setting?
• Should the DoH setting mention the settings, which do not work without DoH?)

[meliurwen]

Sorry for the late response, for the UX part the coupled settings is an interesting solution because it can potentially come handy with other future added settings.

ESNI and DNS settings shouldn't be related, the dependency relation they have is artificial and shouldn't be there.

Said this, and trying to answer the last 4 questions I suggest to: place the ESNI option somewhere after DoH options and is greyed out if DoH is disabled, between the title and the description is explained why the option is greyed out.

Here an example:

[allo-]

I guess this mockup should have an option to jump to the DoH option using an anchor. To decide if it should be disabled one would probably want a reload (save & next) of the DoH setting before this setting. And after jumping to DoH one would possibly want to jump back.

In the backend this may require some dependency handling. I guess it would be good to avoid having more than depth 1, to reduce the effort needed for checking dependencies.

For the frontend it is an interesting question if the greying out or not could work without Javascript as the redesign in #214 removes jquery and bootstrap scripts.

[meliurwen]

I guess this mockup should have an option to jump to the DoH option using an anchor.

👌

To decide if it should be disabled one would probably want a reload (save & next) of the DoH setting before this setting. And after jumping to DoH one would possibly want to jump back.

That would be a little bit annoying from the user's point of view, maybe better to keep the customization process linear, and btw both options roughly belongs to the same area. Keep both in the same tab/section so when the user clicks on the anchor the browser simply scrolls up a little bit?

I guess it would be good to avoid having more than depth 1.

Totally agree.

For the frontend it is an interesting question if the greying out or not could work without Javascript.

To disable the checkbox javascript is mandatory, the alternative would be to reload the page (of which I advise against this). A couple of lines of simple javascript are enough for the div to react at the change of state of the checkbox; more elegantly is possible to reach the same goal with only CSS.

as the redesign in #214 removes jquery and bootstrap scripts.

I don't understand how this is related; a couple of lines of custom javascript or/and css are enough.

OT: Good design on #244, nicer look and less ~bloat~ stuff to load! But be careful with binding so much frontend and backend: on the long run the amount of effort and knowledge (of the project code) required to make changes can risk to grow exponentially like a rolling snowball.