As PCI DSS rules and general security best practices evolve, more people are configuring their web servers to eliminate less-secure versions of SSL and TLS for their HTTP connections. If you are using a Java or JVM-based application, this may manifest itself in a sudden inability to connect resulting in a fatal handshake_failure.

What this is telling you is that you were able to connect but your client and the remote server were unable to find a mutually acceptable encryption algorithm to communicate over so further communication was aborted.

An easy way to tell if this is your problem as a Java/JVM client is to use the Qualys SSL analyzer and see whether it reports a Java client can connect. In my case, I saw the following failures when I entered the SSL endpoint I wanted to access:

If you happen to be a ColdFusion user, you can add -Djavax.net.debug=ssl,handshake,verbose to your jvm.config, restart and make your HTTPS request and see the full list of ciphers being attempted and the ultimate failure in your log file. My logs with the handshake_failure can be seen in this gist for comparison.

Fix with Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

The fix is easy to implement but not easy to find. I experienced this with Oracle’s JVM and not the OpenJDK so other JVM implementations may behave differently. In the case of Oracle’s JVM, strong encryption is disabled out of the box for export reasons so the JVM can not use an encryption algorithm stronger than 128-bit. Many web servers are now disabling 128-bit SSL in favor of 256-bit and 384-bit encryption algorithms so the fix is to turn these on in your JVM.

1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle (this link is for Java 1.8, Google for alternative JVM versions): http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
2. Extract the two JAR files into your jre/lib/security folder overwriting the US_export_policy.jar and local_policy.jar.
3. Restart the JVM

You should now be able to connect to the remote server. If you’re still unable to connect, try enabling debugging and see which ciphers are attempted/ignored. The remote server may have an exotic configuration that requires you to contact them but the unlimited strength jurisdiction policy files should fix handshake_failure issues.

I’m a big fan of my Stilo helmet and one of the reasons is the built in hydration port. I have mine on the right side of my helmet (inboard for LHD cars). In my own cars, I have a camelback system mounted in the passenger area and I use the quick-disconnect for sprint races so I can drink without taking my hands off the wheel.

For endurance races where I’m sharing a car, we usually use something like the Longacre Drink bottle which a crew member pops in the car when I begin my stint:

Normally I attach a bit of the hook side of velcro wrapped around the tube and it will stick to the fabric on the side of the race seat between the seat and the transmission tunnel. The problem this year in the 25 Hours of Thunderhill was that it didn’t stick and about 3 laps into my 40 lap stint, the hose went flying and out of reach.

Enter McMaster-Carr part number #5012K39 “Air and water quick-disconnect tube coupling barbed socket with valve, 1/8 coupling for 1/4″ tube ID”:

This is the appropriate size female connector to click onto the quick-disconnect male portion that extends from the Stilo hydration port. In short, if you want to attach any fluid hoses to the Stilo factory hydration port, you need a 1/8″ coupler quick disconnect. The 1/4″ barbed size is the right size for the hose in the Longacre drink kit (and probably the others). McMaster-Carr has all different styles of this connector available including other size barbs and compression fittings.

I frequently describe my life as “trying to fit 10 gallons into a 5-gallon hat”. It’s a self-imposed problem due to my love of so many different interests (and perhaps a penchant for “being busy” that I’m trying to break). I recently added a newborn baby girl to the mix which means the structure and routine I relied on has been tossed out the window and I find myself needing new techniques to excel.

Caffeine

Introduce our good friend caffeine. It’s always good for a pick me up, especially when I’m feeling slow in the morning. I’m not a coffee drinker but traveling in India and Southeast Asia got me hooked on a good cup of tea. Chai is my preference, but not the sugary kind you would get out of a box at Starbucks. I have a milk frother at home that makes a nice latte-esque cup from black tea leaves and spices. Side note: if you want a no-sugar-added chai at a Starbucks, ask for a “Chai Tea Misto”. It’s chai tea bags with steamed milk priced like a tea so about half the cost of a chai latte. Half the Starbucks don’t know how to make it though, so be clear it’s not a latte.

