CLIENT_HELLO has different cipher suites to the same URL from the same device

For example, here are two sets of cipher suites for two sequential connections to the same back end server:

Cipher Suites (14 suites)

Cipher Suite: Unknown (0x5a5a)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)

Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Cipher Suites (22 suites)

Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)

Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)

Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Is this with your app? Or with Safari?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is Safari communicating with back-end web servers on a private corporate network through a Network Extension VPN.

I’m not really the right person to address Safari issues. You might have more luck connecting with folks over in Safari and Web or the various WebKit support resources.

Once behaviour I have seen with

NSURLSession

— and it’s likely that Safari inherits it from there — is that it will retry failed TLS connections with different parameters in an attempt to get around the failure.

For example, historically some servers failed to support TLS version negotiation properly, and would just drop the connection on the floor if the client tried to connect with TLS 1.2 rather than some legacy TLS version. So

NSURLSession

will, in some situations, retry the connection with TLS 1.1, and maybe even 1.0, and that means a different set of cypher suites in each case.

The thing about this compatibility hack is that it kicks in regardless of what caused the TLS connection to fail (because the actual symptoms seen by the client are so varied), so I could imagine a situation where a TLS 1.2 connection to your server fails for some random reason and then Safari responds by retrying with a lower TLS version.

My advice: Look at the TLS version number in the Client Hello message to see if that’s correlated with the oddball cypher suites. And if it is, look through the packet trace to see if a similar TLS connection failed recently.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

It doesn't look like it's retrying with different parameters because of a failure in these cases.

In the specific example above both of the connections succeeded, and they were sequential--there was no other network traffic out of the device between those two connections.

In other cases we see a successful connection followed by a failure due to a change in the parameters, so that doesn't quite match either.

I'll see about asking in Safari & Web...

Oh--forgot to mention that the TLS parameters are the same in each case (other than cipher suites) with the single exception that there is sometimes padding. The padded/unpadded difference introduces problems of its own, but doesn't appear to be correlated with the cipher suite differences.

Well, absolutely no responses in the Safari & Web section... Any other ideas about where this might get a response?

Any other ideas about where this might get a response?

Normally in situations like this I’d bounce you in to DTS but we don’t support Safari. Some thoughts:

• WebKit has a significant online presence and, while this isn’t strictly a WebKit issue, the folks over there might have direct experience with it.

• Likewise with Apple Support Communities, run by Apple Support.

• The ultimate backstop for Safari issues is Apple Support, with the main drawback being that you’ll need a high-level of support for them to take on a question like this.

Alternatively, if you can reproduce this problem with

NSURLSession

, I’m pretty sure I could convince my management to let me answer it via a DTS tech support incident.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"