1

I am curious into the Passing Weak Cipher through NWProtocolTLS.Options(). Because its working fine in iOS 12 but on iOS 13 Apple they did some changes I guess so it is stopped taking it.

One thing here is: How OpenSSL it takes weak cipher(TLS_DHE_RSA_WITH_AES_256_GCM_SHA384) and establish the connection. and why iOS 13 Network.framework not takes.

Basically, My Socket server already froze with the weak cipher TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 this one I have captured from Server Hello through OpenSSL using WireShark. So now I pass this cipher using iOS 13 in the following method but it's not working.

sec_protocol_options_append_tls_ciphersuite(tlsOptions.securityProtocolOptions, tls_ciphersuite_t.ECDHE_RSA_WITH_AES_256_GCM_SHA384)

Note: We have already raised Feedback Assistant query but still we are waiting from them. This is not a Web Socket, We connect through Server Wifi Hotspot.

Somehow we have solved this issue with the help of OpenSSL Library(https://github.com/levigroker/GRKOpenSSLFramework) for iOS but after the long data polling and byte buffer mechanism and facing lot of issues when it comes handling the longer data.

In OpenSSL iOS App after look at the Client Hello its passes the 86 Ciphers and its works.

But in iOS Network.framework passing the client Hello its passes the 36 Ciphers and its not works.

If anyone wants to have look at the WireShark packets please add a comment, I will attach it further.

So Any idea or help appreciated!

iTag
  • 409
  • 3
  • 19
  • DHE and ECDHE are different algorithms (though with similar mathematical underpinnings) and DHE_RSA and ECDHE_RSA are completely separate TLS keyexchanges; if you want the former, don't use the latter. – dave_thompson_085 Jul 08 '20 at 06:19
  • Okay @dave_thompson_085 but we are not getting an exact match of TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 in iOS 13 updated cipher suite – iTag Jul 08 '20 at 09:05

1 Answers1

1

Network framework uses BoringSSL internally. On trying to connect with the weak cipher(TLS_DHE_RSA_WITH_AES_256_GCM_SHA384) that is not supported on iOS 13.0 and above, BoringSSL does not drop the handshake, but instead vends a default cipher array comprising of


TLS_AES_128_GCM_SHA256,
TLS_AES_256_GCM_SHA384,
TLS_CHACHA20_POLY1305_SHA256,
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_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
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_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
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_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA

The only solution to this is to please try to implement any of the above ciphers on the server side.

Subha_26
  • 440
  • 4
  • 14