[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Hubert Kario]

On Thursday 08 October 2015 17:37:12 Viktor Dukhovni wrote:
> On Thu, Oct 08, 2015 at 04:12:50PM +0000, Hubert Kario via RT wrote:
> > The server does not abort connection upon receiving a Client Hello
> > message with malformed session_id field.
> > 
> > Affects 1.0.1, 1.0.2 and master.
> > 
> > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is
> > defined as
> > 
> >       opaque SessionID<0..32>;
> > 
> > that means, that any SessionID longer than 32 bytes creates an
> > incorrectly formatted Client Hello message, and as such, should be
> > rejected.
> 
> Can be rejected, and perhaps even should be rejected, but I don't
> see a MUST here.  It seems there's little harm in tolerating longer
> session ids (which never match, so are effectively ignored).

RFC 5246:
   decode_error
      A message could not be decoded because some field was out of the
      specified range or the length of the message was incorrect.  This
      message is always fatal and should never be observed in
      communication between proper implementations (except when messages
      were corrupted in the network)

(yes, it's not a MUST either, but I'm afraid that this was simply "too 
obvious" for designers of protocol)

> So yes, I support adding a check for this (likely above the PACKET
> layer), but I don't think this has much urgency and likely should
> not be back-ported to stable releases.

oh, sure, that particular problem isn't a serious issue, but I'm going 
through all fields and all messages so that we have full coverage (e.g. 
for valgrind)

also, accepting bigger session id's means that the session cache code is 
exercised in ways that it usually isn't, that's not a good thing to 
happen (even if it handles them correctly, as it seems, defence in depth 
is a good idea anyway)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151008/3f35566c/attachment.sig>