[Building Sakai] Java 7 and Tomcat SSL connections

Thu Jun 20 07:24:36 PDT 2013

I would also recommend offloading SSL to a more suitable provider,
such as Apache httpd or some other web server. App servers like Tomcat
shouldn't be futzing with that level of the connection. In the
meantime, AJP and the "Tomcat Native Extensions" package will get a
more reliable SSL provider than what's built into Java.
David Adams
Director, Systems Integration and Support
Virginia Tech Learning Technologies

On Wed, Jun 19, 2013 at 2:02 AM, Stephen Marquard
<stephen.marquard at uct.ac.za> wrote:
> Hi Mike,
>
>
>
> There are 2 additional options:
>
>
>
> Install the Apache Portal Runtime (APR) which then uses OpenSSL, not java
> code (as I understand it)
>
> Front each app server with an apache httpd for SSL connections, and use AJP
> to the app server (if you need direct access to each app server for
> webservices)
>
>
>
> Regards
>
> Stephen
>
>
>
> From: Michael Osterman [mailto:ostermmg.sakai at gmail.com]
> Sent: 17 June 2013 11:44 PM
> To: Stephen Marquard
> Cc: Omer A Piperdi; sakai-dev at collab.sakaiproject.org
>
>
> Subject: Re: [Building Sakai] Java 7 and Tomcat SSL connections
>
>
>
> Hi Stephen,
>
>
>
> Thanks for this report! If I read the bug database correctly, Oracle plans
> to fix it in Java 8, and someone from the OpenJDK community plans to merge
> it in:
>
> http://mail.openjdk.java.net/pipermail/security-dev/2013-May/007589.html
>
>
>
> So if you're serving SSL directly from Tomcat, your options are:
>
> Use Java 6
> Use Java 7 with bouncycastle
> Use OpenJDK 7 when/if they integrate the patch
> Live with intermittent SSL failures
>
> Is that about right?
>
>
>
> -Mike
>
>
>
> On Thu, Jun 13, 2013 at 8:41 AM, Stephen Marquard
> <stephen.marquard at uct.ac.za> wrote:
>
> Hi Omer,
>
>
>
> We have been running JDK 1.7.0_21 in production since Monday, with Tomcat
> 7.0.40 and the bcprov-jdk15on-149 JCE as below.
>
>
>
> So far the garbage collection performance in 1.7 with the G1 collector is a
> huge improvement on JDK 1.6. We have only seen one glitch so far, which was
> that one of the app servers started taking much longer to do the initial SSL
> handshake (on the direct SSL port in Tomcat), up to around 400ms. Restarting
> the app server solved the issue.
>
>
>
> Our JAVA_OPTS include:
>
>
>
> -server -d64 -Xms5000m -Xmx5000m -XX:MaxPermSize=768m -XX:+UseG1GC
> -XX:MaxGCPauseMillis=3000 -verbose:gc -XX:+PrintGCApplicationStoppedTime
> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
> -Djava.awt.headless=true -Dnetworkaddress.cache.ttl=60
> -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
> -Dsun.lang.ClassLoader.allowArraySyntax=true -Dhttp.agent=Sakai
> -Djava.net.preferIPv6Addresses=false -Djava.net.preferIPv4Stack=true
> -Djava.util.Arrays.useLegacyMergeSort=true
>
>
>
> Some of the settings in there may no longer be necessary. The
> "java.util.Arrays.useLegacyMergeSort" setting is specifically for Java 7
> (see https://jira.sakaiproject.org/browse/KNL-1083)
>
>
>
> Regards
>
> Stephen
>
>
>
> ________________________________
>
> From: sakai-dev-bounces at collab.sakaiproject.org
> [sakai-dev-bounces at collab.sakaiproject.org] on behalf of Omer A Piperdi
> [omer at rice.edu]
> Sent: 13 June 2013 05:03 PM
> To: sakai-dev at collab.sakaiproject.org
> Subject: Re: [Building Sakai] Java 7 and Tomcat SSL connections
>
> We are currently running 2.9.x on Java 6, planning to upgrade this summer..
> Any idea or suggestion on whether we should stay with latest Java 6 (e.g.
> JDK 1.6.45) or not? We also use direct Tomcat connection for web services
> calls.
>
> Thanks
> Omer
>
> On 6/10/2013 1:38 PM, Stephen Marquard wrote:
>
> Hi all,
>
>
>
> Maybe this will save someone some Googling.
>
>
>
> We recently switched our production servers to Oracle JDK 1.7.0_21 using the
> G1 garbage collector to address some GC problems (with excellent results so
> far, though early days).
>
>
>
> Sadly recent versions of JDK 1.7.0 have a bug in the SSL code which causes
> intermittent failures for SSL connections using DH ciphers. Gory details:
>
>
>
> http://mail.openjdk.java.net/pipermail/security-dev/2013-May/007435.html
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014618
>
>
>
> If your Tomcat is configured to serve SSL connections directly (e.g. on port
> 443 or 8443), then you may be affected by this bug. The symptoms is that
> some connections simply fail to connect (the SSL handshake fails). However,
> if all your connections to Tomcat are via AJP (e.g. port 8009) or HTTP then
> you won't be affected. We use port 8443 on our app servers for SOAP
> webservice connections, so as a result had random failures on webservice
> calls (Tomcat 7.0.40). Our 8443 connector is defined in Tomcat's server.xml
> as:
>
>
>
>  <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
>
>                maxThreads="150" scheme="https" secure="true"
>
>                clientAuth="false" sslProtocol="TLS" />
>
>
>
> The workaround (prior to a later 1.7.0 JDK release with a fix) is to use the
> BouncyCastle JCE provider code as an alternative to the Oracle JCE code. You
> can do this by downloading bcprov-jdk15on-149.jar from:
>
>
>
> http://www.bouncycastle.org/latest_releases.html
>
>
>
> and installing as per
>
>
>
> http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation
>
>
>
> i.e. copy the jar into jre/lib/ext (in your JDK installation, not Sakai
> installation), and update jre/lib/security/java.security.
>
>
>
> In our case we listed the bouncycastle provider in position #2 which seemed
> to work:
>
>
>
> #
>
> # List of providers and their preference orders (see above):
>
> #
>
> security.provider.1=sun.security.provider.Sun
>
> security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
>
> security.provider.3=sun.security.rsa.SunRsaSign
>
> security.provider.4=sun.security.ec.SunEC
>
> security.provider.5=com.sun.net.ssl.internal.ssl.Provider
>
> security.provider.6=com.sun.crypto.provider.SunJCE
>
> security.provider.7=sun.security.jgss.SunProvider
>
> security.provider.8=com.sun.security.sasl.Provider
>
> security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
>
> security.provider.10=sun.security.smartcardio.SunPCSC
>
>
>
> One side-effect is that app servers take longer to initially respond to SSL
> connections after startup - it seems the bouncycastle code takes a while to
> generate a keypair (the CPU goes up for a while).
>
>
>
> Regards
>
> Stephen
>
>
>
> ________________________________
>
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www..uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the author.
> If you are not the intended recipient of the e-mail you may not use,
> disclose, copy, redirect or print the content. If this e-mail is not related
> to the business of UCT it is sent by the sender in the sender's individual
> capacity. !DSPAM:2294,51b61d1b137623371864040!
>
> _______________________________________________
>
> sakai-dev mailing list
>
> sakai-dev at collab.sakaiproject.org
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
>
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
>
>
> !DSPAM:2294,51b61d1b137623371864040!
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"