Hi Mark, Am 15.04.2015 um 00:52 schrieb Mark Mielke:
> Java 6 on > Solaris defaults to the SSLv3 Hello, Um, no. As you found out for yourself in your subsequent mail, the default is using SSLv2-Hello, which is something different than the statement that it defaults to SSLv3. Java 6 already supports TLSv1 so the removal of SSLv3 shouldn't lead to any problems at all if the other side is capable of upgrading to TLS (which Java/Jetty is). As you found out later, this was a bug in the JDK, which - by the way - could have been solved by deactivating SSLv2-Hello on the Solaris-side since Java 6 is also capable of using the newer Client-Hello-formats in the TLS handshake as well. > So, I'm not saying the change to Jetty was wrong. The default probably > should be to block SSLv3. But, I think there can be an assumption made > by people using latest technology, that everybody else can as well. > Just because Google or some other company declares SSLv3 insecure, doesn't > mean that it can be disabled without consequence. Concerning Jetty and the bad habit of changing the API of the classes and therefor the format of the configuration files I agree with you in a way but concerning SSLv3 I think you see it wrong. Google didn't declare SSLv3 to be insecure but published a report showing flaws in SSLv3 and the whole security community decided that the points are valid and SSLv3 is considered to (finally) be dead because of this. So immediately disabling SSLv3 in newer versions of products is a Good Thing[TM] that everybody and their dogs were doing. Not all things considered insecure are blocked immediately by default BTW. TLSv1 and TLSv1.1 are still allowed by default despite the fact that they are vulnerable to attacks like BEAST and CRIME. > All change must be managed gracefully. Not all changes can be done gracefully. Heartbleed and POODLE are two examples where you can't wait for everybody to be ready for it, since it impacted the security of data transfers and I can only reiterate what I said in a previous mail: If you can only use SSLv3 you can switch off SSL completely since there is essentialy no difference in a plain connection and a SSLv3-"secured" one. And: The change in the default wasn't forced on you. It was your decision to update the Jetty Server making it your responsibility to test for side effects, which brings us to > In my case, I didn't even realize there would be an impact and it was a > production outage when it occurred. I did test all the common systems, > but I missed testing Solaris 8... This sounds like a manual testing process. You should consider setting up testcases that do the testing for you, so you can't miss a platform when doing changes. The name for this concept is Continuous Delivery and there are quite some books out there explaining the concept. You have to invest time to set it up but it will save you a s***load of time in the long run (e.g. when switching from Java 7 to Java 8 since Java 7 is EOL already as well). BTDT for quite some time (the list of things breaking when we switched from Java 6 to Java 7 was surprisingly long and would never have been found with manual testing alone). I'm in a quite similar situation as yourself giving support to customers and be in the responsibility to make sure that updates like the Jetty library doesn't break anything. But I think that the difference between us is the mindset. If something breaks after an update I don't blame the provider of the library for doing updates but my lack of testcases rasing a flag that something is breaking or my lack of concentration when reading through the list of changes for the library's update. Cheers, Lothar _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
