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 >
