Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Xuelei Fan]

On 5/30/2013 1:06 AM, Bernd Eckenfels wrote:
> Hello Xuelei,
> 
> This is nice to hear. BTW: my own Bug in that direction never made it through review, maybe you want to reference ist a well. Not Public: 2381456
> 
Would you mind send me the link of the bug, or the code review request
mail?  I may miss some mails about this direction.

> There is a number of Security Advisories for this weakness (generic ones, mainly mentioning other implementations). It might be worth to acknowlege one of the CVEs or Issue your own one (I certainly have customers which noticed lack of it).
> 
Good suggestion.  Oracle provider of JSSE had addressed the TLS
renegotiation issue in JDK 1.4.2 update 26, JDK 1.5.0 update 24 and JDK
6u 19 around the end of 2009 and the beginning of 2010.  Here is the
readme of the fix:
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html.

> As I understand the spec you could, instead of rejecting also ignore the request. Did you consider making it a 3-state? (you can currently force the Same terminating behaviour with an empty cipher suite).
> 
I did consider to ignore or warning the request instead of a fatal
closure.  But it bring in extra complexity, and hard to handle in both
client and server.

> You mentioned industry will move to a secure handshake - are you aware of any initiative in that direction?
> 
See http://www.rfc.org/rfc/rfc5746.txt.  As far as I know, nearly all
major vendors of SSL protocols has support RFC5746.

Xuelei

> PS: i still would prefer to allow applications deal with this by having a syncronous handshake listener (would could then count handshake frequency and close the socket).
> 
> Bernd
>