It never fails that I wind up seriously debugging someones TLS connection at Connectathon Day 2 and this year was no exception. Certificates that worked on the development system back home don't seem to work on the production system we shipped to the connectathon, certificates seemed to be at fault, then configuration. The rule should be that what you test with is what you ship to connectathon, but at some point things need to move off of developer systems to the hardware that you want to have in the demonstration. It's better to make that move before connectathon rather than afterwards. I cannot blame this team, some issues just plain trump connectathon, and I'm as much or more at fault than any of them.
Building Certificates
I've been using the same script to build connectathon certificates for the last four years. The commands are listed in the ATNA FAQ (one of the top 20 most popular pages on the IHE Wiki). I wind up rebuilding keys rather frequently for my teams or for others on the connectathon floor (when I have time). One of these days I'll build a web tool that will enable people to generate certificates in all the popular formats just so I can stop having to do it myself.
Debugging the Connection
One of the critical tools I use to debug TLS connections is Wire Shark. Using it I can tell within seconds (or minutes if I have to wait for a resend) why a TLS connection isn't working. It just tells me what the error is without me having to go look it up in the RFC (unlike the Java logs). It takes me about 3-5 times as much effort to diagnose connection problems with Java logs. I'm still using the version I installed 3 years ago (it was called Ethereal back then), and it is still saving me a lot of time. Another handy use for Wire Shark is to capture proof that you are communicating securely when connectathon monitors show up. I save off the logs for each transaction into files that I store on my system for that purpose.
Updating the ATNA FAQ
The ATNA FAQ is rather old as IHE FAQs go, and its age is showing. I started writing it about a year after the trial implementation of the ATNA profile was released (I implemented ATNA the second year it was available), and finished the first draft in a Word document that I circulated among the IHE community during and after the 2006 connectathon.
The problem I'm running into now is that the code I wrote four years ago to deal with restricting the encryption algorithms does not work on my platform combination any more. Axis2 and other SOAP tools now use the popular HTTPClient tools to marshall the requests. My code doesn't work with those tools (yet). It may simply be that methods used to set the default secure socket factory seem to have changed in newer versions of Java. I'll have it fixed in the morning.
Ranting and Raving
Rant
I'm still wishing there was a .Net solution to support AES on older Windows platforms. This particular Microsoft technical bulletin indicates that AES is present on some versions of Windows XP and Server 2003 as well as Vista and Server 2008 (in the encrypting file system). Note here that AES is also used by Office 2007.
However, if you or I want to use AES for anything through a Microsoft OS, you must have Server 2008 or Windows 7. I've heard several reports of concerns about having to change operating system requirements for products in order to meet meaningful use requirements (AES is one of the best encryption options that comply with the IFR). Can you imagine what it would mean to have to upgrade the OS for all computers in a large hospital or IDN to support meaningful use? That's one way to spend money, but not, I'm sure what was intended by the HITECH Act. Why isn't it supported by those older versions? One good reason might be the fact that the implementation referenced in the technical bulletin isn't FIPS certified.
Rave
The number of vendors supporting XDS this year has grown by leaps and bounds over the last two years. I don't have the exact numbers (yet), but I looked briefly at a slide reporting them last night, and it looks to have better than doubled, and the growth in Registry and Repositories is even better.
Testing this year is also much smoother than last year. Kudu is snappier, the number of tests done on Day 1 (and Day 2) seem to be much improved. Overall, the testing seems to be going very well.
Day 3 will be about PIX and PDQ and I hope to tell you how well that went tommorrow evening.
P.S. I've added the IHE Connectathon to the "Where in the World is XDS" map for this week only. That map is available also from http://tinyurl.com/wwxds to make it easy for you to point others to it.
0 comments:
Post a Comment