Re: Next Protocol Negotiation TLS Extension
Hi, On Fri, Mar 22, 2013 at 1:08 AM, Brad Wetmore bradford.wetm...@oracle.com wrote: Hi Simone, I haven't looked at the proposal yet, but just from a scheduling point of view, unfortunately we're finishing up the implementation of the last of the planned features for JDK 8, so getting this into 8 is likely not possible. Likely not possible means totally impossible or if you do this and that, then it's possible ? :) Do you know the status of JEP 114 ? Will it be shipped in JDK 8 ? We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. Ok, if impossible I will eventually pop up again when JDK 8 is released and JDK 9 work started. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: Next Protocol Negotiation TLS Extension
On 3/25/2013 6:59 AM, Simone Bordet wrote: Hi, On Fri, Mar 22, 2013 at 1:08 AM, Brad Wetmore bradford.wetm...@oracle.com wrote: Hi Simone, I haven't looked at the proposal yet, but just from a scheduling point of view, unfortunately we're finishing up the implementation of the last of the planned features for JDK 8, so getting this into 8 is likely not possible. Likely not possible means totally impossible or if you do this and that, then it's possible ? :) I would never say totally impossible, but closer to totally impossible than likely not possible. Do you know the status of JEP 114 ? Will it be shipped in JDK 8 ? That is still the expectation. We had to pull 114 temporarily because of a conflict in two projects, and we'll be working on resolving the merge when the engineer is back from vacation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009925 We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. Ok, if impossible I will eventually pop up again when JDK 8 is released and JDK 9 work started. Planning for JDK 9's features will start well before that. Some of the dev work will already be underway by release. Brad Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Next Protocol Negotiation TLS Extension
Hi all, [cross-posted to jdk8-dev and security-dev] I am a member of the Jetty servlet container (http://eclipse.org/jetty) team and the implementor of the Next Protocol Negotiation (NPN) TLS Extension used by Jetty to support the SPDY protocol (API at http://git.eclipse.org/c/jetty/org.eclipse.jetty.npn.git/ and implementation at https://github.com/jetty-project/jetty-npn). The SPDY protocol has been chosen as the basis for HTTP 2.0. I would like to ask for suggestions for what would be the best way to have NPN support in OpenJDK 8 rather than via the Jetty NPN implementation. Currently, the Jetty implementation is kind of hacky in that it is the smallest possible hack (in a positive meaning) to make NPN work in OpenJDK. It modifies 5 sun.security.ssl.* classes and introduces 5 new classes. These modifies classes must be put in the bootclasspath. The API of public classes like SSLEngine is not modified; instead the current implementation relies on a static class that maps SSLEngine (or SSLSocket) with application code that is invoked at the right time during the TLS handshake when NPN data is detected. Currently, the Jetty project maintains the NPN implementation locked with OpenJDK releases: every time the sun.security.ssl.* classes are modified, we pull in the changes from OpenJDK, re-patch these classes with NPN support and make a new release of the NPN jar. The NPN TLS extension requires an API exposed to applications (usually web servers, but they are applications for the Java runtime). In this sense, JEP 114 (http://openjdk.java.net/jeps/114, SNI TLS extension) is similar: I am guessing it also has to expose an API to applications. It seems to me that both NPN and SNI would require a standard way to access TLS extensions at the proper time during the TLS handshake. In light of this, it would be great if NPN could be piggybacked on JEP 114, exposing a standard TLS extensions API provided by OpenJDK that application can use to plug in their code for NPN and/or SNI. Now, I understand that designing a TLS extensions API is not as simple as including the current Jetty NPN implementation in OpenJDK, but I would rather see a generic solution in OpenJDK rather than a hacky solution like current Jetty NPN's included in OpenJDK. A private TLS extensions API already exists in the sun.security.ssl.* classes, but it's mostly package private and of course under sun.* packages. So perhaps the work to be done is not a from-scratch effort. I would like to get a discussion started on how NPN can be supported in OpenJDK 8. Ideally, my best plan would be: * NPN included in JEP 114. * JEP 114 designing a standard TLS extensions API that can serve for both NPN and SNI (and, generically, others TLS extensions) * JEP 114 shipped in OpenJDK 8. We're happy to keep Jetty NPN up-to-date for OpenJDK 7 releases, but we will really like to see NPN in OpenJDK 8. We are open to comply with any legal papers that needs to be in place for this contribution. I will be more than happy to provide detailed information about the implementation of Jetty NPN and have it discussed (or even reviewed) by security experts. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: Next Protocol Negotiation TLS Extension
Am 21.03.2013, 17:01 Uhr, schrieb Simone Bordet simone.bor...@gmail.com: I would like to ask for suggestions for what would be the best way to have NPN support in OpenJDK 8 rather than via the Jetty NPN implementation. Is the Jetty solution related to the JSSE patch from Ben Murphy? https://github.com/benmmurphy/ssl_npn I was using this code for some SSL related tests, it is convinient to have a Github with Runtime code :) * NPN included in JEP 114. * JEP 114 designing a standard TLS extensions API that can serve for both NPN and SNI (and, generically, others TLS extensions) * JEP 114 shipped in OpenJDK 8. ... and some additional negotiation control code to help against excessive renegotiation attacks. Does Jetty have a fix here, as well? Gruss Bernd -- http://bernd.eckenfels.net
Re: Next Protocol Negotiation TLS Extension
Hi Simone, I haven't looked at the proposal yet, but just from a scheduling point of view, unfortunately we're finishing up the implementation of the last of the planned features for JDK 8, so getting this into 8 is likely not possible. We have an open bug for this (JDK-8007785) and it's on the radar for JDK 9. I'll put in a link to your email in that bug. I know Xuelei will want to look at this more closely, and I hope to also. Brad On 3/21/2013 9:01 AM, Simone Bordet wrote: Hi all, [cross-posted to jdk8-dev and security-dev] I am a member of the Jetty servlet container (http://eclipse.org/jetty) team and the implementor of the Next Protocol Negotiation (NPN) TLS Extension used by Jetty to support the SPDY protocol (API at http://git.eclipse.org/c/jetty/org.eclipse.jetty.npn.git/ and implementation at https://github.com/jetty-project/jetty-npn). The SPDY protocol has been chosen as the basis for HTTP 2.0. I would like to ask for suggestions for what would be the best way to have NPN support in OpenJDK 8 rather than via the Jetty NPN implementation. Currently, the Jetty implementation is kind of hacky in that it is the smallest possible hack (in a positive meaning) to make NPN work in OpenJDK. It modifies 5 sun.security.ssl.* classes and introduces 5 new classes. These modifies classes must be put in the bootclasspath. The API of public classes like SSLEngine is not modified; instead the current implementation relies on a static class that maps SSLEngine (or SSLSocket) with application code that is invoked at the right time during the TLS handshake when NPN data is detected. Currently, the Jetty project maintains the NPN implementation locked with OpenJDK releases: every time the sun.security.ssl.* classes are modified, we pull in the changes from OpenJDK, re-patch these classes with NPN support and make a new release of the NPN jar. The NPN TLS extension requires an API exposed to applications (usually web servers, but they are applications for the Java runtime). In this sense, JEP 114 (http://openjdk.java.net/jeps/114, SNI TLS extension) is similar: I am guessing it also has to expose an API to applications. It seems to me that both NPN and SNI would require a standard way to access TLS extensions at the proper time during the TLS handshake. In light of this, it would be great if NPN could be piggybacked on JEP 114, exposing a standard TLS extensions API provided by OpenJDK that application can use to plug in their code for NPN and/or SNI. Now, I understand that designing a TLS extensions API is not as simple as including the current Jetty NPN implementation in OpenJDK, but I would rather see a generic solution in OpenJDK rather than a hacky solution like current Jetty NPN's included in OpenJDK. A private TLS extensions API already exists in the sun.security.ssl.* classes, but it's mostly package private and of course under sun.* packages. So perhaps the work to be done is not a from-scratch effort. I would like to get a discussion started on how NPN can be supported in OpenJDK 8. Ideally, my best plan would be: * NPN included in JEP 114. * JEP 114 designing a standard TLS extensions API that can serve for both NPN and SNI (and, generically, others TLS extensions) * JEP 114 shipped in OpenJDK 8. We're happy to keep Jetty NPN up-to-date for OpenJDK 7 releases, but we will really like to see NPN in OpenJDK 8. We are open to comply with any legal papers that needs to be in place for this contribution. I will be more than happy to provide detailed information about the implementation of Jetty NPN and have it discussed (or even reviewed) by security experts. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
