Jetty
  1. Jetty
  2. JETTY-567

Delay in initial TLS Handshake With FireFox 3 beta5 and SslSelectChannelConnector

    Details

    • Type: Wish Wish
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 6.1.9, 7.0.0pre0
    • Fix Version/s: 6.1.15.pre0
    • Component/s: Security and SSL
    • Labels:
      None
    • Environment:
      Firefox 3.0 beta5 for Windows XP, Jetty 6.1.9 and 7.0.0pre0, jdk 1.6 on Windows XP
    • Number of attachments :
      3

      Description

      When using Firefox 3.0 beta5, the first time the browser connects to Jetty, it tries to use the TLS protocol. The handshake fails, and then falls back to SSL, which succeeds.

      The fallback is instantaneous when using the SslSocketConnector, however it takes 30 seconds when using the SslSelectChannelConnector. So the initial page takes 30 seconds to load. After that, all is ok until Firefox is restarted.

      This delay is determined by the value set for maxIdleTime (i.e. if I change the value to 10000, the delay is reduced to 10 seconds).

      This problem only occurs with SslSelectChannelConnector and Firefox 3. The problem doesn't occur with SslSocketConnector or other servers. The problem does not occur when using Firefox2 or IE7 - the page loads instantaneously.

      Although reducing maxIdleTime is a functional workaround (are there disadvantages in doing so?), I think this should be solved - especially since SslSelectChannelConnector and 30000 are the default settings in Jetty 7, and NIO is necessary for continuations...

      here's a snippet of ssl debug for the initial handshake:

      Using SSLEngineImpl.
      btpool0-5, READ: TLSv1 Handshake, length = 158 <-[this is where it stops for 30 seconds]
      btpool0-5, called closeOutbound()
      btpool0-5, closeOutboundInternal()
      btpool0-5, SEND TLSv1 ALERT: warning, description = close_notify
      btpool0-5, WRITE: TLSv1 Alert, length = 2
      btpool0-5, fatal error: 80: problem unwrapping net record
      javax.net.ssl.SSLException: Unexpected end of handshake data
      btpool0-5, SEND TLSv1 ALERT: fatal, description = internal_error
      btpool0-5, Exception sending alert: java.io.IOException: writer side was already closed.
      Using SSLEngineImpl.
      btpool0-6, READ: SSL v2, contentType = Handshake, translated length = 79

          • ClientHello, SSLv3
            .....
      1. Java6SslEngineBug.java
        2 kB
        Greg Wilkins
      2. jetty.txt
        4 kB
        Jan Bartel
      3. tomcat.txt
        2 kB
        Jan Bartel

        Activity

        Hide
        David Yu added a comment -

        Note:

        The fix simply detects the signature of the bug and then close the connection (fail-fast) so that ff3 will delegate to using SSL instead of TLS.
        This is a jvm bug on java1.6 where the SSLEngine expects more data from the initial handshake when the client(ff3) already had given it.

        The expected state transition:
        NOT_HANDHSAKING
        unwrap()
        NEED_TASK (need to interpret data)
        NEED_WRAP (need to respond)

        The state transition when the bug happens:
        NOT_HANDSHAKING
        unwrap()
        NEED_TASK (need to interpet data)
        NEED_UNWRAP (need more data??? bug)

        Show
        David Yu added a comment - Note: The fix simply detects the signature of the bug and then close the connection (fail-fast) so that ff3 will delegate to using SSL instead of TLS. This is a jvm bug on java1.6 where the SSLEngine expects more data from the initial handshake when the client(ff3) already had given it. The expected state transition: NOT_HANDHSAKING unwrap() NEED_TASK (need to interpret data) NEED_WRAP (need to respond) The state transition when the bug happens: NOT_HANDSHAKING unwrap() NEED_TASK (need to interpet data) NEED_UNWRAP (need more data??? bug)
        Hide
        Joakim Erdfelt added a comment -

        I'm receiving some test failures on jetty-ssl that might be related.
        NOTE: This is an intermittent failure.

        testRequestJettyHttps(org.mortbay.jetty.security.SSLEngineTest) Time elapsed: 33.615 sec <<< ERROR!
        javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:117)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1650)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:739)
        at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
        at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
        at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at org.mortbay.jetty.security.SSLEngineTest.readResponse(SSLEngineTest.java:220)
        at org.mortbay.jetty.security.SSLEngineTest.testRequestJettyHttps(SSLEngineTest.java:173)

        Using JDK 1.5.0_15 (Sun) on Linux ia32 (ubuntu hardy), using Maven 2.0.9 (release)

        Show
        Joakim Erdfelt added a comment - I'm receiving some test failures on jetty-ssl that might be related. NOTE: This is an intermittent failure. testRequestJettyHttps(org.mortbay.jetty.security.SSLEngineTest) Time elapsed: 33.615 sec <<< ERROR! javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:117) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1650) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:739) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.mortbay.jetty.security.SSLEngineTest.readResponse(SSLEngineTest.java:220) at org.mortbay.jetty.security.SSLEngineTest.testRequestJettyHttps(SSLEngineTest.java:173) Using JDK 1.5.0_15 (Sun) on Linux ia32 (ubuntu hardy), using Maven 2.0.9 (release)
        Hide
        Greg Wilkins added a comment -

        I've tried to get Sun to open a bug on this issue and have created a small reproducible test harness that demonstrates the problem.

        I raised a report on the 13/Feb/2009 and received an internal bug number 1455259, but have yet, it's not been escalated to real bug.

        Show
        Greg Wilkins added a comment - I've tried to get Sun to open a bug on this issue and have created a small reproducible test harness that demonstrates the problem. I raised a report on the 13/Feb/2009 and received an internal bug number 1455259, but have yet, it's not been escalated to real bug.
        Hide
        Greg Wilkins added a comment -

        Reopening, because we need to chase Sun until the JVM is really fixed.

        Show
        Greg Wilkins added a comment - Reopening, because we need to chase Sun until the JVM is really fixed.
        Hide
        Greg Wilkins added a comment -

        well sun shows no interest in fixing the bug.
        we have a work around now in Jetty, so that the delay is avoided.
        If anybody still gets the delay, please reopen.

        Show
        Greg Wilkins added a comment - well sun shows no interest in fixing the bug. we have a work around now in Jetty, so that the delay is avoided. If anybody still gets the delay, please reopen.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dan Ruthers
          • Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: