Thank you for your response. The problem is solved, and I can now
decode the whole TLS stream, thanks.
FYI, what I found out if you are interested:
I have dug the source code to find out what is happening in the mean
time, and found that the signed data is MD5++SHA1, but I have been
calculating the wrong hashes. (No algorithm identifier though)
I couldn't make the link between digitally-signed and signature
entities, if they are the same they should have the same name, or it
could be mentioned somewhere in the text, that could be easily
searchable, I say.
And yeah, this is just test data, I was using the 512 bit keys to make
the stream somewhat shorter.
TLS1.1 surely specifies that the signed data is MD5++SHA1, but this is
nowhere to be found in the TLS1.2 specification.
2009/7/17 Dave Thompson <dave.thomp...@princetonpayments.com>:
>> From: owner-openssl-us...@openssl.org On Behalf Of Akos Vandra
>> Sent: Tuesday, 14 July, 2009 13:34
>
>> 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
> <snip>
>> As far as I know, this means <snip>
>> 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, <snip>
>
> Yes it does say so. 4346 7.4.3 says Signature is (assuming RSA)
> digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }
> and 4.7 says digitally-signed "is encoded as an opaque vector <0..2^16-1>
> where the length is specified by the signing algorithm and key."
> 4.3 says vector has a prefix length, which for that range is 2 octets.
> The size of an RSA signature is the same as the modulus, which
> for your case obviously is 64 bytes = 512 bits. (You do know RSA-512
> has been factorable = insecure for years now, right? Of course
> if this is only test/debug data its security doesn't matter.)
>
>> 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;
>
> Not in TLS1.0 or 1.1 for sure. It should be two (fixed-length) hashes
> as above, and it is (36 bytes = 16 + 20). I don't know if 1.2 changed.
>
>> 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.
>
> Per 7.4.8, the hash(es) should be of all the handshake messages so far.
> This is the same idea as used (later) for Finished.
>
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-us...@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
