cancel
Showing results for 
Search instead for 
Did you mean: 

dotnet TSL 1.2

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.

bobbydoogle
Contributor
9 REPLIES 9

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. 

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

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.?

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;

 

Powered by NexWebSites.com -
Certified Authorize.net developers

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.

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 

Powered by NexWebSites.com -
Certified Authorize.net developers

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?

 

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. 

Great. Glad to hear it.

Powered by NexWebSites.com -
Certified Authorize.net developers

ah!  adding this before my httpwebrequest worked.

 

Const _Tls12 As SslProtocols = DirectCast(&HC00, SslProtocols)

Const Tls12 As SecurityProtocolType = DirectCast(_Tls12, SecurityProtocolType)

ServicePointManager.SecurityProtocol = Tls12