How bad is its impact? (Severity)
- Likely to generate a customer support call
How often does it happen? (Frequency)
Any time a session renegotiation occurs on the server (running 1.6.0_22 or above) and the peer does not have a fix
How much effort is required to fix it? (Cost)
Minimal. All the fix accomplish is logging a message along the lines of:
"GRIZZLY0081: Secure SSL/TLS renegotiation is not supported by the peer. This is most likely due to the peer using an older SSL/TLS implementation that does not resolve security vulnerability CVE-2009-3555"
We should probably document this exception stating that the peer VM should be 1.6.0_22 or if the peer is a native application, it should have its SSL libraries
What is the risk of fixing it? (Risk)
Minimal (see the changes in the referenced issue for details)
Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes. See . However, doing so opens up the security hole that was fixed by not allowing insecure renegotiations.
If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
If this improved message isn't present, then we'll need to at least document what the default exception message/stacktrace
looks like and again, present the options of upgrading the peer, or opening the security hole back up.