다음을 통해 공유

Azure Troubleshooting: Authentication failed because the remote party has closed the transport stream

  • 아티클

Introduction

We quite often make changes on the Azure side of things to ensure the level of security is where it needs to be. There’s however scenarios where customers may not have an infrastructure that supports these security requirements.

Recently worked a scenario where a native application developed in .NET 4.0 was unable to acquire a token from Azure when running on Windows XP SP3 machines.

On the other hand, the same native application developed in .NET 4.5 and running on Windows 10 machines, could successfully authenticate and obtain a token from Azure.

Data Gathering

Initial thoughts formed around .NET 4.0 being outdated, however, this did not align with the data.

The native application returned the following error:

System.AggregateException: One or more errors occurred.

---> System.Net.Http.HttpRequestException: An error occurred while sending the request.

---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.

---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

 at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

 at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)

 at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

 --- End of inner exception stack trace ---

 at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult TransportContext& context)

 at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

 --- End of inner exception stack trace ---

This broadened the scope to move up a level and check the communication between the native application and Azure.

Fidler

Used a tool called Fiddler to view the HTTP traffic from both the working Windows 10 machine and the non-working Windows XP machine.

Tool can be downloaded here: https://www.telerik.com/download/fiddler/fiddler4

Observed the following steps in the Fiddler for the Windows 10 machine:

  1. CONNECT login.windows.net
  2. Response: HTTP 200 Connection Established
  3. POST login.windows.net/oauth2/token
  4. Response: HTTP 200 OK
  5. CONNECT Azure Web App (site.azurewebsites.net)
  6. Response: HTTP 200 Connection Established
  7. GET Azure Web App (site.azurewebsites.net/api)
  8. Response: HTTP 200 OK

All of these steps were successful, as well as the Bearer authorization header present.

Moved along to the Windows XP Fiddler trace and observed the following:

  1. CONNECT login.windows.net
  2. Response: HTTP 501 DNS Lookup Failed
  3. CONNECT Azure Web App (site.azurewebsites.net)
  4. Response: HTTP 200 Connection Established
    1. HTTPS handshake to site.azurewebsites.net failed. System.IO.IOException Authentication failed because the remote party has closed the transport stream.

 

The Fiddler trace presented an error similar to that of the native application, however, could not confirm what caused the DNS failure (Fiddler or XP client), which could've led to the handshake failure.

Next step was to get a network capture from the Windows XP machine to provide more clarity.

Flow:

Windows XP > login.windows.net = successful TLS 1.0 handshake

Windows XP > site.azurewebsites.net = incomplete handshake

Client Hello

Narrowed down the focus to the following details within the Client Hello sent from the Windows XP machine:

- TLS: TLS Rec Layer-1 HandShake: Client Hello.

 + Version: TLS 1.0

 + RandomBytes:

 SessionIDLength: 0 (0x0)

 CipherSuitesLength: 22

 + TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5                { 0x00,0x04 }

 + TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }

 + TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA           { 0x00,0x0A }

 + TLSCipherSuites: TLS_RSA_WITH_DES_CBC_SHA { 0x00,0x09 }

 + TLSCipherSuites: TLS_NTRU_NSS_WITH_AES_256_CBC_SHA { 0x00, 0x64 }

 + TLSCipherSuites: TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA { 0x00, 0x62 }

 + TLSCipherSuites: TLS_RSA_EXPORT_WITH_RC4_40_MD5 { 0x00,0x03 }

 + TLSCipherSuites: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 { 0x00,0x06 }

 + TLSCipherSuites: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA { 0x00,0x13 }

 + TLSCipherSuites: TLS_DHE_DSS_WITH_DES_CBC_SHA { 0x00,0x12 }

 + TLSCipherSuites: TLS_NTRU_NSS_WITH_AES_128_CBC_SHA { 0x00, 0x63 }

 

The Server Hello from login.windows.net contained the following:

- TLS: TLS Rec Layer-1 HandShake: Server Hello. Certificate.

 + Version: TLS 1.0

 Length: 4689 (0x1251)

 - SSLHandshake: SSL HandShake Certificate(0x0B)

 HandShakeType: ServerHello(0x02)

 Length: 77 (0x4D)

 - ServerHello: 0x1

 + Version: TLS 1.0

 TLSCipherSuite: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }

The network trace continues on indicating a successful handshake between the Windows XP client and login.windows.net.

The Client Hello from the Windows XP machine contains the exact same details as the Client Hello sent to login.windows.net. This led me to proceed with an SSL analysis.

NOTE: There’s a free SSL Report tool from Qualys that can be found here: https://www.ssllabs.com/

First ran the tool against login.windows.net: https://www.ssllabs.com/ssltest/analyze.html?d=login.windows.net&s=23.100.32.136&latest

There’s a configuration section that returns the following details:

Configuration

https://www.ssllabs.com/images/icon-protocol.png

Protocols
TLS 1.3
No
TLS 1.2
Yes
TLS 1.1
Yes
TLS 1.0
Yes
SSL 3
No
SSL 2
No
For TLS 1.3 tests, we currently support draft version 18.

https://www.ssllabs.com/images/icon-cipher.png

Cipher Suites
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.1 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.0 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112

I confirmed the same details observed in the network capture, that both the Windows XP SP3 machine and login.windows.net support TLS 1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA.

I ran the same SSL report against site.azurewebsites.net and the following cipher suites are supported:

Configuration

https://www.ssllabs.com/images/icon-protocol.png

Protocols
TLS 1.3
No
TLS 1.2
Yes
TLS 1.1
Yes
TLS 1.0
Yes
SSL 3
No
SSL 2
No
For TLS 1.3 tests, we currently support draft version 18.

https://www.ssllabs.com/images/icon-cipher.png

Cipher Suites
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.1 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
https://www.ssllabs.com/images/collapse.pnghttps://www.ssllabs.com/images/expand.png # TLS 1.0 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128

 

Notice site.azurewebsites.net did not support TLS 1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA as the Windows XP client and login.windows.net.

The last part was to confirm the Windows XP cipher suites. This OS is however not supported by the SSL Report. Instead found an article referencing the TLS 1.0 cipher suites for Windows XP.

TLS_RSA_WITH_RC4_128_MD5

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_DES_CBC_SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

TLS_RSA_WITH_NULL_MD5

TLS_RSA_WITH_NULL_SHA

https://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx

Not only does the Windows XP client not have any cipher suites in common with site.azurewebsites.net, it is not capable of supporting any of the cipher suites offered.

Did a bit of research and discovered that Azure Web Apps notified customers that the TLS/SSL cryptography would be upgraded to improve security:

https://social.msdn.microsoft.com/Forums/azure/en-US/6530d35a-9321-4e61-a496-39b66c63a1a0/we-are-updating-our-tlsssl-cipher-suites-to-improve-security

During this upgrade, the 3DES cipher was removed, which leads to an unsupported scenario for Windows XP SP3 machines connecting to Azure Web Apps (site.azurewebsites.com).

Conclusion

Although this scenario is not supported out of the box, there are other options such as utilizing Azure Application Gateway to offload SSL and forward the requests to site.azurewebsites.net.

Learn more

Azure Application Gateway here: /en-us/azure/application-gateway/application-gateway-ssl-policy-overview

Errors

 Errors that can indicate an uncommon cipher suite scenario:

  • Authentication failed because the remote party has closed the transport stream.
  • HTTPS handshake to site.azurewebsites.net failed.

References