User.js: network.security.esni.enabled

Created on 11 Jan 2019  Â·  7Comments  Â·  Source: arkenfox/user.js

Should we toggle that? It is false by default.

Most helpful comment

I see on the bugzlla there is a linked access denied depends on bug. I'm guessing there's a reason why it's not enabled yet.

Just doing a little searching and it seems that besides not being ready for primetime, it also needs DoH to be enabled in order for it to work. We don't advise DoH (not knocking DoH, it's great in some situations). IDK, maybe we can include it in the user.js for info only?

All 7 comments

I see on the bugzlla there is a linked access denied depends on bug. I'm guessing there's a reason why it's not enabled yet.

Just doing a little searching and it seems that besides not being ready for primetime, it also needs DoH to be enabled in order for it to work. We don't advise DoH (not knocking DoH, it's great in some situations). IDK, maybe we can include it in the user.js for info only?

Right, seems to be still a working draft, and even after enabling CloudFlare test shows it does not work for me (maybe related to DoH not being enabled though). At least we should keep it in mind for when it’s ready. ;)

IMHO it doesn't harm to enable it right now, so when DoH requirement is lifted, it would be already enabled. We just need to make a clear warning that it doesn't work for now.

@earthlng bump .. what are your thoughts?

mine

  • we don't encourage DoH (but it is a useful and valid mechanism for those who need it)
  • network.security.esni.enabled is not in the user.js
  • but it may never be flipped, in which case we will never revisit it
  • am OK with adding it, but definitely as inactive

feel free to draft a PR

AFAIK DoH is not a "requirement" for ESNI per se.

see https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-1

Although TLS 1.3 [RFC8446] encrypts most of the handshake, including
the server certificate, there are several other channels that allow
an on-path attacker to determine the domain name the client is trying
to connect to, including:

  • Cleartext client DNS queries.
  • Visible server IP addresses, assuming the the server is not doing
    domain-based virtual hosting.
  • Cleartext Server Name Indication (SNI) [RFC6066] in ClientHello
    messages.

DoH deals with the 1st point whereas ESNI addresses the 3rd. If the attacker is not between you and fe your ISP's DNS, then you don't need DoH for ESNI to still have an effect, I believe.

but it may never be flipped, in which case we will never revisit it

I think they will definitely flip it eventually. It seems to be still in the drafting phase and is fairly new tech so probably almost nobody is using it yet. And there could also be bugs etc. IMO best to ignore for now. By adding it to the user.js we kind of encourage people to try it and I don't think we should do that.
Just my 2 cents

OK, but I'll add it to the sticky reminder

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Thorin-Oakenpants picture Thorin-Oakenpants  Â·  3Comments

Thorin-Oakenpants picture Thorin-Oakenpants  Â·  7Comments

Just-me-ghacks picture Just-me-ghacks  Â·  6Comments

Thorin-Oakenpants picture Thorin-Oakenpants  Â·  5Comments

Thorin-Oakenpants picture Thorin-Oakenpants  Â·  5Comments