Please allow regular ESNI (without DoH)

NEW
Unassigned

Status

()

enhancement
P5
normal
6 months ago
9 days ago

People

(Reporter: darkspirit, Unassigned)

Tracking

({feature, nightly-community})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 attachments)

(Reporter)

Description

6 months ago
Posted image screenshot.png
Debian Testing

STR:

servo.org is hosted on Cloudflare and has an ESNI record:
$ dig TXT _esni.servo.org +short
"/wFBbh+pACQAHQAgWOxePWsGi6pv7H58y0Qutk223JzeuZLmCra5UQFsbU4AAhMBAQQAAAAAW8UqAAAAAABbzRMAAAA="

But it doesn't seem to work with Nightly:
$ mozregression --launch 2018-10-18 --pref network.security.esni.enabled:true -a https://servo.org/cdn-cgi/trace
> fl=75f21
> h=servo.org
> ip=2003:[censored]
> ts=1539908194.146
> visit_scheme=https
> uag=Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
> colo=HAM
> spdy=h2
> http=h2
> loc=DE
> tls=TLSv1.3
> sni=plaintext

Screenshot = https://www.cloudflare.com/ssl/encrypted-sni/

Actual:
> sni=plaintext

Expected:
> sni=encrypted
https://tools.ietf.org/html/draft-ietf-tls-esni-01
It's so cool that Firefox wants to support this.
DoH is not part of the ESNI standard, just mentioned as one way to ensure authenticity and privacy, so I would expect that ESNI just works if it's enabled. Could this be an OS-related problem?
(Reporter)

Comment 1

6 months ago
Posted image unbound.png
With our regular dns configuration it looks basically the same.
> DoH is not part of the ESNI standard

No, but DoH is required by Firefox to get ESNI going so please first make sure you have that enabled!
(Reporter)

Comment 3

6 months ago
Thank you for supporting ESNI at all! :) But sorry for the misunderstanding.

I have two concerns, while not knowing your general plans:
* ESNI shouldn't be artifically restricted to DoH.
  I would assume that Firefox has a mature DNS library or would switch to c-ares or will oxidize[1] to TRust-DNS[2] sooner.
  Adding this to the appropriate meta bug for later would be fine, but awesome if it would be just a small change.

  [1] https://wiki.mozilla.org/Oxidation
  [2] https://github.com/bluejekyll/trust-dns

  * ESNI should be enabled by default at a later stage:
    If someome is not part of an organization and doesn't have a secure DNS via VPN, DoH or DoT,
    ESNI would still protect TLS connections leaving the ISP
    to prevent combination of intercepted Source IP + SNI with other tracking intel.
    If problems are expected with corporate environments, it could be disabled by default for ESR.
OS: Linux → All
Hardware: x86_64 → All
Summary: Regular ESNI doesn't seem to work → Please allow regular ESNI (without DoH)
Priority: -- → P5
Whiteboard: [necko-triaged]

Comment 4

6 months ago
I have tested with Stubby and Dnscrypt-Proxy with DOT and DOH.
It seems to fail the ESNI test. May I know why?

Stubby: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
Dnscrypt-Proxy: https://github.com/jedisct1/dnscrypt-proxy
(Reporter)

Comment 5

6 months ago
https://twitter.com/bagder/status/1052994271459123201
> "I'm wondering why DoH is a requirement to enable ESNI?"
> For technical reasons. That's the only code for "raw" DNS packet handling we have in Firefox.

They want to get a foot in the door for ESNI. This seems to be an absolute MVP as
* there's currently no support for ESNI using the system's resolver (this bug),
* enforcing long-term privacy breaks ESNI (bug 1500526), and
* you can't even enforce SNI privacy for testing purposes.
So I assume we just have to be patient.

Comment 6

13 days ago

I use dnscrypt-proxy found at https://github.com/jedisct1/dnscrypt-proxy which already has DoH/ESNI implemented, so Firefox should be able to detect that and be aware of it, that way I don't have configure DoH in Firefox to ensure ESNI working.

You need to log in before you can comment on or make changes to this bug.