Coldfusion, SSL 3.0 and Authorize.net
I've been batting this around for a few days now. Recently, Mary Jo Sminkey of CF Webstore fame posted a note to an email list about the recent requirement by Authorize.net that incoming requests to their API use SSL 3.0. I confess to being unaware of the differences between SSL 2.0 and 3.0. So I set out to discover for myself. To start with SSL 2.0 uses weaker handshaking. A requesting client can, it seems, edit the list of preferences leaving the server no choice but to hand shake with the "lowest common denominator" cipher. There are some other issues as well dealing with how the packets are constructed etc. So the consensus is that SSL 2.0 is the weak sister and should be deprecated. For its part SSL 3.0 has been around for a decade or so and is widely supported.
The question is, will my CFHTTP calls from ColdFusion 6 or Coldfusion 7 still work when Authorize.net disables SSL 2.0? To answer this question I got some great help from Scott Krebs over at Edge Web. He dug out three or four URLs that were really helpful. I've included them at the bottom of this post. I also got some guidance from the Stephen Hawking of cryptography, Mr. Dean H. Saxe (the H is for Holy Cow he knows a lot). The answer is a qualified yes. Anyway, here's what I did to test while I wait for Authorize.net to get their act together and set up a test bed.
Testing SSL 3.0
First I had to prep a server so that it only supports SSL 3.0 and above (we'll talk about the "above" in a moment). I logged into the desktop of one of my ColdFusion 7 windows servers and used these instructions to disable SSL2.0. I also disabled PCT for good measure - although I did not have the time to figure out exactly what it is. I restarted the server.
Next I obtained a public cert for a URL and installed it on the web server. Now, theoretically, connecting to that site could only be done via SSL 3.0 or above. So far so good. Note, the "public" cert is important too. I used a Thawte cert so I could guarantee that the keystore would trust it. I didn't want to mistake an issue with the keystore for a problem handshaking.
Finally, I followed the instructions found Here to add a debug switch to my jvm.config file. I cleared out the coldfusion-out log and restarted ColdFusion on the server. At this point, Java was logging any cfhttp calls into the coldfusion-out log, including the handshake stuff. I ran the following code:
The Findings
First off, there is a great deal of stuff going on behind the scenes when you make an SSL connection. Running the above request only one time generated over 30k of log data. About 95% of it is the crypto stuff - registers of tabbed hex data. But looking carefully I found the following lines:
jrpp-0, WRITE: SSLv2 client hello message, length = 98There were more references to TLSv1 before the connection was closed. What to make of it? Well, for one thing no mention of SSLv3 is made anywhere in the log. What gives? I thought that I had disabled SSL 2.0, and clearly I'm making a successful SSL connection, but looking at the log it seems I'm making a "TLS 1.0" connection instead of SSL 3.0.
jrpp-0, READ: TLSv1 Handshake, length = 914
*** ServerHello, TLSv1
RandomCookie: GMT: 1218720998
....
A bunch more cypher stuff... Followed by: .... jrpp-0, WRITE: TLSv1 Handshake, length = 32
jrpp-0, READ: TLSv1 Change Cipher Spec, length = 1
JsseJCE: Using JSSE internal implementation for cipher RC4
jrpp-0, READ: TLSv1 Handshake, length = 32
The Fine Print
It turns out that both Coldfusion 6 and Coldfusion 7 (really the 1.4.2 JVM) support SSL 3.0 by way of the TLS 1.0 protocol. This protocol is sometimes called "SSL 3.1" and it represents a slightly better implementation. Connections will actually attempt this protocol first and use it if successful. I would go so far as to say if you are using ColdFusion 6 or 7 and making HTTPS calls from within your code you are likely already using TLS and therefore compliant. MSDN puts it this way:
Of course one thing to bear in mind would be if a provider only supports SSL 3.0 and chooses to disable TLS for some reason then CF 6 and 7 would be out of luck. Still, I'm reassured that TLS is actually one step "above" SSL 3.0 and represents the higher level of encryption rather than a lateral or lower level. It is enabled by default and I have seen no guidance anywhere suggesting that it be disabled for any reason.
One Gotcha
Note that this does not address the specific use of client certificates to handshake with SSL. That's a different scenario. Check out this post from Steven Erat that gives a rundown on that issue. If you need to use a client cert to connect then the main problem is that there is no way in the cfhttp or cfinvoke or cfldap tag to specify the location of the cert. In that case you will either need a custom solution (a Java library or something) or you will need to upgrade to ColdFusion 8 which happily supports a clientcert and clientcertpassword attribute.
Resources Summary
The following links were helpful to me. Some of them are mentioned in this article. Again, my thanks to Scott Krebs and the folks from circle of Gurus who always come through with great information.
- Disabling SSL 2.0
- Steve Erat on SSL 3.0 and ColdFusion Tags
- How to Enable SSL Debug Information
- Understanding SSL Debug Info (from Sun)
- Differences Between TLS and SSL 3.0
- Analysis of SSL 3.0 (David Wagner - Berkeley & Bruce Schneier - Counterpan sys.)
As always, this article is intended as a starting point to pull together resources. I'm interested in the findings of anyone who is working on this issue or related issues. I'm always grateful to my vigilant readers for expanding my knowledge.
9 Comments
-
@Ryan,
Yes... but it does show the ciphers used and you can even run through a test of specific ciphers to see which ones a given server will support. For example, a test of gmail https tells me that it will support EXP-RC4-MD5 encryption, which according to Foundstone, is a weak 40 bit algorithm. So it is still useful to figure out what is happening and why your handshake might be failing.
-Mark -
Of course you can test the same using openssl on the command line or using Netscape 7. NS7 lets you selectively enable/disable ciphers for SSL, which is pretty cool.
One caveat of SSLDigger/openssl: If a site supports a weak form of crypto or SSLv2, it may very well redirect any requests to a page explaining that you need a browser upgrade. In other words, it may not support that weak crypto for the entire site! So this is where NS7 comes in handy. -
interesting timing.
We're (more precisely, my java programmer coworker is.. I'm just trying to help him) currently wrestling with a process that's using the underlying java engine. It's supposed to be creating a secure RMI connection from the CF box to another box. It keeps throwing an error saying "No Cipher Suites in Common".
I tried using the foundstone thing linked above, but I'm not sure if the results will have any bearing on what we're doing. The ssl cert we're using *is* added to the cacerts, but unfortunately I don't understand java well enough to know if my coworker is even approaching this from the right angle. Ah well. -
Thanks Mark. Very insightful. I too got the email from Authorize.net about the SSL 3.0 upgrade happening in March. Two of my clients are using Authorize.net (one on CF7 the other on CF8).
I too have asked them for a test server that I could run my code against, but so far they don't have anything.
The one client using CF7 has talked about upgrading to CF8, so if I had to I could push up that time table to upgrade if the tests prove unsuccessful once Authorize.net is ready to test. -
OK, I think I get (or will get) the ColdFusion/Java part. I am stuck back at how to obtain the client certificate. The site uses SSL to allow visitors to connect to it. Can that certificate be reused to have the site connect to Authorize.Net? We are using CF7 with IIS6 on Win2003.
Thank you.
Like everyone else, I will be glad when Authorize.Net gets a test server set up. Hopefully once it is set up and someone gets their site to work on it, they will post a how-to guide for those of us who don't have CF8 and previously didn't know there were different versions of SSL. -
Thanks for the very informative article Mark! We're all learning a lot more about SSL, that's for sure.
I got an email from Authorize.Net support that the test server now has this requirement in place. Unfortunately, I cannot report that everything worked fine for me...my tests on my own server which runs CF7 did not work. Of course, there's no way to tell for sure why, it's certainly possible AuthNet did something else that is causing the failure...I'd be interesting to hear if the test server works for CF8 (I don't currently have CF8 server with SSL that I can test on). I forwarded the response I got back to support, to see if maybe they can determine the exact cause for the failure, but it was a basic handshake/login error code that I got so that definitely has me worried. I'm hoping maybe they just gave me the wrong login credentials! -
Just to clarify...it does seem like we're not having any problem connecting to the server, if it was not using the SSL 3.0 I wouldn't get a 200 code which I am. So seems like the problem is just that the credentials they sent me for the test server aren't valid. Gotta love it...
-
Short story: We had nothing to worry about.
Longer version: I contacted Authorize.Net and they gave me the test server address. I then requested test account credentials (I was not involved with the original set up of our site). I copied the same code that we use to connect to their live site, substituted the test account credentials and test credit card info and dumped the results. There were no errors (other than the fake credit card number was invalid). Supposing they have their servers set up correctly, we are good to go.
I was mistaken about needing some kind of client SSL certificate.
We are running CF MX7 Standard on Java version 1.4.2_05 (we need to update to fix the DST changes).
Sites to Watch
Aggregators
RSS
