Is anyone doing any validation of "who" is sending messages to a NON SSL TCP Listener channel?

[JeffBenedict]

Our leadership has asked us to look into solutions for validating/verifying the sender of hl7 messages into our Mirth system as actually being who the channel was setup for. Without going with the complexities of SSL certificates, my initial thought was utilizing MSH fields in the messages, but that can easily be mimicked. So the next thought was using the remoteAddress Source Mapping, ip address, which would allow for a little more validation, but with the understanding that IPs could be spoofed by a bad actor. (Yes we do have VPNs setup to our external vendors). Other than those 2 options (MSH and IP), and w/o using SSL/Certificates, are there any other methods available to Mirth that I'm not thinking about?

[pacmano1]

I would not expect ports to be open to anyone but the other side you approved to send messages. The question sorta puzzles me. If there are bad actors on their side, you have a much larger problem. You should not need to validate an IP address in Mirth, since you should already be explicitly permitting the other side inbound by VPN tunnel / firewall rules. If you are NOT doing that, you really need to fix that ASAP.

MSH-8 is a security field that would normally be used to authenticate against some service, but you and the sender need to agree to use that.

[JeffBenedict]

For our VPNs and Firewalls to the outside world, we DO have only the ports open that the remote system needs to use to communicate with us. The request from leadership puzzled me too and when I asked for clarification, the answer came back along the lines of: "if our engine is listening on port xyz for an HL7 message from company abc, then how can we validate/block a message being sent to that same port from an internal ip by someone who wrote their own hl7 sender or from some other hl7 tool to that same listening port?" That is the reason I went down the remoteAddress source mapping validation route.

[pacmano1]

BTW - getting folks to send TLS wrapped TCP from their integration engines seems like asking for their first born. IMHO, it's so much easier than managing VPNs.

HL7 over https is another option and you can ask your clients to migrate over time. the http listener(s) on your side can handle the authentication of senders via client TLS (or not) and authorization headers, JWTs, etc.

[pacmano1]

On your last comment - Are you already allowing by the explicit IP addresses of the other sides integration engine (rather than allow all from the other side)? If yes, short of what you mentioned in your initial post of checking MSH stuff, you would have to ask the client to participate in some shared credentialing within the HL7 message itself that would likely need to be token based and thereby expire and require renewal, I suppose other schemes would work of course. That is likely a heavy lift on their side.

If management said "you must validate the messages" I would move the hl7 over HTTPS with JWTs.

[JeffBenedict]

Yes, for the vendors engines that are on the other side of a VPN, it's locked down to their IP and Port (failed to mention that in my earlier comment); Thank you for your insight. It is always greatly appreciated.

[pacmano1]

Was chatting with @jonbartels on this - he did mention starting in version 2.6: https://hl7-definition.caristix.com/v2/HL7v2.6/Segments/UAC. But never seen it.

[jonbartels]

if our engine is listening on port xyz for an HL7 message from company abc, then how can we validate/block a message being sent to that same port from an internal ip by someone who wrote their own hl7 sender or from some other hl7 tool to that same listening port?

I think that this risk is a bit of an absurd condition.

I can describe a condition where I did something similar, literally yesterday. Customer could not send messages over the VPN. To triage the problem I got into the OS console on a system that was in a similar position on the network. I ran telnet server port and copied in HL7 as text. Mirth accepted the message.

The controls against this being used nefariously or irresponsibly are:

• IP whitelisting
• access control to the apps and console
• training of staff on proper procedures

Using SSL with mutual-TLS would make a similar process harder, but still not impossible.

I think that protocol specific constraints like the UAC segment are interesting but I've never seen them used in the wild.

[JeffBenedict]

Yes that UAC segment looks interesting, but it's hard enough getting vendors of older / smaller EHR systems to move past HL7 2.3 when newer/bigger EHRs are upgrading their interfaces to 2.5.1 and "conversions" have to be done in the engine. :)