tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SSL & Tomcat
Date Mon, 09 Nov 2009 18:47:38 GMT
On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko
<knst.kolinko@gmail.com>wrote:

> 2009/11/9 Mark Thomas <markt@apache.org>:
> > Summarising the information gathered so far from various channels
> > (thanks to Bill B., Bill W. & Rainer who have done most of the actual
> > work to find the info below).
> >
> > BIO/NIO connectors using JSSE.
> > Vulnerable when renegotiation is triggered by the client or server.
> > We could prevent server initiated renegotiation (and probably break the
> > majority of configurations using CLIENT-CERT).
> > We can't do anything to prevent client initiated renegotiation.
> >
> > APR/native connector using OpenSSL
> > It is vulnerable when renegotiation is triggered by the client or by the
> > server.
> > Client triggered negotiation is supported.
> > Server triggered negotiation will be supported from 1.1.17 onwards.
> >
> > OpenSSL 0.9.8l disables negotiation by default
> >
> >
> > In terms of what this means for users:
> >
> > BIO/NIO
> > - There isn't anything we can do in Tomcat to stop client
> >  initiated renegotiation so it is a case of waiting for the JVM
> >  vendors to respond.
> >
> > APR/native
> > - Re-building their current version with 0.9.8l will protect
> >  users at the risk of breaking any configurations that
> >  require renegotiation.
> > - We can release 1.1.17 with the binaries built with 0.9.8l. This
> >  will also protect users at the risk of breaking any
> >  configurations that require renegotiation. Mladen is doing this
> >  now.
> > - Supporting renegotiation whilst avoiding the vulnerability will
> >  require a protocol fix. In the meantime, we could port port
> >  r833582 from httpd which would disable client triggered
> >  renegotiation for OpenSSL < 0.9.8l (which may help some users
> >  who can't easily change their OpenSSl version and release 1.1.18
> >  with this fix
> > - Once the protocol is fixed, release 1.1.next bundled with the
> >  appropriate version of OpenSSL
> >
> >
> > Have I got my facts right above? If so, any objections to posting the
> > above to the users@ and announce@ lists along with adding something to
> > the security pages?
> >
> > Mark
> >
>
> +1
>
> s/negotiation/renegotiation/
> s/port port/port/
>
> A question:
> My understanding of renegotiation is that it changes SSL session. Is
> it possible to observe changes in the value of SSL sessionId?  I doubt
> so, but may be?
>

AFAIK you can reuse the session ID across negotiations ( it's a nice
optimization BTW, too
bad we're not using, it can speed up SSL connections a lot ), I'm not sure
if it changes
within a renegotation, but AFAIK when you start any negotiation you can
specify you want
to reuse the old session id.  But if I understand the exploit correctly -
they would want a different
cypher, and if you reuse the session you reuse the old one.


Maybe we can modify JSSESupport.Listener to break the connection if
handshakeCompleted is
called > once in a connection ? That is besides disabling server-initiated
handshakes.

Costin



> We read that value once and provide it to our users as
> "javax.servlet.request.ssl_session" request attribute.
>
> Regarding valves (as mentioned in issue 48157):
> I understand, that that is not sufficient, but if anyone wants to
> check against malformed headers, they can do so.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message