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

Thu Jun 12 17:55:38 EDT 2014

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

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

That works fine whether the NSS library is enabled or not.  I also removed the LD_LIBRARY_PATH so I wasn't favoring the JBDS bundled libraries.  I don't think the problem is manifested when using VPE, but instead when JBDS tries to establish a TLS connection.

The versions of the libraries installed with RHEL 6.5 on my setup (including latest patches) are:
{noformat}
nss.x86_64                          3.15.3-6.el6_5           @rhel-6-server-rpms
nss-softokn.x86_64                  3.14.3-10.el6_5          @rhel-6-server-rpms
nss-softokn-freebl.x86_64           3.14.3-10.el6_5          @rhel-6-server-rpms
nss-sysinit.x86_64                  3.15.3-6.el6_5           @rhel-6-server-rpms
nss-tools.x86_64                    3.15.3-6.el6_5           @rhel-6-server-rpms
nss-util.x86_64                     3.15.3-1.el6_5           @rhel-6-server-rpms
nspr.x86_64                         4.10.2-1.el6_5           @rhel-6-server-rpms
{noformat}
If I look at the advertised versions of libnss3.so packaged with JBDS based on the "objdump -x <file>" command:
{noformat}
Version definitions:
1 0x01 0x05a18a0f libnss3.so
2 0x00 0x03892642 NSS_3.2
3 0x00 0x09264891 NSS_3.2.1
4 0x00 0x03892643 NSS_3.3
5 0x00 0x09264791 NSS_3.3.1
6 0x00 0x03892644 NSS_3.4
7 0x00 0x03892645 NSS_3.5
8 0x00 0x03892646 NSS_3.6
9 0x00 0x03892647 NSS_3.7
10 0x00 0x09264b91 NSS_3.7.1
11 0x00 0x03892648 NSS_3.8
12 0x00 0x03892649 NSS_3.9
13 0x00 0x09264992 NSS_3.9.2
14 0x00 0x09264993 NSS_3.9.3
15 0x00 0x08926470 NSS_3.10
16 0x00 0x02647b82 NSS_3.10.2
17 0x00 0x08926471 NSS_3.11
18 0x00 0x02647c81 NSS_3.11.1
19 0x00 0x02647c82 NSS_3.11.2
20 0x00 0x02647c87 NSS_3.11.7
21 0x00 0x02647c89 NSS_3.11.9
22 0x00 0x08926472 NSS_3.12
23 0x00 0x02647d81 NSS_3.12.1
24 0x00 0x02647d83 NSS_3.12.3
25 0x00 0x02647d84 NSS_3.12.4
26 0x00 0x02647d85 NSS_3.12.5
27 0x00 0x02647d86 NSS_3.12.6
28 0x00 0x02647d87 NSS_3.12.7
29 0x00 0x02647d89 NSS_3.12.9
{noformat}
I believe what that all means is that a library that requires any of those versions of NSS when dynamically loading it can use the NSS bundled with JBDS.  This indicates to me that the version of libnss3.so bundled with JBDS is 3.12.9 since it's the highest reported version.  RHEL 6 with all updates applied is using 3.15.3.

I started jbdevstudio using strace to see where the libraries are being loaded from with no LD_LIBRARY_PATH:
{noformat}
 strace -ff -o jbds -ttt -x -s 4096 /usr/share/jbdevstudio/jbdevstudio -nosplash -data $HOME/workspace &
{noformat}
The relevant output for nss libraries being loaded was:
{noformat}
1402606672.301854 open("/lib64/libnss_files.so.2", O_RDONLY) = 3
1402606674.129796 open("/lib64/libnss_dns.so.2", O_RDONLY) = 14
1402606699.583935 open("/usr/share/jbdevstudio/studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnssutil3.so", O_RDONLY)        = 142
1402606699.585376 open("/usr/share/jbdevstudio/studio/plugins/org.mozilla.xulrunner.gtk.linux.x86_64_1.9.2.19pre/xulrunner/libnss3.so", O_RDONLY) = 142
{noformat}
So, it's looks like a mix of /lib64 and jbds xulrunner native libraries are being loaded.  When I use LD_LIBRARY_PATH, the issue does not occur.  The problem with that work around is that the JBDS packaged native library versions are older than the recent RHEL 6 updates.

Is it possible for JBDS to not bundle these native libraries and instead rely on the underlying linux installation libraries (which are updated)?  RHEL 6 includes a xulrunner package that provides:
{noformat}
/etc/ld.so.conf.d/xulrunner-64.conf
/usr/bin/xulrunner
/usr/lib64/xulrunner
/usr/lib64/xulrunner/LICENSE
/usr/lib64/xulrunner/README.xulrunner
/usr/lib64/xulrunner/chrome
/usr/lib64/xulrunner/chrome.manifest
/usr/lib64/xulrunner/chrome/icons
/usr/lib64/xulrunner/chrome/icons/default
/usr/lib64/xulrunner/chrome/icons/default/default16.png
/usr/lib64/xulrunner/chrome/icons/default/default32.png
/usr/lib64/xulrunner/chrome/icons/default/default48.png
/usr/lib64/xulrunner/components
/usr/lib64/xulrunner/components/binary.manifest
/usr/lib64/xulrunner/components/compreg.dat
/usr/lib64/xulrunner/components/libdbusservice.so
/usr/lib64/xulrunner/components/libmozgnome.so
/usr/lib64/xulrunner/components/libnkgnomevfs.so
/usr/lib64/xulrunner/components/xpti.dat
/usr/lib64/xulrunner/defaults
/usr/lib64/xulrunner/defaults/pref
/usr/lib64/xulrunner/defaults/pref/all-redhat.js
/usr/lib64/xulrunner/dependentlibs.list
/usr/lib64/xulrunner/dictionaries
/usr/lib64/xulrunner/libmozalloc.so
/usr/lib64/xulrunner/libmozsqlite3.so
/usr/lib64/xulrunner/libxpcom.so
/usr/lib64/xulrunner/libxul.so
/usr/lib64/xulrunner/mozilla-xremote-client
/usr/lib64/xulrunner/omni.ja
/usr/lib64/xulrunner/platform.ini
/usr/lib64/xulrunner/plugin-container
/usr/lib64/xulrunner/plugins
/usr/lib64/xulrunner/run-mozilla.sh
/usr/lib64/xulrunner/xulrunner
/usr/lib64/xulrunner/xulrunner-stub
{noformat}

> 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)