Re: [TLS] Rizzo claims implementation attach, should be interesting

["Yngve N. Pettersen" <[e-mail]>]

On Thu, 29 Sep 2011 16:13:03 +0200, Martin Rex <[e-mail]> wrote:

> Yngve N. Pettersen wrote:
>>
>> Martin Rex wrote:
>>
>> > Marsh Ray wrote:
>> > >
>> > > I believe there was a mitigation put in place by OpenSSL: sending an
>> > > empty (just padding) message before each app data message.
>> > >
>> > > I read somewhere that this mitigation was off by default in OpenSSL
>> > > because it [breaks] some software (an old MSIE IIRC).
>> >
>> > Why using a EMPTY (just padding) SSL record?  That looks like an
>> > obvious untested border case.
>> >
>> > How about using an initial SSL record with one byte of real data
>> > for SSLv3 and TLSv1.0 SSL with CBC cipher suites?
>>
>> According to my testing, this breaks about as many websites,
>> unfortunately, approximately 0.15% of tested websites.
>
> What exactly did you do?  did you fragment the client's
> finished handshake message as well (which is the first protected
> message on a TLS connnection) ?  As previously mentioned, I would
> expect this to cause interop problems, whereas I have a slight
> hope that fragmenting only application data might work.

The test only used a split record for application data, and was only  
performed if the server supported on of the CBC ciphersuites supported by  
the prober, and a successful HTTP request for / without split record had  
been sent earlier in the test.

Determining failure required detecting two successive failures that either  
did not return a response at all, or a 400+ error code that was not the  
same as was received in the baseline request. (200/300 was considered a  
success regardless )

Five different split policies were tested (0, 1, 2, blocksize-1, blocksize  
-2 bytes), each with or without having the blocks in the same TCP record.  
The above number was with the two records in the same TCP record (as that  
had a significantly lower failure rate).

The above numbers is the combined failure rate for servers that support  
AES, or only support 3DES. (AES is presumed to be selected by these  
servers).

I have previously seen HTTPS servers mishandle two HTTP requests in the  
same record (the second was ignored); my guess is that this is the same  
thing: An assumption that a single SSL/TLS Application record contain just  
a single, complete HTTPS request. My guess is that the responsible servers  
are front-ends, firewalls or similar, not servers like Apache with modSSL  
or IIS.

At least one server return "ET is not a recognized HTTP method",  
apparently having dropped the record with the "G" part of the request.

BTW: 0.045% failed all 5 of the tests, so I consider it likely that there  
is no split policy that will work for all servers.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************