As a Northern Californian going through a drought, I have separately been working to minimize my showers. My shower takes about 2 minutes to get hot water so we let it run into a 5-gallon bucket. Once it gets warm, I would jump in, get wet, turn the water off. Wash my hair, my body and then turn the water back on to rinse before getting out. As someone who loves long, hot showers, this is both soul-crushing and terribly efficient. Combined with better managing our sprinklers and more water-efficient washer/dryer, we cut our overall water usage by 35%.

Let’s weave these threads together. Busy life. Little sleep. Newborn baby. Water restrictions. How can I optimize my physical feeling each day?

Cold Showers

There’s a lot of research and/or hype about cold showers in the fitness world. They are claimed to help with fat loss and promote muscular recovery among other things. I am not a researcher and have no opinion on those. What I can tell you is that cold showers can wake up even the most sleep deprived new parent and kick start your day. Best part? The effect lasts for hours!

If you search for “cold shower challenge”, you’ll find lots of suggested protocols. I started with a regular hot shower and progressively added cold water finishes. Just for a few seconds. Then a few more seconds. Then a few more and so on until I worked up to half my shower under cold water. Here’s how I’m doing it now:

1. Run a hot shower (into the bucket to save water which we use to water plants)
2. Get in right as the water gets hot, scrub my face vigorously, quickly get wet (under 60 seconds)
3. Turn water off, wash my hair and body
4. Turn water back on to hot and begin to rinse
5. Immediately move water to cold, as cold as you can without the shower turning off
6. Try to remain calm as your body goes from 130F water to 60F water, finish rinsing off (another 60 seconds). Embrace the feeling.
7. Exit the shower WIDE AWAKE

My mind is buzzing as I dry off and I walk into my home office with not so much a thought about needing a cup of chai.

My home is generally pretty cold so I used to stay in the shower for long periods of time to warm up my cold extremities. Now when I turn the cold water rinse off, the air temperature feels warm and I’m in no rush to dry off or put on clothes. If you’ve ever gone wakeboarding in a cold lake, it’s like how falling back into the water can feel great after the wind chill factor of being towed behind a boat at 20mph.

I still enjoy a good cup of chai because it’s delicious but I have found that using caffeine as a crutch has all but disappeared. And in a weird way, I now enjoy the feeling of shock as the cold water hits my head and the adrenaline starts running.

You can easily start with a 5-second cold finish. Move that to 10. Then 20. How about a minute? Try it out and tell me what happens below!

My apps use a variety of frameworks which offer a lot of rapid development and agility but they also come at the cost of slower startup times. For a Coldspring-based app with a large service layer, you could easily run into timeouts when initially loading the application. Here’s a simple function to temporarily extend the processing timeout during initialization using CFTHREAD and the Admin API:

<cffunction name="extendRequestTimeoutDuringInit" output="false" access="public" returntype="any">

  <cfthread action="run" name="delayRequestTimeoutDuringInit">
    <cfset thread.adminapi = createObject("component", "cfide.adminapi.administrator") />
    <cfset thread.adminapi.login('mysecretpassword') />
    <cfset thread.runtime = createObject("component", "cfide.adminapi.runtime") />
    <cfset thread.timeout = thread.runtime.getRuntimeProperty("TimeoutRequestTimeLimit") />
    <cflog file="application" text="Extending RequestTimeout to #2*thread.timeout# seconds" />
    <cfset thread.runtime.setRuntimeProperty("TimeoutRequestTimeLimit", 2*thread.timeout) />
    <cfset sleep(2 * thread.timeout * 1000) />
    <cfset thread.runtime.setRuntimeProperty("TimeoutRequestTimeLimit", thread.timeout) />
    <cflog file="application" text="Restored RequestTimeout to #thread.timeout# seconds" />
  </cfthread>

</cffunction>

I call this in Server.cfc when my instance starts up but you could also call it from any reinit routine in OnRequestStart or OnApplicationStart. Previously when we pushed code, the first user request would kick off the initialization process while other requests queued. Many of those first requests would exceed our page timeout setting of 60 seconds. Running the above function uses a background thread to double the timeout and later reset it once the application has initialized so users no longer see timeout/error screens.