клиент и сервер не могут общаться, потому что у них нет общего алгоритма - SSLStream

Уже есть ответы на множество подобных вопросов, и ни один из ответов не помогает моему текущему сценарию.

В службе Windows у нас есть поток TCPL SSL и клиент, подключающийся к потоку.

Я создал .NET-клиент и могу успешно получить доступ к серверу с помощью Strict TLS 1.2 с использованием IIS Crypto.

Мы пытаемся получить доступ к серверу с помощью Lantronix xport Pro, и в строке ниже выдается исключение.

stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Ssl3| SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, True);

Исключение происходит, только если включен строгий TLS 1.2. Если у нас включен протокол SSL3, все работает без проблем.

используя WireShark, я вижу, как клиент отправляет запрос TLS 1.2 с приведенными ниже шифрами

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

В соответствии с MSDN, указанным выше, шифры поддерживают TLS 1.2.

У меня нет проблем с подключением к клиенту .net, который мы создали для тестирования со строгим протоколом TLS 1.2

Создание самоподписанного сертификата с использованием открытого ssl. сервер работает под управлением Windows Server 2012 R2.

Не уверены, какие варианты мне следует попробовать для SSLstream, специфичного для TLS 1.2?

Есть ли что-то особенное, что мне нужно для общения, кроме .net-клиента?

Любые предложения по отслеживанию этой проблемы были бы замечательными

Обновление по запросу Lantrix Pro

Frame 33845: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Ethernet II, Src: Pronet_c7:bb:29 (00:20:4a:c7:bb:29), Dst: Vmware_99:95:c7 (00:50:56:99:95:c7)
Internet Protocol Version 4, Src: 10.10.110.71, Dst: 10.10.110.10
Transmission Control Protocol, Src Port: 38182, Dst Port: 28000, Seq: 1, Ack: 1, Len: 58
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 53
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 49
            Version: TLS 1.2 (0x0303)
            Random: 8a f5 6f 9e 92 65 43 c7 45 9b 57 ff dd a4 22 45 ...
                GMT Unix Time: Nov 16, 2043 20:38:22.000000000 Central Standard Time
                Random Bytes: 92 65 43 c7 45 9b 57 ff dd a4 22 45 12 16 cb 41 ...
            Session ID Length: 0
            Cipher Suites Length: 10
            Cipher Suites (5 suites)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)

person Peru    schedule 03.04.2018    source источник
comment
Это практически то же самое, что и этот вопрос. Как я уже сказал, это означает, что Lantronix xport Pro не поддерживает TLS 1.2. В документации к устройству заявлена ​​поддержка только SSLv3. Хотя вы утверждаете, что устройство поддерживает TLS 1.2 (вопреки документации), вы все же не предоставили доказательств этого в виде pcap.   -  person Steffen Ullrich    schedule 04.04.2018
comment
@Tharun Я не вижу подтверждения SSL в этом захвате. ОТСУТСТВИЕ квитирования означает, что ОТСУТСТВИЕ приветствия клиента означает НЕЛЬЗЯ сказать, что вы используете TLS 1.2.   -  person Eugène Adell    schedule 04.04.2018
comment
@ EugèneAdell, я смотрю на компьютерную карту, которой я поделился. Привет от клиента сгенерирован из 10.10.110.71   -  person Peru    schedule 04.04.2018
comment
почему отрицательные голоса? Я поделился pcap, и я вижу приветствие клиента, созданное с помощью TLS 1.2   -  person Peru    schedule 04.04.2018
comment
@SteffenUllrich, я обновил вопрос с помощью PCAP-запроса клиента привет   -  person Peru    schedule 04.04.2018
comment
@ EugèneAdell, я обновил вопрос с помощью PCAP-запроса клиента привет   -  person Peru    schedule 04.04.2018
comment
@Tharun Пожалуйста, опубликуйте захват и сообщите номер пакета этого Client Hello. Тогда мы сможем проследить и увидеть ответ сервера.   -  person Eugène Adell    schedule 04.04.2018
comment
@SteffenUllrich, я обновил pcap drive.google.com/open?id=1ubBgrd6LandGoogle.com/open?id=1ubkfrd6L и также номер пакета :: 33845   -  person Peru    schedule 04.04.2018
comment
@Tharun: вы проверили, что ваш конкретный сервер действительно поддерживает какой-либо из этих шифров? Вероятно, единственный безопасный из них - TLS_RSA_WITH_AES_128_CBC_SHA. Вы можете проверить, например, с помощью openssl s_client -connect host:port -cipher "AES128-SHA" и посмотреть, будет ли у вас успешное рукопожатие. Если вы это сделаете, пожалуйста, также предоставьте pcap этого рукопожатия для сравнения с неудавшимся рукопожатием.   -  person Steffen Ullrich    schedule 04.04.2018
comment
@SteffenUllrich Еще одна проблема с файловым шифром_Openssl client.pcapng Я выполнил вашу команду openssl packetNumber: 2337. Как я уже упоминал, сервер использует TCP SSLStream, а не http. пожалуйста, дай мне знать, если возникнут какие-либо вопросы   -  person Peru    schedule 04.04.2018


