Hi, This client now interoperates with Cloudflare and the https://defo.ie copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and ISC licenses. It won't be merged until draft-06 is out, at a minimum.
https://github.com/ctz/rustls/pull/318/files I found some things confusing in the draft: 1) The draft uses field names that carry a lot of weight, but they're not always explained in prose. 2) I think the draft could benefit from a more procedural description of the steps required, like one might read in a WHATWG draft. This preference could just be what I'm used to, though. 3) It's not clear what to do if the server doesn't consult the (E)SNI at all. For example, Cloudflare doesn't seem to check things for big clients like medium.com, which presumably have a dedicated IP. In newer PRs and proposals, should a bogus encrypted SNI from the client trigger a retry request even if the server doesn't need the SNI? 4) The draft seems to require more precise explanation around the key exchange, since it uses some functions from the TLS 1.3 key schedule in a novel way. I saw weird names and patterns in both rustls and NSS. For example, in rustls, the secret input "Z" ended up being named "premaster_secret". It works, but there's a semantic mismatch. thanks, Rob [0] Example: https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-) On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <say...@gmail.com> wrote: > Hi, > > I think I have a working ESNI client, but I'm encountering a strange error > testing with Cloudflare. > > I initially tested with "cloudflare.com", but found this was a bad idea, > because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI > triggered no errors. > > When my client sends an ESNI to a Cloudfront-fronted domain, I get a > handshake_failure error (40). According to the -02 draft, this should only > happen if the server fails to negotiate TLS 1.3. I've got my client > configured for TLS 1.3 only, so this shouldn't be an issue. When I add an > unencrypted SNI to an otherwise identical ClientHello, everything works > over TLS 1.3. If there are problems with my ESNI encryption, I should see > other errors. Things like "illegal_parameter" or "decrypt_error", right? > > In Wireshark, I can at least see that my encrypted_server_name extension > matches Firefox's cipher and key share entries, and the lengths of > record_digest and encrypted_sni are the same. Firefox does send some > extensions I don't, like ALPN. Does the absence of unencrypted SNI imply > the presence of other extensions? > > I also wondered about extension order. Since the ClientHello.key_share is > part of the ESNI calculation, does it need to appear first in the > extensions list? > > thanks, > Rob >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
