Hi Bernd, * [email protected] <[email protected]> [2015-11-16 15:17]: > I brought this up before, and agree with you that it is a good idea: > if the server sends the alert and treats it fatal there is no problem > in at least trying to continue. It is also not a security problem > because the certificate will be validated (and if it is indeed the > wrong server it will be noticed). > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374 > > I am not sure why it was rejected, most likely because of the unclear > warning semantics. However I thi k there is no problem in continuing, > either the server cooperates or not, the client will notice. Other > implementations handle this less picky and still work.
I just wanted to clarify that this is slightly different from my proposal. This bug suggests that if the server sends a *fatal* alert the client should continue. This goes against the specification. RFC 5246 says: "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection." So, I am not sure if not following the RFC is a good idea or not. Maybe it will be better, I am not sure. I haven't really looked into it. Do you know how browsers or other SSL/TLS clients handle this? What I am asking for is for a slightly different case: *warning* (not fatal) alerts to be treated differently. RFC 5246 states: "If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection." It is this case where the specification allows OpenJDK a choice. OpenJDK can either treat a unrecognized_name warning alert as fatal (and abort) or non-fatal (and continue). Many other clients (including browsers such as Firefox and Chrome) continue normally in the presence of a unrecognized_name warning alert. From that point of view OpenJDK should too. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
