Details
-
Type:
Wish
-
Status:
Resolved
-
Priority:
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 :
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
.....
- ClientHello, SSLv3
-
Activity
Actually, Greg, the SslSelectChannelConnector is defined in etc/jetty-sslengine.xml in v6.1.11 - not etc/jetty-ssl.xml ... as Dan points out in the initial description, using the SslSocketConnector (as defined in etc/jetty-ssl.xml) instead of the SslSelectChannelConnector would be a second workaround.
you might want to fix the report so the Sun guys can reproduce the bug more accurately 
This posting on the jetty support list from 16th January 2008 sounds as if it is related. I'll attach the jetty and tomcat output files separately:
Matt Doran wrote:
> Hi guys,
>
> We use Jetty as the embedded web server in our product (PaperCut). In fact, we're one of the case studies on the web tide site here <http://www.webtide.com/case_studies/>.
>
> We've recently upgraded our application to use Java 6 and Jetty 6.1.14 (from Jetty 5). And we've found that establishing an HTTPS connection to the server from Firefox 3 results in a 30 second delay (which doesn't occur using other browsers).
>
> After enabling the JRE's SSL debug logging and googling the errors I found, I came across your issue describing this problem (JETTY-567 <http://jira.codehaus.org/browse/JETTY-567>). So the underlying issue appears to be a bug in the Java SSL implementation. And Greg said that he'd raised the issue with Sun, but I couldn't find the issue in the Sun Bug database.
>
> This is a pretty serious bug, and I'm surprised that there aren't more people affected by this one!
>
> Does anyone have any news on this issue? Or had any feedback from Sun? Does anyone know if this affects other web servers (like Tomcat)?
>
>
>
fyi, I've just tried Tomcat on the same Java 6 VM, and it does not have the delay problem encountered in Jetty.
However analysis of the Java SSL debug logs, shows that it has the same TLSv1 handshake failure, but it doesn't wait the 30 seconds before falling back to the SSLv3 connection. I guess this is a difference in the implementations ... but maybe one of the Jetty developers can make sense of it and improve Jetty's behaviour in this case.
I've attached the SSL logging of a Firefox connection to Jetty 6.1.14 and Tomcat 6.0.18. You can see the TLSv1 handshake failures in both ... but they react in different ways. Jetty waits for more data from the client, and Tomcat fails with the "Unexpected end of handshake data" and moves on immediately.
Regards,
Matt
More information about this. It does not occur with JDK 1.5, only with JDK 1.6 .
To help replicate the problem, here's the instructions:
1. use latest production Sun JDK: JDK 1.6.0 update 6. \
java -version says: "Java(TM) SE Runtime Environment (build 1.6.0_06-b02)"
either Windows or Linux (32 bit)
2. use Jetty 6.1.10 stock installation. Simply edit etc/jetty-ssl.xml and set its content to:
-----------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<!-- =============================================================== -->
<!-- Configure SSL for the Jetty Server -->
<!-- this configuration file should be used in combination with -->
<!-- other configuration files. e.g. -->
<!-- java -jar start.jar etc/jetty.xml etc/jetty-ssl.xml -->
<!-- =============================================================== -->
<Configure id="Server" class="org.mortbay.jetty.Server">
<Call name="addConnector">
<Arg>
<New class="org.mortbay.jetty.security.SslSelectChannelConnector">
<Set name="Port">443</Set>
<Set name="maxIdleTime">30000</Set>
<Set name="keystore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
<Set name="password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="keyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="truststore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
<Set name="trustPassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<!-
<Set name="handshakeTimeout">2000</Set>-><!-- Set name="ThreadPool">
<New class="org.mortbay.thread.BoundedThreadPool">
<Set name="minThreads">10</Set>
<Set name="maxThreads">250</Set>
</New>
</Set -->
</New>
</Arg>
</Call>
</Configure>
-------------------------------------------------
this is the standard jetty-ssl.xml , the only difference is the class has changed to SslSelectChannelConnector , and the handshakeTimeout paramerter has been removed (it is not a supported setter in SslSelectChannelConnector, so leaving it in would cause an exception on startup).
3. in Firefox 3, open https://www.server.com (whatever the address of your server is)
4. .... there will be a 30 seconds delay before getting the home page. after the intial connection, all is fine until you restart FireFox
Again, this is a tricky one to pinpoint:
1. it only happens with FireFox 3 (beta5, and also RC1). FireFox 2, IE7, Safari all connect without the delay.
2. it only happens with SslSelectChannelConnector . Using the normal SocketConnector works.
3. it only happens with Java 1.6 . Java 1.5 does not give this problem.
Now, you may think these are quite strict conditions, so the problem would not be very common. However these are the latest versions of FireFox, Java and Jetty, so this problem will be very common, especially when FireFox 3 goes in production in a few days....