The solution is to go back to the IHE-ATNA profile that long time ago mandated the use of TLS 1; so Connectathon should never have allowed SSL anyway.
The short term solution is to recognize this problem, and get back to testing healthcare specific things.
The Following is the Notice written up last night:
There have been problems with the NIST XDS tools regarding the use of TLS. This note documents the issues and describes the changes to testing.
The ATNA profile requires the use of TLS v1 for protecting message exchange between systems. In the past we have seen TLS on-the-wire negotiations where one party requests TLS V1 and the other party requests SSL V3 and the connection is established at the SSL V3 level. This has been accepted in the past but it has been poorly understood. We now understand the following details.
So what is important when dealing with our tools is to understand what Java version is being used in which tool on the test floor.
- In general this is controlled mostly by implementation platform and not vendor/tool code.
- On Windows platforms, older versions allow the back off to SSL V3 and the newest absolutely requires TLS V1. I am not a Windows developer so I cannot point to specific versions based on my knowledge.
- For Java based systems it is the JDK/JRE version that matters. Java 6 (1.6) will only negotiate to SSL V3. Java 7 (1.7) is able to negotiate TLS v1.
The immediate goal is to have vendors and monitors stop having to deal with this problem and get back to productive testing. So,
- The Internet Public Registry and the three copies here in Cleveland (RED/GREEN/BLUE) all are running on Java 6.
- Toolkit for Connectathon is running on Java 6
Vendors and monitors: any test that cannot easily be validated via TLS (TLS selection in toolkit) should be validated without TLS. Do not spend any more time dealing with TLS issues unless it relates directly to the interaction between two vendor systems!