Re: [TLS] Verify data in the RI extension?

[Michael D'Errico <[e-mail]>]

Bodo Moeller wrote:
> On Nov 28, 2009, at 9:41 AM, David-Sarah Hopwood wrote:
>>
>>   struct {
>>       enum { fake_finished(20) } fake_handshake_type;
>>       enum { zero(0), (2^24-1) } fake_length;
>>       opaque previous_client_verify_data<12..255>;
>>       opaque previous_server_verify_data<12..255>;
>>   } PreviousVerifyData;
>>
> (Encoding the actual combined length of the previous_..._verify_data 
> fields seems simpler to analyze -- this still wouldn't be a valid 
> Finished message; or hash an empty Finished first, then a pseudo-message 
> containing the previous verify data.  Of course, neither of this avoids 
> the potential problem with buggy receivers that ignore out-of-sequence 
> messages.  That pseudo-message *could* use the Certificate type to 
> maximize the probability that buggy implementations will look at it and 
> stop [given that Certificate is expected at that point of the protocol], 
> but I guess that looks even weirder.)

Encoding a longer length is even better since that will suck some of the
real Certificate message into the fake Finished message, making it
impossible for the handshake to complete.  How much longer?  Why not just
use the maximum length of 0xFFFFFF?

Mike