Re: [TLS] Query regarding generating client_write_key.

[Joshua Davies <[e-mail]>]

On the contrary - the entire SSL handshake is sent in the clear - this is
why its important that both sides keep a running digest of the entire
handshake sequence and compare notes at the end, after encryption keys have
been exchanged (see RFC 2246, 7.4.9).  The first encrypted message in the
handshake is the "finished" message.  If you're using Wireshark/Ethereal to
sniff packets, it will decode the protocol details for you - if you're using
a non-standard port (say, testing on 8443), you'll need to select
analyze->decode as->SSL.

On Thu, Sep 29, 2011 at 12:50 PM, Tayade, Nilesh <[e-mail]
> wrote:

> Thanks a lot Davies. The source code was a lot helpful.****
>
> ** **
>
> Also I have another query – while observing the https packets on wire, I
> could see besides the SYN, SYN-ACK, ACK rest all the packets are encrypted.
> ****
>
> So after the socket is created (ACK from client is sent) – the client-hello
> is sent from client side in case of TLS/SSL. But what is this message
> encrypted using? The certificates aren’t exchanged yet, so we don’t know
> server’s keys.****
>
> ** **
>
> *From:* Joshua Davies [mailto:[e-mail]]
> *Sent:* Wednesday, September 28, 2011 10:03 PM
> *To:* Tayade, Nilesh
> *Cc:* [e-mail]
> *Subject:* Re: [TLS] Query regarding generating client_write_key.****
>
> ** **
>
> Are you implementing TLS 1.0/1.1 or TLS 1.2?  The PRF changed in 1.2.****
>
> ** **
>
> The PRF is by far the most complex part of the implementation - if you
> really want to understand it, I'd recommend chapter 6 of my book ; )
>  However, you can download the companion source code for free from
> http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20implementing_ssl_gcc.zip;
> take a look at the ch06/prf.c file.  It was written to be as straightforward
> and self contained as possible, and it includes a standalone main routine
> that you can use to pass in arbitrary secrets/seeds/labels and see exactly
> what the PRF function generates.****
>
> ** **
>
> On Tue, Sep 27, 2011 at 3:53 AM, nilesh <[e-mail]>
> wrote:****
>
> Hi,
>
> I am new to the TLS/Cryptography and started working on decrypting the
> packets over SSL/TLS.
> I have followed the RFC2246, 5246.
>
> To start decoding the packets, I need to have symmetric keys
> (client_write_key/server_write_key).
> I have the key_block, IV and MAC. As per the rfc:
>
> client_write_key = PRF{key_block[32..36], client_random, server_random,
> some_string}[0..31];
> And I have started writing PRF (pseudo-random function) somewhat like:
>
> <snip>
> /*
>  input : has 5bytes data i.e. key_block[32..36];
>  salt1 == client_random, salt2 == server_random, salt = 'A'.
> */
> for (i = 0; i < 2; i++)
> {
>        MD5_Init(&md5);
>        MD5_Update(&md5, (unsigned char *) &input[0], 3);
>        // MD5_Update(&md5, shasig, 20);
>        MD5_Final((unsigned char *)&md, &md5);
>
>        SHA1_Init(&sha);
>        SHA1_Update(&sha, pad, i + 1);
>        SHA1_Update(&sha, (unsigned char *) &input[2], 3);
>        SHA1_Update(&sha, salt1, 32);
>        SHA1_Update(&sha, salt2, 32);
>        SHA1_Final(shasig, &sha);
> }
> </snip>
>
> Now, we need to XOR the md and shasig to get the bytes in client_write_key.
>
> Queries:
> 1. The md5 generates 16bytes and SHA1 generates 20bytes so xor will be
> 20bytes.
> But the key we expect should be 32bytes (iterated the MD5/SHA1 twice for
> that). How could this be achieved?
> 2. Any suggestions on if the PRF() is designed somewhere? Pointers on how
> it could be designed?
>
> I tried several ways, but getting the wrong key. Could someone please
> advice?
>
> --
> Thanks,
> Nilesh
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls****
>
> ** **
>