SSL cipher suite for DPM x_relay_url

[aaronsca]

Greetings,

I am integrating DPM into an application, and it's working great for the most part. Transactions are geting approved through https://secure.authorize.net/gateway/transact.dll via DPM in test mode with a cheap Comodo certificate on my server for the relay response.  There is only one small, nagging wrinkle.  That being that AuthNet does not appear to support the TLSv1 AES cipher suite for the relay response POST.  Specifically, AuthNet appears to require 3DES.  

I'd like to only have the AES cipher suite enabled on my servers for performance and security reasons.  I suspect that AuthNet requring 3DES is more a function of running IIS 6.0/Windows Server 2003, and not some deliberate attempt to restrict AES.  Does anyone know if AuthNet has plans to enable AES for the relay response anytime soon?

For the curious, here is the relevant Apache mod_ssl configuration snippet:

    SSLEngine on
    SSLProtocol TLSv1
    SSLCipherSuite AES:DES-CBC3-SHA
    SSLCertificateFile /etc/pki/tls/certs/boowah.net.crt
    SSLCertificateKeyFile /etc/pki/tls/private/boowah.net.key
    SSLCertificateChainFile /etc/pki/tls/certs/boowah.net.ca-bundle
    CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Thanks!

-Lex

[TJPride]

How do you know this? Do you have garbage coming through, or does your server error log tell you what the problem is, or is nothing coming through and you're just theorizing? Also, what performance and security issues are there for DES? Even if we assume for the sake of argument that you're correct and the only way to get this to work is turn on DES, Authorize.net is still the only entity that's going to connect to you via that, so essentially no slowdown, and the only non-brute force attacks on DES are still highly theoretical and only something that the NSA could probably manage (if anyone). If a government-level entity is out to get you, you're dead anyway - there are much easier ways to crack your system or shut you down that don't involve breaking through DES.

[aaronsca]

As I mentioned above, I'm able to get transactions processed and approved, so long as I enable 3DES :)

I originally had my server configured for AES cipher suites only, and AuthNet would connect to my server for the relay response and immediately disconnect without sending any POST data.  On the browser side, AuthNet kicked back an error that read, "An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error." It took some sleuthing with tcpdump, openssl, combing through the logs and trial and error Apache mod_ssl configuration to figure out that although AuthNet supports TLSv1, they still require the old 3DES cipher suites and do _not_ support AES. 

With respect to performance, the issue isn't so much that DES is slow (it is), but that AES is fast.  AES by itself is faster and arguably more secure than 3DES.  AES acceleration built into modern Xeon processors on top of that makes AES even faster, which translates into lower load on the server, being able to handle more connections, etc.

With respect to security, it's not a specific threat or vulnerability I'm trying to mitigate.  Rather, I'm trying to reduce the attack surface.  I've been running AES-only for a number of months now without issue, save for this one with AuthNet. Having to enable a specific cipher suite for this single case seems silly.  Most if not all modern browsers and SSL/TLS libraries support the AES cipher suites. As I mentioned above, I suspect this is a simple case of AuthNet running older Windows software that simply doesn't support it.  If that's the case, there's nothing to do about it.

[TJPride]

Well, it certainly doesn't hurt to ask, but I doubt they're going to change the way they're doing things just for you, at least not in a short period of time. So if you're integrating now, better to assume worst-case scenario and just turn on DES. As long as only Authorize.net is connecting to you through that, the slowdown really isn't going to matter unless you're getting hundreds of thousands of orders per day. It may offend your programming sensibilities, but there are better things to be spending your time on :)

There are many programming situations where it's more cost-effective to upgrade your computer / hosting than to put in the amount of effort to code a work-around. And here, you don't even need to upgrade.

[Trevor · Accepted solution]

I think the best input I can provide here is that you are both mostly right.  At this time, our system does use 3DES for SSL communication. Unfortunately, the rest of my response is going to sound very generic.  We don't have a timeline for when we might support AES, but we are constantly updating our platform. My guess is that this is a feature that will be added as a part of a future general update and not something that we will address specifically.

[evoDev]

I have a feeling that this might still be an issue at Authorize.NET with their Win 2003 servers. I have a similar article on SHA2 certficates here.