Search code examples
opensslios13certificate-pinningswift-nionetwork-framework

iOS 13 Certificate Pinning with Weak Cipher stopped working But works fine in iOS 12


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!


Solution

  • 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.