[jbosstools-issues] [JBoss JIRA] (JBIDE-17284) OpenJDK seem to have issues with SSL/TLS handshakes when using URLConnection

[Rich Lucente (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-17284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975799#comment-12975799 ] 

Rich Lucente commented on JBIDE-17284:
--------------------------------------

More detail regarding how I can consistently reproduce this issue.  I was experimenting with running JBDS remotely and accessing it via HTML5 inside a web browser.  Details for this setup are here [https://github.com/rlucente-se-jboss/jbds-via-html5].  When I click on the "Java EE Web Project" link in the JBoss Central pane (or any link that securely reaches out to github), the IDE will crash.  If I remove support for the Mozilla NSS provider in /usr/lib/jvm/java-1.7.0-openjdk.x86_64/jre/lib/security/java.security then the crash doesn't occur.  The error seems to be related to setting up a TLS connection to github.  Keep in mind that my remote install of JBDS is nowhere near standard.  For instance, jbdevstudio is installed in /usr/share/jbdevstudio and not in the user's home directory.  Also, the SELinux context for the directory matches the other files under /usr/share.

The Mozilla NSS provider is enabled in /usr/lib/jvm/java-xxx-openjdk/jre/lib/security/java.security at line:
{noformat}
# the NSS security provider was not enabled for this build; it can be enabled
# if NSS (libnss3) is available on the machine. The nss.cfg file may need
# editing to reflect the location of the NSS installation.
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
{noformat}
The hs pid error trace showed it crashing in the same place.

I searched for native libraries in my /usr/share/jbdevstudio install and I found the following:
{noformat}
[root at rhel6vm2-rlucente jbdevstudio]# find . -type f -name '*.so'
./studio/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20140116-2212/eclipse_1508.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnssckbi.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libxul.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnss3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libsoftokn3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnspr4.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libssl3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libfreebl3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnssdbm3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libjavaxpcomglue.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnssutil3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libmozjs.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libxpcom.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libsmime3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libplc4.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libsqlite3.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/components/libimgicon.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/components/libmozgnome.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/components/libdbusservice.so
./studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/components/libnkgnomevfs.so
{noformat}
These include the NSS and NSPR libraries from the Mozilla Network Security Services.  What I think is happening is that during TLS negotiation, the github server is requesting elliptic curve encryption.  Java falls through the providers and settles on the SunPKCS11 which uses the NSS native libraries.  At this point I think that the dynamic library load order is a mix of /lib64 and the jbds native libraries.  The mismatch is causing SIGSEGV to occur.

There are three work-arounds to this issue that I explored.  The first is to disable the SunPKCS11 provider, but that would disable it for every java user on the host.  The second is to force the use of the JBDS native libraries via LD_LIBRARY_PATH, although these lag the latest RHEL patches for NSS and NSPR.  The third work-around that I just tried is to ensure that the needed dependencies are installed with the latest versions in RHEL.  The package list I believe is needed is:
{noformat}
yum -y install nspr nss nss-softokn nss-softokn-freebl nss-util xulrunner
{noformat}
However, when I tried that I got a GConf error and the same SIGSEGV crash, so LD_LIBRARY_PATH, even though it's using older versions of NSS, seems to be the most stable workaround since it doesn't eliminate the SunPKCS11 provider for other java users on the same host.


> OpenJDK seem to have issues with SSL/TLS handshakes when using URLConnection
> ----------------------------------------------------------------------------
>
>                 Key: JBIDE-17284
>                 URL: https://issues.jboss.org/browse/JBIDE-17284
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: common/jst/core, openshift, upstream
>            Reporter: Max Rydahl Andersen
>            Assignee: Snjezana Peco
>            Priority: Critical
>             Fix For: 4.2.0.Beta3
>
>
> We've received multiple reports about instant crashes of users running JBoss Tools and Developer Studio.
> The common issue is that it happens when they use OpenJDK vm, not Oracle.
> The crash log normally contains something similar to:
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(J[Lsun/security/pkcs11/wrapper/CK_ATTRIBUTE;)J+0
> j  sun.security.pkcs11.P11ECKeyFactory.generatePublic(Ljava/security/spec/ECPoint;Ljava/security/spec/ECParameterSpec;)Ljava/security/PublicKey;+170
> j  sun.security.pkcs11.P11ECKeyFactory.engineGeneratePublic(Ljava/security/spec/KeySpec;)Ljava/security/PublicKey;+80
> j  java.security.KeyFactory.generatePublic(Ljava/security/spec/KeySpec;)Ljava/security/PublicKey;+25
> j  sun.security.ssl.HandshakeMessage$ECDH_ServerKeyExchange.<init>(Lsun/security/ssl/HandshakeInStream;Ljava/security/PublicKey;[B[BLjava/util/Collection;Lsun/security/ssl/ProtocolVersion;)V+228
> Opening this bug to collect and use a key issue for hunting down the cause.
> Note: This issue is *not* specific to JBoss Tools as far as I can see, but it does affect us since we lookup a file located behind https url at key times which seem to trigger the crash.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)