Привязка сертификатов iOS 13 с помощью слабого шифра перестала работать, но отлично работает в iOS 12

Question

Мне интересно узнать о передаче слабого шифра через NWProtocolTLS.Options(). Поскольку он работает нормально в iOS 12, но в iOS 13 Apple, я думаю, внесли некоторые изменения, поэтому он перестал его принимать.

Вот одна вещь: как OpenSSL принимает слабый шифр (TLS_DHE_RSA_WITH_AES_256_GCM_SHA384) и устанавливает соединение. и почему iOS 13 Network.framework не берет.

По сути, сервер My Socket уже завис со слабым шифром TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, который я захватил из Server Hello через OpenSSL с помощью WireShark. Итак, теперь я передаю этот шифр с помощью iOS 13 следующим способом, но он не работает.

sec_protocol_options_append_tls_ciphersuite(tlsOptions.securityProtocolOptions, tls_ciphersuite_t.ECDHE_RSA_WITH_AES_256_GCM_SHA384)

Примечание: мы уже поднимали запрос к помощнику по обратной связи, но все еще ждем его. Это не веб-сокет, мы подключаемся через сервер Wifi Hotspot.

Каким-то образом мы решили эту проблему с помощью библиотеки OpenSSL (https://github.com/levigroker/GRKOpenSSLFramework) для iOS, но после длительного опроса данных и механизма байтового буфера и столкнулись с множеством проблем при обработке более длинных данных.

В приложении OpenSSL iOS после просмотра Client Hello он передает 86 шифров и работает.

Но в iOS Network.framework, передавая клиенту Hello, он передает 36 шифров и не работает.

Если кто-то хочет взглянуть на пакеты WireShark, добавьте комментарий, я приложу его дальше.

Итак, любая идея или помощь приветствуются!

Answer 1

Сетевая структура использует BoringSSL внутри. При попытке подключиться со слабым шифром (TLS_DHE_RSA_WITH_AES_256_GCM_SHA384), который не поддерживается в iOS 13.0 и выше, BoringSSL не отбрасывает рукопожатие, а вместо этого предлагает массив шифров по умолчанию, состоящий из

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

Единственное решение - попробовать реализовать любой из вышеперечисленных шифров на стороне сервера.