TLS problem
- This topic has 11 replies, 4 voices, and was last updated 2 years, 1 month ago by
.
-
Topic
-
We’re having a TLS issue between Epic and Cloverleaf. We have potential workarounds for the issue, but none of them are great. This affects standard inbound HL7 TLS interfaces using MLLP (as opposed to HTTPS or something like that).
When we start an outbound Epic interface, it opens the TCP connection to Cloverleaf, but it doesn’t start the TLS handshake until it has a message to send. This could potentially be hours later (days later in a test environment). When an inbound Cloverleaf interface receives a TCP connection, there is a 30 second timeout for the TLS handshake to occur, after that the connection is reset. During those 30 seconds all other interfaces in the process are non-responsive. Because Epic will restart the connection when it is reset, that means that all Cloverleaf interfaces in the same process as the problematic interface will not work until Epic has a message to send.
Cloverleaf development says that the issue is a “rare case” and we have workarounds, so they haven’t offered a fix of the non-responsiveness problem. Their suggested workaround is to put each inbound TLS interface in its own process.
Epic says that Cloverleaf shouldn’t have any expectation that the handshake will happen right when the TCP connection is opened. They’ve suggested that we make the Cloverleaf inbound threads be the clients when setting up the connection.
Other options I’ve considered are to disable TLS, use HTTPS instead of TLS or leave it the way it is and manually turn off interfaces if they don’t have queued messages.
I’m posting here as a warning to others who are setting up these interfaces. It took a long time to realize what was happening, and it just seemed like the interfaces were sometimes unreliable.
- You must be logged in to reply to this topic.
