secure netty creates new TLS contexts on each connection #111

Closed
bblfish opened this Issue Mar 12, 2012 · 6 comments

Comments

Projects
None yet
2 participants
Contributor

bblfish commented Mar 12, 2012

This means ( I am reasonably confident ) that the TLS caching of client certificates won't work. I had written this up as a question on stack exchange Netty https ( TLS ) Session duration: why is renegotiation needed? a few months ago, but I think my recent commit on the Play code fixes it.

    lazy val context = {
      val res = SSLContext.getInstance("TLS")
      initSslContext(res)
      res
    }

    def createSslContext = {
      context
    }

essentially the context becomes a lazy val. ( Looking at the code now it looks like I would just have needed to transform the createSslContext into a lazy val.

By placing a few logging statements at the right place I found that this seemed to allow the VM to find the client sessions in its cache, and not have to ask the client for the certificate again. As I am just working with the Play code I did not have time to check that on the unfiltered code used by readwriteweb X509Cert class in the webid branch

Contributor

bblfish commented Mar 12, 2012

Btw. The code I wrote on github for Play2.0 works for Java 6 on OSX but not for Oracle's latest java7 where it blocks (it did not have that effect on the older java7 I was using previously). Essentially I can connect to the server once - it asks me for my client certificate - but then if I do that with another browser it blocks.

It would be worth trying to see how your changes in the previous issue you fixed work on java 1.7.0_04-ea . ( I also tried the developer releases from OpenJDK , with the same result )

I think I am pretty confident that one should reuse the same context. After all there is a method called getDefaultContext on SSLContext

Contributor

bblfish commented Mar 12, 2012

Btw, I made the licence include you.

https://github.com/bblfish/Play20/blob/2e6e1c27bae5a21fec32daa9cde8779d0ac6f0c8/framework/src/play/src/main/scala/play/core/server/NettyServer.scala

I suppose later it would be quite easy to reseperate the code, but for the moment it is easier to work like this.

Contributor

bblfish commented Mar 13, 2012

Ok, I tried the code on Java 7 final on Solaris and it works, so the bug on OSX which consumed a lot of my time is clearly a OSX java preview bug.
There is an exception being throw by Chrome but I posted a bug report for that on netty
netty/netty#232

Owner

n8han commented Mar 18, 2012

I've wasted time tracking down a number of things in different projects that turned out to be OSX java preview bugs. :)

I'm changing createSslContext to a lazy val and will run the tests against that for both Java 6 and 7 (a no preview release of it!).

Owner

n8han commented Mar 18, 2012

Interesting, I get a test failure on openjdk 7 independent of these changes:

[error] x A Secure Server should
[info] + respond to secure requests
[error] x refuse connection to unsecure requests
[error] org.apache.http.client.ClientProtocolException should have been thrown. Got: org.apache.http.NoHttpResponseException: The target server failed to respond (DefaultResponseParser.java:101)

I'm not sure if we're failing in the best way there. But that would be a separate bug. This change looks fine.

n8han closed this in 7cf999b Mar 18, 2012

Contributor

bblfish commented Mar 18, 2012

cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment