Hi, This code works with medium.com (hosted by Cloudflare). I was previously testing with a parked domain. Maybe there's some signaling needed when the handshake fails based on Split Mode / Shared Mode configuration.
thanks, Rob On Sat, Oct 26, 2019 at 7:43 PM Rob Sayre <say...@gmail.com> wrote: > As an update, > > I seem to be able to negotiate a handshake with "only.esni.defo.ie", but > I must be making a mistake in my ClientHello. Wireshark sees Firefox's > ClientHello as TLS 1.3, but mine only shows up as TLS 1.0, although the " > only.esni.defo.ie" ServerHello does show up as TLS 1.3. You check out the > details on that host at https://defo.ie/ . > > My client fails to read application data after that, although the server > does seem to send it. > > You can check out my fork of Rustls here: > https://github.com/grafica/rustls > > If you then do something like: > $ cd rustls/rustls-mio/ > $ cargo run --example esniclient > > you should see some ESNI traffic. Some of the code in the fork is a little > messy so far, but it's still in the "make it work" phase. :) > > thanks, > Rob > > > 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
