it seems the parsing of HCertificateRequest in
 /sys/src/libsec/port/tlshand.c:^msgRecv
uses the wrong lengths for the length fields.

The existing code fails to parse HCertificateRequest for me in
the tls handshakes of 802.1x-eap-ttls sessions on UTwente campus.

this fix seems to do the right thing -- it makes things work for me,
and it is backed up by rfc2246.txt, see the details below.
nevertheless, please doublecheck it is indeed correct
(that's why I'm including the rfc quotes below) --
I'm kind-of surprised by the seeming need to fix this -- then again,
of course, I have no idea how much this code has been exercised.

Axel.

details:

The error in the lenght of the length fields seems to be confirmed
by rfc 2246 (TLS):

page 7 of rfc2246.txt discusses the encoding and lenght of length fields:

   Variable length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation <floor..ceiling>.  When
   encoded, the actual length precedes the vector's contents in the byte
   stream. The length will be in the form of a number consuming as many
   bytes as required to hold the vector's specified maximum (ceiling)
   length. A variable length vector with an actual length field of zero
   is referred to as an empty vector.

       T T'<floor..ceiling>;

page 42 of rfc2246.txt discusses the CertificateRequest:

       opaque DistinguishedName<1..2^16-1>;

       struct {
           ClientCertificateType certificate_types<1..2^8-1>;
           DistinguishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;

so, it seems 1 byte (instead of 2) suffices for certificate_types
and 2 bytes (instead of 3) suffice for certificate_authorities.