Hey all,

First time poster, long time listener here!

Don't know if this is of interest to you guys, but I just had a nasty 
surprise with the same code running under JDK7 breaking when it worked 
under JDK6.

It's specifically to do with handling SSL connections, it seems that JDK7's 
SNI support can trigger throwing an SSLProtocolException because of 
handshake alerts. Reported as 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374 and closed as 
"not an issue".  A workaround is to set a system property. Confirmed for 
myself on JDK6 and 7 with a site I set up - works on 6, exception on 7 by 
default, works on 7 with workaround.

It seems reasonable to me that this would be the default behaviour for good 
security practises, but I'm surprised that the attitude is that this 
breaking change is not an issue. At first glance, the workaround can only 
be applied globally to a JVM, so I can't connect to servers with this 
problem selectively, it's all or nothing. That seems pretty poor given the 
abilities to override other security behaviours like trust checking and 
hostname verification.

I know there are good security reasons why you wouldn't want to do this in 
general, but I don't think that it should be forbidden or global. I think 
I'm working on an example at the moment, writing a lib to check things like 
status codes and performance of web resources. I can't get through to check 
details about what's being served without ugly exception handling and 
string hacking.

Interested in your thoughts!

-- 
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to