Creating SSL sockets in Java using out-of-the-box APIs isn’t good enough

By Greg Turnquist

Greg is a member of the Spring team, an author of several books on Spring Boot, conference speaker, and the lead for Spring Data JPA.

java | ssl

January 9, 2012

Lately, I have had to work on a Java solution that involved locking down SSL. What do I mean by this? Quite simply, the list of default ciphers provided to Java’s SSLSocket/SSLServerSocket includes some really crazy choices. A few are low grade ciphers (40 bit and 56 bit), and some even have no encryption.

Essentially, if you are going to write any code with an SSLSocket you MUST override the default ciphers and put in a better choice of ciphers. Sadly, this means that for every app you write with SSL sockets, you must include some custom code to override these settings.

What do you call it when you write the same code over and over again? A code smell! Code smells require some form of refactoring to avoid. In this situation, you should delegate creating SSL sockets to a library dedicated to making SSL sockets easier to configure correctly. I believe such a library is needed.

Encryption always carries a sticky issue: not all countries support all the ciphers. What I mean is that it is illegal to use certain levels of encryption technology in certain countries. Basically, if you build an app and sell it to a customer located in a country that can’t use your default keys, they may need the ability to reconfigure to something weaker. You need to build your app so that it can use either property files, Spring application contexts, or other means to adjust the ciphers supported. This can really become a hassle if you have to implement it more than once.

Another issue is that your odds of making mistakes goes up every time you implement that solution. That is why libraries are really handy. For all this, I have decided to reach out to the creator of Jasypt (Java Simplified Encryption) to see if he feels it belongs in his library. If not, I think creating something on github would be in order.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *