Hi,

With Web Security Requirements, we maintain PCI Compliance for a number of our Servers and websites.

As part of PCI Checks TLS v1.0 is now no longer supported on PCI Compliant Servers.

We have seen some VisualCron traffic on TLS support / Controlling the Encryption for other Tasks:
http://www.visualcron.co....aspx?g=posts&t=4970  <SMTP>
7.6.2
[FEATURE] Client/Server: SMTP Task->Added support for setting supported SSL/TLS versions

e.g. Connections



With this Disabled on a Windows Test Server running IIS, it appears the HTTP Task (GET) now fails with <From VC 7.6.4 and Test VC 7.6.6>:
<Output (Error)> Error getting HTTP response: The underlying connection was closed: An unexpected error occurred on a send.

We are doing more testing but we think this is the change that causes the problem.

Looks like you are using SecureBlackBox . . . which should be compatible ?
https://www.eldos.com/sbb/desc-ssl-spec.php#http 

Are you able to confirm TLS Versions for this task (we are currently 7.6.4 in Production and have 7.6.4 and 7.6.6 available for Test also) ?

For the HTTP Task we do not use any external component. We use the .NET WebRequest. It negotiates to the highest available security - it is not possible to explictly set which security right now. More information here:

http://stackoverflow.com...m-net-webrequest-support 

---

Hi Henrik,

We have had a look at that and some other material.

The fact that VisualCron cannot connect with TLS v1.0 turned off means it is trying to connect with that protocol, we would think ?

We have this issue also with another Software Product built on .net.

The post above is mostly on about SSL v3 connections and not specifically TLS v1.0.

According to the wiki post in the article;
https://en.wikipedia.org...r_Security#TLS_handshake 

The first thing that happens is the client sends a message with the highest TLS protocol version it supports

Negotiation phase:
• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.

From out point of view, based on the above, we think it should be using TLS 1.2, and switching off TLS 1.0 should not have mattered . . . . if they are on.

See the information at the bottom of this Page you linked to:
--- snip ---
Update: It turns WebRequest does support TLS 1.1 and 1.2, but you have to turn them on manually at System.Net.ServicePointManager.SecurityProtocol. See also http://stackoverflow.com/a/26392698/284795 

I don't know why they are disabled out the box, that seems a poor setup choice, and tantamount to a bug. We should probably report it.
--- snip ---

We will certainly look further into it at our end

Hi Henrik,

We have had a look at that and some other material.

The fact that VisualCron cannot connect with TLS v1.0 turned off means it is trying to connect with that protocol, we would think ?

We have this issue also with another Software Product built on .net.

The post above is mostly on about SSL v3 connections and not specifically TLS v1.0.

According to the wiki post in the article;
https://en.wikipedia.org...r_Security#TLS_handshake 

The first thing that happens is the client sends a message with the highest TLS protocol version it supports

Negotiation phase:
• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.

From out point of view, based on the above, we think it should be using TLS 1.2, and switching off TLS 1.0 should not have mattered . . . . if they are on.

See the information at the bottom of this Page you linked to:
--- snip ---
Update: It turns WebRequest does support TLS 1.1 and 1.2, but you have to turn them on manually at System.Net.ServicePointManager.SecurityProtocol. See also http://stackoverflow.com/a/26392698/284795 

I don't know why they are disabled out the box, that seems a poor setup choice, and tantamount to a bug. We should probably report it.
--- snip ---

We will certainly look further into it at our end

Yes, we saw that post on StackOverFlow. Unfortunately these specific TLS options are not available for .NET 4.0. Seems like they were introduced in 4.5.

---

OK Thanks for that.

That is consistent with what we are hearing from another Software Vendor also.

Can we register a vote for a plan to get onto .net 4.5 or Bundle a 'HTTP with High Security' Task with .net 4.5. to enable operation with a higher security web server with disabled TLS 1.0 & SSL3 . . . . as time goes on I suspect this Task is going to run into more of these issues.

In the interim we will look at workarounds . . . for the PCI Compliant Servers

Powershell task Proof of Concept . . .

Yes, hopefully we will change this soon. I am moving this topic to Feature requests.

---

I think we might have found a workaround. Please test this version:

http://www.visualcron.co....aspx?g=posts&t=5208 

---

Hi Henrik,

Thanks for the tweak to the HTTP Task.

I can confirm that the HTTP Task in 7.7.7 <Beta> is now executing against TLS 1.2 Web Sites and returning consistent results with a Powershell check of a PCI Compliant website:

--- snip - Powershell Task Equivalent Check with Enforced TLS 1.2 ---
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
[System.Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest "https://**** Your PCI / TLS 1.2 Website Here ***" -UseBasicParsing
--- snip ---

Old Error Encountered in prior versions < VisualCron 7.7.7 :
<Error getting HTTP response: The underlying connection was closed: An unexpected error occurred on a send.>

Thanks !

K

Thanks for getting back to us!

---