Ответы (1)


TL; DR: клиент сломан. Похоже, что поставщик практически не добавил минимальную поддержку TLS 1.2 в старый продукт, сохранив при этом небезопасные шифры и не добавив поддержку для используемых в настоящее время подписанных сертификатов SHA-256.


Клиент отправляет только минимальное подтверждение TLS 1.2. Он содержит только 5 шифров (где 3 шифра EXPORT критически небезопасны, шифр 3DES немного небезопасен, но допустим AES128-SHA). И, по сравнению с другими успешными рукопожатиями TLS 1.2, он не содержит алгоритм сигнатуры Расширение TLS.

Это расширение впервые в TLS 1.2. Он используется, чтобы сообщить серверу, какие алгоритмы подписи поддерживаются. Если расширение не предоставлено, по умолчанию будет использоваться SHA1 с RSA для предлагаемых шифров. Цитата из RFC:

Если клиент не отправляет расширение signature_algorithms, сервер ДОЛЖЕН сделать следующее:

  • Если согласованный алгоритм обмена ключами является одним из (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), вести себя так, как если бы клиент отправил значение {sha1, rsa}.

Но сервер предоставляет сертификат с ключом RSA, но с хешем SHA-256. Таким образом, этот сертификат не будет соответствовать принятым алгоритмам подписи, и рукопожатие не будет выполнено. Если сервер вместо этого разрешает TLS 1.1 или ниже, то рукопожатие будет успешным, поскольку расширение signature_algorithm игнорируется с этими более низкими версиями протокола, и, таким образом, сервер может отправить подписанный сертификат SHA-256, который у него есть.

Как видно из захвата с помощью openssl s_client в предоставленных pcaps, квитирование TLS 1.2 работает, если клиент предоставляет расширение signature_algorithm и сигнализирует о поддержке RSA и SHA-256.

person Steffen Ullrich    schedule 04.04.2018
comment
Спасибо @SteffenUllrich за подробный анализ. как вы думаете, это может быть связано с stackoverflow.com/questions/22825663/ или как я могу справиться с этим из моего кода .net, шаги создания сертификата SSL, поскольку у меня очень мало контроля над клиентом? - person Peru; 04.04.2018
comment
извините, если вопросы звучат глупо, я относительно новичок в этой стороне криптографии. мы используем открытый SSL для создания самоподписанных сертификатов. если мы будем использовать любой другой хеш для создания сертификатов, совпадут ли шифры? - person Peru; 04.04.2018
comment
@Tharun: Я не думаю, что это связано. Что касается сертификата: они создаются вне серверного приложения, например, покупаются в общедоступном ЦС. Но сертификаты SHA-1 на какое-то время устарели, поэтому ни один публичный центр сертификации не выдаст такой сертификат. Но, если поставщик утверждает, что поддерживает TLS 1.2, он должен исправить проблему. На данный момент ваш единственный выбор, вероятно, только также разрешить TLS 1.1 и, возможно, TLS 1.0, который все еще достаточно безопасен. - person Steffen Ullrich; 04.04.2018
comment
@Tharun: если вы создаете самозаверяющие сертификаты, вы можете просто использовать sha1 в качестве алгоритма хеширования для создания сертификата. Но, возможно, было бы лучше оставить sha256 и вместо этого также принять TLS 1.1. - person Steffen Ullrich; 04.04.2018
comment
Спасибо @SteffenUllrich за подробные ответы. - person Peru; 04.04.2018
comment
@SteffenUllrich, я попробовал 2 вещи, но обе не сработали. Включает TLS 1.1, также попытался создать самоподписанный SHA1. Работает только с TLS 1.0 и более ранними версиями. - person Peru; 05.04.2018
comment
@Tharun: сложно сказать, что здесь происходит. Удостоверились ли вы, что тесты TLS 1.1 и SHA-1 действительно работают с openssl s_client (например, cmdline -tls1_1), и можете ли вы предоставить pcaps для успешных тестов s_client и неудачных тестов с Lantrix Pro для той же настройки сервера? - person Steffen Ullrich; 05.04.2018
comment
@SteffenUllrich, я думаю, я этого недостаточно понимаю. Я пробовал openssl s_client -connect host: port -cipher AES128-SHA Согласование происходит с TLS 1.1. Я попробовал openssl s_client -connect host: port -tls1_2, затем согласование не удалось. если я сделаю сервер строгим TLS1.2 openssl s_client -connect host: port -cipher AES128-SHA также не сработает. это происходит только в TCP SSLStream 28000 порт нет. если я использую openssl с портом 443, все работает нормально. - person Peru; 05.04.2018
comment
@Tharun: Я предполагаю, что на порту 443 у вас есть какой-то веб-сервер, а на порту 28000 - ваш специальный .net-сервер, то есть разные серверы с разными настройками. В этом случае я предполагаю, что в вашем конкретном приложении тоже есть проблема, но я недостаточно разбираюсь в вашем приложении, и у меня нет возможности воспроизвести вашу проблему. - person Steffen Ullrich; 05.04.2018