Re: [TLS] Record layer corner cases
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Record layer corner cases



On Tue, Nov 28, 2006 at 03:00:31PM +1300, Peter Gutmann wrote:
> Peter Williams <home_pw at msn.com> writes:

>> Out of interest Peter and Martin, how well do your software and hardward
>> modules handle the following change from SSL v2 to SSL v3, including fallback
>> handling as specified by SSL3, and then the TLS fallback mechanisms?
>> 
>> "SSL Version 3 supports the transmission and reception of "out of band data".
>> Out of band data is normally defined at the TCP/IP protocol level, but
>> because of SSL's privacy enhancements and support for block ciphers, this
>> becomes difficult to support.

> I don't handle it at all, if my code sees OOB data in the middle of a TLS
> stream it flags it as a network-level error (my security model is default-
> deny).  I've never seen OOB data used and can't imagine why it'd ever be used
> except as a potential attack vector targetting corner cases in TLS
> implementations.

The above quote is from the SSL patent, which does mention
"SSL Version 3" -- but it's not really about what we know as SSL 3.0,
it only describes the SSL 2 protocol design.  The patent says that
"currently there are several versions of the novel SSL", and there the
"novel SSL" is what we know as SSL 2 and variants thereof.  What
eventually was fielded as SSL 3.0 is, of course, a very different
protocol.

The SSL 2 protocol design provides for a "security escape" flag in
record headers ("reserved for future versions of the protocol"),
which would be used to tag out-of-band data.  That and now TCP-leve
out-of-band data is what the above patent text is talking about.
(As noted there, handling TCP out-of-band data would be difficult
within SSL.)

Bodo


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.