DPM fails to post back to x_relay_url after TLS v 1.0 is disabled

[vincet]

The transactions and posting back to our server has been working.

We disabled TLS 1.0 on the server and only allow TLS 1.1 or TLS 1.2

This broke the post back and get the following

"An error occurred while trying to report this transaction to the merchant" on https://secure.authorize.net/gateway/transact.dll

The transaction is taken/recorded by Authorize.net. It just fails to post back/load the x_relay_url

The x_relay_url, page it should post back to, is on port 443(https)

It is a .net webforms page that has a javascript redirect on it.

Any ideas why this change would break the post back?

Environment:

Windows Server 2008, IIS 7.5

[rockyjvec]

We are having the exact same problem.  We use the Direct Post Method (DPM) on a linux server.  I suspect that their client service which does the post back to our servers doesn't support TLS > 1.0.  Which is sad since the reason we disabled it in the first place was because their most recent security scan told us we needed to (even though we get an A+ on ssllabs).

[vincet]

Can anyone from Authorize.net confirm support for TLS v1.1 or  v1.2 when posting pack to x_relay_url on your DPM api?

[RichardH]

Hello @vincet

Yes, we currently support both TLS 1.1 and 1.2 when posting a relay response.  Please ensure that the target URL is publicly addressable and on a standard port 80 or 443.

Richard

[vincet]

Thanks for the response Richard. We have ensured that the target URL is publicly addressable and on port 443.

The only thing that changed on the server was disallowing TLS 1.0 on the server

Prior to that change it was working.

Any ideas on why this is the case?

Any suggestions on how else to troubleshoot?

[rockyjvec]

@RichardH,

Thank you for the response.  Do you support Server Name Indication (SNI) when posting a relay respose?  It seems like you do since it works with TLS 1.0 enabled.

Here is our configuration that works:

     SSLProtocol ALL -SSLv2 -SSLv3
     SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4
     SSLHonorCipherOrder on
     SSLCompression off

     Header always set Strict-Transport-Security "max-age=31536000"
     Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Simply adding "-TLSv1" to the SSLProtocol line to disable TLS 1.0 makes the relay responses fail.  We get an A+ on the SSLLabs server test with both configurations (with or without TLS 1.0).  Do you see anything in that config that could cause the problem?

[rockyjvec]

@RichardH,

Are you sure you support TLS 1.1 and 1.2?  Here is a dump of the handshake when it fails:

New TCP connection #2: sm1e.visadpsmessage.com(48369) <-> ******(443)
2 1  0.1093 (0.1093)  C>S  Handshake
      ClientHello
        Version 3.1 
        cipher suites
        Unknown value 0xc014
        Unknown value 0xc013
        Unknown value 0xc00a
        Unknown value 0xc009
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        compression methods
                  NULL
2    0.1104 (0.0010)  S>C  TCP FIN
2    0.2190 (0.1086)  C>S  TCP FIN
New TCP connection #3: sm1e.visadpsmessage.com(48371) <-> ******(443)
3 1  0.1158 (0.1158)  C>S  Handshake
      ClientHello
        Version 3.0 
        cipher suites
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_MD5
        Unknown value 0xff
        compression methods
                  NULL
3    0.1167 (0.0009)  S>C  TCP FIN
3    0.2268 (0.1100)  C>S  TCP FIN

Note that it is only trying to connect with version 3.1 (TLS 1.0) and version 3.0 (SSL 3.0)

From RFC2246:

version
       The version of the protocol being employed. This document
       describes TLS Version 1.0, which uses the version { 3, 1 }. The
       version value 3.1 is historical: TLS version 1.0 is a minor
       modification to the SSL 3.0 protocol, which bears the version
       value 3.0. (See Appendix A.1).

[RichardH]

I've reported your issue to the product team for analysis.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

[rockyjvec]

Thanks, will do.

[jgoebel]

According to my logs Authorize.Net is using TLSv1 for both post back and silent post.