topic Re: dotnet TSL 1.2 in Integration and Testing

dotnet TSL 1.2

bobbydoogle — Sat, 10 Feb 2018 21:57:59 GMT

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.

Re: dotnet TSL 1.2

NexusSoftware — Sun, 11 Feb 2018 18:52:05 GMT

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/highlight/true#M36009 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.

Re: dotnet TSL 1.2

bobbydoogle — Sun, 11 Feb 2018 20:43:23 GMT

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

Re: dotnet TSL 1.2

NexusSoftware — Sun, 11 Feb 2018 20:55:26 GMT

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;

Re: dotnet TSL 1.2

bobbydoogle — Sun, 11 Feb 2018 21:16:11 GMT

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.

Re: dotnet TSL 1.2

NexusSoftware — Sun, 11 Feb 2018 23:38:22 GMT

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

Re: dotnet TSL 1.2

bobbydoogle — Tue, 13 Feb 2018 13:05:21 GMT

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?

Re: dotnet TSL 1.2

bobbydoogle — Tue, 13 Feb 2018 13:23:19 GMT

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.

Re: dotnet TSL 1.2

NexusSoftware — Tue, 13 Feb 2018 14:14:50 GMT

Great. Glad to hear it.

Re: dotnet TSL 1.2

nmah — Tue, 20 Mar 2018 15:41:13 GMT

ah! adding this before my httpwebrequest worked.

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

Const Tls12 As SecurityProtocolType = DirectCast(_Tls12, SecurityProtocolType)

ServicePointManager.SecurityProtocol = Tls12