On 25/09/2011 17:39, Konstantin Kolinko wrote: > 2011/9/25 Mark Thomas <ma...@apache.org>: >> On 25/09/2011 17:11, kkoli...@apache.org wrote: >>> Author: kkolinko >>> Date: Sun Sep 25 16:10:59 2011 >>> New Revision: 1175421 >>> >>> URL: http://svn.apache.org/viewvc?rev=1175421&view=rev >>> Log: >>> Mention when support for RFC 5746 was added. >>> >>> As far as I am reading Tomcat-Navive changelog, >>> it does not have implementation for this new renegotiation protocol. >> >> It should have. It is entirely provided by OpenSSL. >> > > Oops. > It needs some time to sort this in my mind > > > Then I think the > http://tomcat.apache.org/security-native.html > has to be updated with more specific version numbers, like I did for > 5.5, 6.0 and 7.0 pages. > >> Also, search >> http://tomcat.apache.org/native-doc/miscellaneous/changelog.html for >> renegotiation. The APR/native HTTP connector fully supports control of >> whether or not legacy negotiation is supported via the >> allowUnsafeLegacyRenegotiation attribute of the connector. > > I did so, but the changelog mentions only > "Add support for unsafe legacy renegotiation." (1.1.21) > which is unrelated to RFC 5746. > > The native security page says "From 1.1.18 onwards, client initiated > renegotiations are rejected". So it sounds that they are rejected, > regardless of RFC 5746. > > Both of the above resulted in my confusion. > > The native code does not check for "TLS_EMPTY_RENEGOTIATION_INFO_SCSV" > cipher, unlike JSSESocketFactory used by not-native connectors, > nor AprLifecycleListener prints status of this feature support at > Tomcat startup.
The one thing I didn't check was if client initiated renegotiation was re-enabled once the allowUnsafeLegacyRenegotiation option was implemented and I don't know the code well enough to know where to look without some research. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
