Running BCFIPS in SpringBoot 3.2

Healthcare Standards · 2 years ago · 163 views

I'm rewriting wrappers for a Spring Boot 1.5 application using Spring Boot 3.2 to help me eliminate some older dependencies I cannot even get patches for anymore.  So now I have to make my new Spring Boot application work with the latest Bouncy Castle FIPS code. I've previously mentioned the NIST Certified Bouncy Castle FIPS TLS libraries in other posts.  SOAP is tremendously complicated to configure and manage.  REST is so much easier, and when you don't need all of the power of a SOAP stack, you can certainly send SOAP messages in XML quite readily using a normal REST transport layer.  You may need to write some extra marshalling code, but for standardized interfaces, that doesn't tend to be a big lift and there are plenty of existing tools to help (e.g., Faster Jackson XML). There are a few challenges. One of these stems from the need for the BC-FIPS modules to validate themselves on startup.  This uses jar validation processes, but the code running the validation needs to be able to find itself.  That gets complicated by a minor change in Spring Boot 3.2 URL format when it repackages the application into an uber-jar. The URL conflicts with what the BC modules expect, and then they won't validate.  While the fix is a one-liner in BC-FIPS, it's a change to a certified software module, which means that it has to go through processes which make it take longer than anyone would like. Spring Boot uber class loading has the ability to target classes which need to be unpacked from the Uber-jar before loading. The JAR files will then be unpacked from the uber-jar into your TEMP folder before being loaded, and those will be accessible from a different kind of URL, that of the JAR file, which BCFIPS knows how to resolve. To make this work, you will need to update your configuration for the spring-boot-maven-plugin to tell it which jar files need to be unpacked.  The necessary lines of code are below: <plugin> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-maven-plugin</artifactid> <configuration> <mainclass><!--your-application-main-class--></mainclass> <requiresunpack> <dependency> <groupid>org.bouncycastle</groupid> <artifactid>bcpkix-fips</artifactid> </dependency> <dependency> <groupid>org.bouncycastle</groupid> <artifactid>bc-fips</artifactid> </dependency> <dependency> <groupid>org.bouncycastle</groupid> <artifactid>bctls-fips</artifactid> </dependency> </requiresunpack> </configuration> <executions> <execution> <id>default-jar</id> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> Rewriting my wrapper to ditch CXF and modernize to the latest Spring Boot will save a lot on future maintenance efforts and is already making the application much simpler.  There's plenty of glue code needed to run inside the CXF framework that can just be done away with. As you now know, I had to go back and rework for SNI again too.  It turns out the same fix was basically needed, calling URLConnectionUtil.openConnection(). import org.bouncycastle.jsse.util.URLConnectionUtil;   ...   /**   * This method obtains an SNI enabled Server Socket Factory   * @param location The URL to obtain a connection for   * @return An HttpURLConnection that supports SNI if the URL starts with HTTPS or has no URL Scheme.   * @throws IOException   */  public HttpURLConnection getSNIEnabledConnection(URL location) throws IOException {    String protocol = location.getProtocol();    if (protocol == null || !protocol.startsWith("https")) {      // Not HTTPS      return (HttpURLConnection) location.openConnection();    }    URLConnectionUtil util = new URLConnectionUtil(getSSLContext().getSocketFactory());    HttpsURLConnection conx = (HttpsURLConnection) util.openConnection(location);    conx.setHostnameVerifier(ClientTlsSupport::verifyHostname);    return conx;  }