How Kubernetes saved my desktop application

Keep this fix in mind if you have a broken Java desktop application but aren't a crypto expert.
110 readers like this.
Puzzle pieces coming together to form a computer screen

Opensource.com

Recently, fellow Opensource.com scribe James Farrell wrote a wonderful article entitled How Ansible brought peace to my home. In addition to the great article, I really liked the title, one of those unexpected phrases that I’m sure brought a smile to many faces.

I recently had a weird but positive experience of my own that begs a similar sort of unexpected label. I’ve been grappling with a difficult problem that arose when upgrading some server and networking infrastructure that broke a Java application I’ve been supporting since the early 2000s. Strangely enough, I found the solution in what appears to be a very informative and excellent article on Kubernetes, of all things.

Without further ado, here is my problem:

I’m guessing that most readers will look at that message and think things like, "I hope there’s more info in the log file," or "I’m really glad I’ve never received a message like that."

Unfortunately, there isn’t a lot of info in the log file, just the same message, in fact. In an effort to debug this, I did three things:

  1. I searched online for the message. Interestingly, or perhaps ominously, there were only 200 or so hits on this string, one of which suggested turning on more debugging output, which involved adding the setting

    -Djavax.net.debug=ssl:handshake:verbose

    to the java command running the application.

  2. I tried that suggestion, which resulted in a lot of output (good), most of which only vaguely made sense to me as I’m no kind of expert in the underlying bits of stuff like SSL. But one thing I did notice is that there was no information regarding a response from the server in the midst of all of that output;

  3. So I searched some more.

Another interesting part of this problem is that the code ran fine when executed by the Java command bundled in the OpenJDK, but failed with this error when using a customized runtime created from the same OpenJDK in this way. So the relatively modest number of apparently similar problems turned up from search #1 above were actually not all that relevant since they all seemed to be dealing mostly with bad SSL certificates on the server in conjunction with the PostgreSQL JDBC’s ability to check the server’s credentials.

I should also mention that it took me quite some time to realize that the problem was introduced by using the custom Java runtime, as I managed to check many other possibilities along the way (and indeed, I did fix a few minor bugs while I was at it). My efforts included things like getting the latest OpenJDK, checking and re-checking all the URLs in case one had a typo, and so forth.

As often happens, after putting the problem aside for a few hours, an idea occurred to me—perhaps I was missing some module in the customized Java runtime. While I didn’t receive any errors directly suggesting that problem, the observable fact that the standard OpenJDK environment worked while the custom one failed seemed to hint at that possibility. I took a quick look in the jmods/ folder in the OpenJDK installation, but there are some 70 modules there and nothing jumped out at me.

But again, what seemed odd was, with debugging turned on (see #1 above), there was no indication of what the server would accept, just what the client mostly couldn’t offer, many lines like this:

Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

So I was at least thinking by this time that maybe what was missing was the module that offered those kinds of cipher suites. So I started searching with strings like "jdbc crypto," and in the midst of that, the most unlikely article showed up: Optimizing Kubernetes Services—Part 2: Spring Web, written by Juan Medina. Midway down the article, I spotted the following:

Huh! Imagine that, his script is creating a custom Java runtime, just like mine. But he says he needs to add in manually the module jdk.crypto.ec in order to connect via SSL to his PostgreSQL environment. Sure sounded familiar.

In fact, this was the solution to my problem as well; the missing module was jdk.crypto.ec, and I was able to add it into my build as follows:

DEPS=$(JAVA_HOME)/bin/jdeps --print-module-deps $(TEST_HOME)/MyApp.jar \ $(TEST_HOME)/lib/*.jar,jdk.crypto.ec;
$(JAVA_HOME)/bin/jlink --module-path $(W64_JAVA_HOME)/jmods
–no-header-files --no-man-pages --compress=2 –strip-debug
–add-modules $$DEPS --output $(TEST_HOME)/java-runtime

(I’m cross-building a Windows Java runtime here; see my earlier article on this topic for more info).

In conclusion

This was a big bullet to dodge for someone like me who doesn’t know much about crypto. And once again, open source, and more than that, the willingness to share that goes with open source, is huge. And wow, using Kubernetes to fix a Java desktop application, that’s pretty huge too! Thanks again to Juan Medina!

What to read next
Tags
Chris Hermansen portrait Temuco Chile
Seldom without a computer of some sort since graduating from the University of British Columbia in 1978, I have been a full-time Linux user since 2005, a full-time Solaris and SunOS user from 1986 through 2005, and UNIX System V user before that.

6 Comments

This article is in good timing for me too because I'm troubleshooting a similar issue. Thanks!

Nice article ... thanks for mentioning my previous work :)

For all of its merits, Java and its security parts can be a real pain to debug.

Given the growing complexity of software, it seems increasingly necessary to find debugging solutions in seemingly unrelated projects and posts.

I also feel that poorly documented and mysterious problems like this end up making it more difficult for people to adopt good security practices and sometimes lead to desperate work-arounds that make security worse.

thanks!

James, thank YOU for your kind comment.

Re Java - lately I've been dipping my toes into the whole streams & collectors thing, and I have to say the messages the compiler emits when I goof up the syntax can be pretty darned opaque, too.

I think we're in for more of this kind of thing as the pressure for doing something useful every six months besides just fixing all the bugs starts to weigh on people. Plus I'm not clear on how those wonderful projects that are meant to USE this new stuff are going to keep up.

Not to be overly bleak here! But just a bit worried.

In reply to by JamesF

I think the concept of self-contained environments has exposed some interesting things about software, dependencies, and troubleshooting. Kubernetes and pods and containers and namespace align nicely with Java modularity, Python environments, and so on. Synergy!

Thanks for the comment, Seth! For sure there is conceptual alignment, I suppose that's the (kind of tongue in cheek) point of my article - how does Kubernetes relate to a classical fat desktop application designed nearly 20 years ago? Well for starters, deployment...

In reply to by sethkenlon

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.