I have been reading on dotnet TSL 1.2 and am having difficultly confirming if my application's authnet integration is or is not using TSL 1.2. I know the server it is hosted on supports TSL 1.2 form a SSL check, I'm using entity framework 4.5 with package id="AuthorizeNet" version="1.8.3" targetFramework="net45". Any steps to confirm would be most appreciated.
02-10-2018 01:57 PM
You could do a simple test as outlined at : https://community.developer.authorize.net/t5/Integration-and-Testing/TLS-1-2-Migration/m-p/61582/hig... in order to verify your server is connecting via a TLS 1.2 connection.
If you are able to connect to the Sandbox, you are good to go, because the Sandbox has been accepting only TLS 1.2 connections for a while now.
02-11-2018 10:52 AM
On my local development computer in sandbox mode (not the server that runs our production integration in live mode), I get an error with Additional information: The request was aborted: Could not create SSL/TLS secure channel. How can I tell if this is to do with my computer/network or our authorize.net dotnet api / etc.?
02-11-2018 12:42 PM - edited 02-11-2018 12:43 PM
You could run the same test on your local machine, it is likely to be the source of the error.
For .Net applications, be sure to use the following before your application's webRequest:
const SslProtocols _Tls12 = (SslProtocols)0x00000C00; const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12; ServicePointManager.SecurityProtocol = Tls12;
02-11-2018 12:55 PM
This is all very helpful, however, regarding specifying SslProtocols, I'm not sure I'm making a webRequest per say, I use dotnet from Package Manager installation. For instance the simple code I used to create the error locally was this:
Gateway target = AuthNet.Gateway(); IGatewayRequest request = new AuthorizationRequest( ccNumber, expNumber, amount, "AuthOnly", false );
The AuthNet.Gateway() just does the following:
return new Gateway( AuthNet._apiLoginTest, AuthNet._transactionKeyTest, true );
Is this a webRequest in terms of needing to specify the code you mentioned? Additionally, any information on if the 1.8.3 version of Authorize.net dotnet package was TSL1.2 compatible? I would rather not upgrade if not necessary.
My local dev machine outputs this to the requested C# test:
{"given_cipher_suites":["TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_RSA_WITH_AES_256_GCM_SHA384","TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE_CBC_SHA","TLS_RSA_WITH_RC4_128_SHA","TLS_RSA_WITH_RC4_128_MD5"],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{"TLS_RSA_WITH_3DES_EDE_CBC_SHA":["uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"],"TLS_RSA_WITH_RC4_128_MD5":["uses RC4 which has insecure biases in its output"],"TLS_RSA_WITH_RC4_128_SHA":["uses RC4 which has insecure biases in its output"]},"tls_version":"TLS 1.2","rating":"Bad"}
I have yet to try this in production yet, that is one of my next steps. Appreciate any further tips on this.
02-11-2018 01:15 PM - edited 02-11-2018 01:16 PM
In the newer versions of the SDK, you shouldn't need to specify those TLS parameters.
From the results you received, this is due to your machine supporting an insecure cipher suite.
Any client supporting an insecure cipher suite will be marked as Bad.
You could modify the Cypher Suites and edit the Registry Keys manually or use the free application at : https://www.nartac.com/Products/IISCrypto
02-11-2018 03:37 PM - edited 02-11-2018 03:38 PM
On my windows 10 development machine I downloaded and ran the IISCrypto tool and set best practices option. Rerunning the test results in:
{"given_cipher_suites":["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE_CBC_SHA"],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Probably Okay"}
Probably Okay. However I am still getting "The request was aborted: Could not create SSL/TLS secure channel." attempting to connect to Sandbox. I am going to attempt to update my SDK to the latest version now. Any other suggestions regarding my test environment?
02-13-2018 05:05 AM
Good news, I got it working on my dev machine. As you had mentioned, with slight variation, I used
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Prior to running my code and also ran the IISCrypto tool you recommended with best practices settings. A few more tests and I should be able to repeat this process on my production machine.
02-13-2018 05:19 AM - edited 02-13-2018 05:23 AM
Great. Glad to hear it.
02-13-2018 06:14 AM
ah! adding this before my httpwebrequest worked.
Const _Tls12 As SslProtocols = DirectCast(&HC00, SslProtocols)
Const Tls12 As SecurityProtocolType = DirectCast(_Tls12, SecurityProtocolType)
ServicePointManager.SecurityProtocol = Tls12
03-20-2018 08:41 AM