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.

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:

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

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.

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

You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.