On Thu, Oct 13, 2016 at 12:18:03PM +0300, Ilari Liusvaara wrote:
> On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote:
> > TLDR: the spec. was clear and easy to implement, but some test vectors
> > and clarification on what constitutes a Handshake Context would have
> > helped.
> > FWIW, please let me share my experience of implementing TLS 1.3.
> > This month, I have written a TLS 1.3 implementation (named picotls,
> > available at https://github.com/h2o/picotls) based on draft 16 from
> > scratch.
> Tried interop versus my own implementation (with my implementation
> as client).
> Didn't work... I traced the blowup to client_hello_decode_server_name():
> The sent contents of the SNI extension is:
> 00 0B 00 00 08 "h2o.test"
> Which AFAICT is a server name list of 11 bytes, containing entry of
> type 0 (host_name), with length 8 and name "h2o.test".
My implementation vs. picotls:
Ok, dumped the handshake using wireshark. Wireshark seems to think
the SNI with two lengths is perfectly sane.
I modified the picotls code to read the extra length.
Then I hit another issue: eckey_is_on_group seems to be busted: It
presumably should use == instead of !=, since it is presumably
supposed to return 1 if groups match, since it is used to check
if the key is P-256.
Couple of bugs in my code later, I could get successful handshake
with my code as client and picotls as server. Yay.
picotls vs my implementation:
Trying picotls as client and my code as server first hit the issue that
picotls doesn't send RSA-PKCS-V1.5 as supported, causing my
implementation to fail with no suitable certificate (it requires
algorithms for the chain too, not just the end key).
After defeating that check, the handshake got further, but something
in server's messages (ServerHello, EncryptedExtensions, Certificate,
CertificateVerify, Finished) made picotls crash (heap corruption as
evidenced by the malloc() error). Haven't debugged that error yet.
TLS mailing list