• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Handshake error for web connections

 
Ranch Hand
Posts: 59
5
Netbeans IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am running into a strange problem that I am having a lot of trouble debugging. When I am in actual debug mode, this does not appear. When I am running from a compiled jar file, this does not appear. The only time this appears is when I am running the code from an image (linked via jlink). As a note, I am running Adopt Open JDK 12.0.1.j9.

The code in question:



And here is the stack trace I am getting when I run it (again, only when run from a linked image):



When I have tried to google this, I have found many solutions to other problems. It seems like this particular error is one that pops up in many unrelated cases, which has made tracking down a solution difficult. Any advice/thoughts appreciated.
 
Marshal
Posts: 3707
523
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Draque Thompson wrote:

I have seen this type of error when there is a mismatch between the client and server on supported TLS/SSL protocols and/or cipher suites.

For example, the client indicates that it only supports SSL 3, but the server insists on TLS 1.1 or higher.  I suspect that your two execution environments are different.
 
Draque Thompson
Ranch Hand
Posts: 59
5
Netbeans IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input there, but after I checked thoroughly, this is not the case. Below are captures of system information from within the linked image (in which the handshake fails) and the runnable jar (in which the handshake succeeds):

IMAGE:


JAR:


As you can see, they're identical. Can you think of anything else that might be leading to this? Simple request https connections are really basic, so I feel like there has to be something that I'm missing here.

Thanks for the attention, as this one really has me puzzling.
 
Ron McLeod
Marshal
Posts: 3707
523
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try capturing a network trace of the dialogue between the client and server when performing the TLS handshake.  Then you will be able to see why the client and server fail to negotiate something workable.

I don't know what tools are available for Mac OS, but on Linux and Windows, I use the command-line version of Wireshark (tshark), or tcpdump.
 
Ron McLeod
Marshal
Posts: 3707
523
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, try running something like this in both environments to show supported protocols and cipher suites, and see if you can establish a secure connection:
 
Draque Thompson
Ranch Hand
Posts: 59
5
Netbeans IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for that last suggestion! It uncovered what the problem was, although it was something that I did not expect at all.

Jlink fails to detect that jdk.crypto.ec is a required module when linking this. Once I added that manually to the list of linked modules, the errors disappeared. The fact that it simply showed a handshake failure rather than some kind of hint that the underlying encryption module was missing is frustrating, but at least it's one more thing checked off my list in my upgrade process.
 
Ranch Hand
Posts: 218
5
MS IE Notepad Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Draque Thompson wrote:The fact that it simply showed a handshake failure rather than some kind of hint that the underlying encryption module was missing is frustrating, but at least it's one more thing checked off my list in my upgrade process.


That's caused by design of TLS wich Java follows here exactly: TLS only knows handshake_failure - it's designed to not expose what went wrong - only the fact that something did went wrong. Java reflects this correctly - openSSL would give you exact the same "error".

To examine issues with TLS it can be useful to add these to launch option:

-Djavax.net.debug=all -Djava.security.debug=all

Although that can and will lead to extreme long output (so for testing it might be clever to redirect System.out and System.err to write to files rather than to console) this way somewhere near the handshake exception you would had find some along those lines that there's no matching cipher suite is available. Digging a bit further this would resolv to that there's no provider for elliptic curve crypto. Then it would had been to look WHY there's no provider - wich then had lead you to your conclusion: missing dependency caused by linking sub-image instead of use full blown runtime.
You see, aside from how you discovered the issue - there would had been a "route to get there".

Crypto stuff is really hard to debug as it's all hidden behind SPI and classes stripped its debug data.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic