Subject: [TLS] TLS1.2 CertificateVerify deocding

From: Akos Vandra <[email-masked]>
Date: Wed, 15 Jul 2009 10:37:34 +0200

Hello,

I have written to half a dozen mailing lists, but never got an answer.
This is why I am contacting you, in spite of the fact that I don't
think my email is on-topic here.

I am a student doing some research on the inner workings of TLSv1.2,
for implementation on a custom hardware.

Currently I am sniffing traffic between gnutls-serv and gnutls-cli,
and trying to work out each bytes meaning (yeah I am a little bit
crazy, but this helps me understand the protocol top to bottom. :)

I am trying to decode the CertificateVerify structure, but have thus far failed.
I have access to both client(512bit) and server(1024bit) keys, and
have sniffed their
communication, what I came up with
(along the stream) is this CertificateVerify packet sent from the
client to the server:

0x16, 0x03, 0x03, 0x00, 0x46,
0x0f, 0x00, 0x00, 0x42, 0x00, 0x40, 0xe4, 0xe9,
0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67,
0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d,
0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6,
0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48,
0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49,
0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30,
0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b,
0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3

As far as I know, this means the next things:

TLSPlainText.
 ContentType = 0x16 (Handshake)
 ProtocolVersion = 0x03, 0x03,
 Length = 0x00, 0x46,
 Fragment = Handshake
TLSPlainText.Handshake.
  HandshakeType = 0x0f (certificate_verify)
  Length = 0x00, 0x00, 0x42,
  Body = CertificateVerify
TLSPlainText.Handshake.
CertificateVerify
    Length = 0x00, 0x40,   <-- The RFC doesn't say that there should
be a length info here, but
this certainly is the remaining part's length.
    Data = 0xe4, 0xe9,
           0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67,
         0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d,
         0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6,
         0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48,
         0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49,
         0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30,
         0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b,
         0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3

I tried decoding this signed data with openssl (successfully), it yielded:

$openssl rsautl -verify -inkey clientkey.pem -in sign.bin -hexdump

0000 - 47 f6 a5 1b a9 cb 4a a6-90 63 2c 65 ec 6f 6d 20
0010 - 10 af a8 f0 f0 80 0d 99-a3 22 cf 2b 07 b0 a4 c8
0020 - c7 ec 1d 33

My question is how to interpret this data? From the rfc I understood
that this should be a .DER encoded

    struct {
       SignatureAndHashAlgorithm algorithm;

       opaque signature<0..2^16-1>;
    } DigitallySigned;

But this certainly isn't one (for ex. the second byte which should be
a length byte is way too long).
What am I missing?
I am not sure what is the hash that should be calculated, so I am not
sending that along, because I
don't think it would be correct.

Thanks in advance for your help,
 Vandra Ákos

---

From: [email-masked]
Date: Wed, 15 Jul 2009 10:23:10 +0100

>>On Wed 15/07/09 9:37 AM , Akos Vandra [email-masked] sent:
>>Hello,
>>

Refer to RFC 5246, section 7.4.1.4.1 - this is not DER encoded - SignatureAndHashAlgorithm are just two octets I think. First octet is hash algorithm - second is signature algorithm.