Can't connect to external TFS build after enforcing TLS 1.2 on Release Server

[ruairiohagan]

Hi,

We have 3 TFS servers installed, one in our development environment (which is the artifact source), then two other installations in our test and production environments which consume the build artifacts from the dev TFS instance and deploy them to their respective environments.

We have recently began enforcing TLS 1.2 communications on our test environment in preparation for it being enforced on our production env. Connections from both test and prod to dev are via https.

Since we have done that we can no longer connect to artifacts on our dev instance from test (but still can from prod). The error returned from the endpoint configuration screen in the services tab is:

"Failed to query service endpoint api: https:///tfs//_apis/projects. Error Message: The underlying connection was closed: An unexpected error occurred on a receive.. "

Note we can still connect directly to the dev instance from test using a browser - and can also retrieve the JSON file form the url it says it cannot connect to.

All TFS servers are on premises running version 15.117.26714.0.

Any help or ideas for a resolution would be greatly appreciated.

Thanks,

Ruairi.

[Lovakumar]

This is pretty old issue. Closing this for now. Please re-activate if this is still an issue.

[ruairiohagan]

Hi,

This is still an issue for us. We need to enforce TLS 1.2 in our production environment for our PCI security certification.

At the minute we have to implement compensating controls to work around it, but that can only be a temporary measure.

Please re-activate this issue, we still need a fix for it.

[Lovakumar]

Can you try steps mentioned in https://developercommunity.visualstudio.com/content/problem/186106/tfs-compatibility-with-tls-12.html

[ruairiohagan]

It is only the release extension that does not support TLS 1.2, not TFS itself.

When TLS 1.2 is enforced on the production (release) server, I can still access the TFS web portal on the development (build) over https, but the release extension does not work, as described above.

When I allow TLS 1.0 client to work from the production server in the registry, the release extension starts working again too.

(note that we are also have another issue with the latest release of the extension as reported in issue #521, so we'd need both issues resolved before we can deploy an update to our production environment)

Thanks!

[omeshp]

@ruairiohagan What version of tfs server is running on dev and test instances?

Can you run the below powershell command from both dev and test servers and share the results? (Invoke-WebRequest -Uri https://www.howsmyssl.com/a/check).RawContent

Run the below powershell command from the test server and share the output. Replace the pattoken with the generated pat token and serverurl with your server.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$base64 = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":pattoken"))
$headers = @{ Authorization = "Basic $base64" }
Invoke-WebRequest -Uri https:///serverurl/_apis/projects -Headers $headers

[ruairiohagan]

@omeshp ,

howsmyssl from TEST TFS server:

HTTP/1.1 200 OK Access-Control-Allow-Origin: * Connection: close Strict-Transport-Security: max-age=631138519; includeSubdomains; preload Content-Length: 1231 Content-Type: application/json Date: Wed, 11 Sep 2019 07:40:39 GMT

{ "given_cipher_suites": ["TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_DHE_DSS_WITH_AES_256_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_DSS_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": true, "insecure_cipher_suites": { "TLS_DHE_DSS_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_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.0", "rating": "Bad" }

howsmyssl from DEV TFS server:

HTTP/1.1 200 OK Access-Control-Allow-Origin: * Connection: close Strict-Transport-Security: max-age=631138519; includeSubdomains; preload Content-Length: 1232 Content-Type: application/json Date: Wed, 11 Sep 2019 07:43:41 GMT

{ "given_cipher_suites": ["TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_DHE_DSS_WITH_AES_256_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_RC4_128_MD5"], "ephemeral_keys_supported": true, "session_ticket_supported": false, "tls_compression_supported": false, "unknown_cipher_suite_supported": false, "beast_vuln": false, "able_to_detect_n_minus_one_splitting": true, "insecure_cipher_suites": { "TLS_DHE_DSS_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_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.0", "rating": "Bad" }

Response of last PS script running on test server pointing to dev server:

StatusCode : 200 StatusDescription : OK Content : {"count":1,"value":[{"id":"4b6bece7-ad1f-4a53-8fb3-ff2be21ee65a","name":"Main","description":"General Repository","url":"https://dev-tfsserver/tfs/DeciphaDev/_apis/projects/4b6bece7-ad1f-4a53-8fb3-ff2... RawContent : HTTP/1.1 200 OK Pragma: no-cache X-TFS-ProcessId: e704a1e6-952d-4871-9ea6-d2e21aa18af0 ActivityId: 7cf6cf3f-9057-42ae-a1db-1ace2bd7b4de X-TFS-Session: 7cf6cf3f-9057-42ae-a1db-1ace2bd7b4de X-VSS-E... Forms : {} Headers : {[Pragma, no-cache], [X-TFS-ProcessId, e704a1e6-952d-4871-9ea6-d2e21aa18af0], [ActivityId, 7cf6cf3f-9057-42ae-a1db-1ace2bd7b4de], [X-TFS-Session, 7cf6cf3f-9057-42ae-a1db-1ace2bd7b4de]...} Images : {} InputFields : {} Links : {} ParsedHtml : mshtml.HTMLDocumentClass RawContentLength : 271

[omeshp]

@ruairiohagan Thanks for that info, looks like by default TLS 1.0 is getting used on test server. Can you run the below query too:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
(Invoke-WebRequest -Uri https://www.howsmyssl.com/a/check).RawContent

[ruairiohagan]

Hi @omeshp ,

We current have tls 1.0 enabled because if we enforce TLS 1.2 the connection just doesn't work.

Running your script (with TLS 1.0 still enabled) I get:

HTTP/1.1 200 OK Access-Control-Allow-Origin: * Connection: close Strict-Transport-Security: max-age=631138519; includeSubdomains; preload Content-Length: 1768 Content-Type: application/json Date: Thu, 12 Sep 2019 01:59:11 GMT

{ "given_cipher_suites": ["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_DHE_RSA_WITH_AES_256_GCM_SHA384", "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_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_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_DHE_DSS_WITH_AES_256_CBC_SHA256", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256", "TLS_DHE_DSS_WITH_AES_256_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_DSS_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_DHE_DSS_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_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" }