sniproxy
sniproxy copied to clipboard
dlundquist
Encrypted SNI (ESNI)
I guess once ESNI starts to spread (not sure if that's going to happen anytime soon), sniproxy won't work anymore - at least not without without decrypting the traffic. Correct?
As I understood it, ESNI must be enabled by the server admin by publishing some DNS records. As long as an sniproxy instance doesn't publish these DNS records, nothing changes.
ESNI uses different keys than the actual TLS connection. So sniproxy could be compatible with ESNI, and still not have access to the certificate private key. It would only need access to the key material of ESNI (which will allow it to decrypt the encrypted SNI, but not the connection that follows)
ESNI uses different keys than the actual TLS connection. So sniproxy could be compatible with ESNI, and still not have access to the certificate private key. It would only need access to the key material of ESNI (which will allow it to decrypt the encrypted SNI, but not the connection that follows)
I suspect that snipoxy determine the initial forwarding operation with reading the domain name in SNI. According to the existing draft, the public key for ESNI encryption is released based on DNS. The private key for decrypting ESNI is obviously only owned by the target server. Sniproxy seems to be unable to obtain the private key to unlock the encrypted information of ESNI.
And the ESNI standard is still the draft.
Sniproxy seems to be unable to obtain the private key to unlock the encrypted information of ESNI.
It depends on the use-case. I use sniproxy for routing requests to backend servers, so I can share an ESNI key with my sniproxy instance. If you use sniproxy for outbound routing, it'd be a different story, then you may have a problem with ESNI.
Good question, thanks for bringing this to my attention. Short of mounting a brute force attack or taking the https://xkcd.com/416/ approach, once the SNI extension is encrypted there isn't much we can do.
I found a solution for those who want to use sniproxy for outbound routing as well. If you combine it with a DNS server that blocks ESNI-lookups (TXT _esni.example.com), the browser will not observe that the server supports ESNI and send the hostname in plain text. I didn't find anything in the draft indicating that the server itself will indicate that it supports ESNI. The only thing that could prevent this from working is:
Client MAY cache the ESNIKeys for a particular domain based on the TTL of the Resource Record
Alternatively, the user may disable TLS 1.3, because TLS 1.2 doesn't support ESNI.
@dlundquist It seems that the writers have thought about software like sniproxy as well; they call such servers Client-Facing Servers. https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-3.1
Hi @jornane,
As far as I know, enabling ESNI in Firefox require turning on TRR mode(DNS over HTTPS). So You can't force the user(at least Firefox users) to use your DNS server.
I think the solution works only when the user is using your DNS server.
I think the solution works only when the user is using your DNS server.
This is correct for outgoing connections, but in order to use sniproxy for outgoing connections, you need to make changes to your clients anyway. This is simply one extra change that has to be made.
In order to use sniproxy for incoming connections, no changes need to be made for the client, because the esni-keys will be known in that case.
For the outgoing case - for the fixed set of compared hosts (no wildcards, nor regex) - would it be possible to compare encrypted strings instead of trying to decrypt them? This would mean that sniproxy be able to encrypt hosts in configuration file with the respective public keys retrieved from DNS.
would it be possible to compare encrypted strings instead of trying to decrypt them?
Yes, until the keys change, which can basically be any time.
I checked the ESNI spec - checking encrypted strings is not possible, there is nonce there, so no two requests will have the same encrypted strings...
It seems like ESNI is replaced by ECH. Mozilla blogged about this last year: https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/
I did not look at the specifics, but it sounds previous designs (should they exist :)) would also be applicable here.
So maybe rename the issue?
