Hello!
I am trying to decode the CertificateVerify structure, but have thus far
failed.
I have access to both client and server 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
there should be a
struct {
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
But this certainly isn't one (for ex. none of the bytes could make for a
length info for the signature field). 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 is correct.
Regards,
Vandra Ákos
