Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345654

Summary:	TLS Renegotiation should not be enabled by default
Product:	[RT] Jetty	Reporter:	Chad La Joie <clajoie>
Component:	server	Assignee:	Greg Wilkins <gregw>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	gunnar, jetty-inbox
Version:	unspecified
Target Milestone:	7.2.x
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Chad La Joie

2011-05-12 16:02:49 EDT

Build Identifier: 7.3.1

In SslContextFactory, TLS renegotiation is enabled by default.  A few years ago a vulnerability was discovered[1] in HTTPS that uses this feature.  A TLS extension[2] was added to address this, however I don't see any code checking to see if the client supports secure renegotiation.  If there isn't any such code (I very well may simply have missed it), then renegotiation support should be disabled by default.

[1] http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
[2] http://tools.ietf.org/html/rfc5746

Reproducible: Always

Comment 1 Greg Wilkins

2011-05-12 23:42:21 EDT

Chad,

the renegotiation enabling was added to jetty in response to that vulnerability and we initially set to disabled.

However, after several releases of JVM's and browsers that support rfc5746, we switched the default to enabled.

I can't see anything in the java SSLEngine API that would allow us to detect if RFC5746 is being supported?  Do you know of such a check?   If so, then we would use that anded with the boolean.

Comment 2 Greg Wilkins

2011-09-06 00:48:13 EDT

Chad,

I think the vulnerability has been fixed long enough now that we don't need to default to no renegotiation

Comment 3 Chad La Joie

2011-09-06 07:14:27 EDT

Personally I still think it should be disabled as the majority of browsers still in use today don't have the TLS patch.  But I understand that's just a matter of personal preference.