Problem with Cipher Suite View

[paulwyszynski]

Description

I have a problem with the cipher suite list in the summary. There are more available cipher suites in the list, than my httpclient supports/has restricted. Is this a known issue?

Checked with CharlesProxy and it shows the expected behavior.

Steps to Reproduce

I've tested it with Android 9/ Android 13, OkHttpClient 4.11

Supported ciphers from my httpclient (OkHttpClient):

0 = "TLS_AES_128_GCM_SHA256" 1 = "TLS_AES_256_GCM_SHA384" 2 = "TLS_CHACHA20_POLY1305_SHA256" 3 = "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256" 4 = "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" 5 = "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" 6 = "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 7 = "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256" 8 = "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"

Proxyman shows a larger list:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA

Current Behavior

Too many ciphers in the list.

Expected Behavior

List should be the same as restricted through OkHttpClient ( ConnectionSpec.RESTRICTED_TLS)

Environment

• App version: Proxyman 4.8.1
• macOS version: MacOS Ventura 13.4.1

[NghiaTranUIT]

Thanks @paulwyszynski , I've noticed this issue too.

I retrieve the list of Cipher suits from SSLHandler (SwiftNIO) when it performs the SSL Handshake. It returns the List of supported suits and the choosen one. I'm not sure it doesn't match our expectations.

I will investigate it 👍

[paulwyszynski]

In my case it doesn't even show the ones allowed e.g. the TLS_AES_.... aren't in the below list. This can't be correct.

Thank you @NghiaTranUIT

[NghiaTranUIT]

@paulwyszynski I did an investigation on this bug. It turns out:

• A list of cipher suits, that Proxyman displays, is a list that Proxyman supports during the SSL Handshake. It's not a list that your client supports.
• When both server & client choose a certain cipher suit, it will display as a Negocated Cipher row.

---

Meanwhile, Charles Proxy shows the Client Supported.

[paulwyszynski]

Hi @NghiaTranUIT,

yes, CharlesProxy shows the client supported, and I think this is correct, because I'm interested in all the data regarding my client traffic. Is this gonna be fixed?

[rakeeb-hossain]

Bumping this, I think this should follow CharlesProxy as well. It makes it difficult to test endpoints with TLS fingerprinting enabled.

[NghiaTranUIT]

I tried but I haven't found any reliable solution yet : /

SwiftNIO doesn't expose any methods to get the cipher suite from the Client.

[paulwyszynski]

Ok, for me it was an extreme edge case, because I had to double check this out after our app has been tested for security issues. But it's definitely a nice to have feature in upcoming release.