Клиент C с сервером OpenSSL + Java: javax.net.ssl.SSLHandshakeException: нет общих наборов шифров

Я не верю, что сервер Java также принимает клиента Java, если только клиент Java не делает то же самое .setEnabledCipherSuites (all-supported) -- если это так, он использует анонимный (не прошедший проверку подлинности) набор шифров, который не защищен от активной атаки, и хотя многие люди все еще застряли в модели пассивных угроз примерно 1980 года, сегодня активные атаки являются обычным явлением. Вот почему список шифров JSSE по умолчанию исключает анонимные шифры, если только вы не переопределите его. И почему список шифров OpenSSL по умолчанию также исключает их, что вы не переопределили.

(добавить) Чтобы объяснить проще, анонимные наборы шифров ЗАШИФРОВАНЫ (за некоторыми исключениями, которые здесь неуместны, поскольку они никогда не являются предпочтительными), но НЕ аутентифицированы. Слово «неаутентифицированный» означает «неаутентифицированный»; это не означает «не зашифровано». Слово «незашифрованный» используется для обозначения «не зашифрованного». «Не зашифровано» означает, что что-то, что просто просматривает канал, например Wireshark, может видеть открытый текст. «Неаутентифицированный» означает, что злоумышленник, который перехватывает (возможно, перенаправляет) ваш трафик, может заставить вас установить «безопасный» сеанс с злоумышленником посередине, и они могут расшифровать ваши данные, скопировать и/или изменить их по своему усмотрению, повторно -зашифруйте его и отправьте дальше, и вы будете думать, что это правильно и конфиденциально, когда это не так. Погуглите или поищите здесь (думаю, в основном это security.SE и суперпользователь) такие вещи, как «атака человека посередине», «обман ARP», «обман MAC», «отравление DNS», «атака BGP» и т. д.

Непосредственная проблема заключается в том, что вы не используете хранилище ключей. Вы создаете SSLContext с ключом и менеджерами доверия из него, но затем вы создаете сокет из SSLServerSocketFactory.getDefault(), который не использует контекст. Вместо этого используйте sc.getServerSocketFactory().

(добавьте) почему? Каждый SSLSocket (и SSLServerSocket) связан с SSLContext, который, среди прочего, управляет закрытым ключом (-ами) и используемыми сертификатами или цепочками, а также доверенными сертификатами. (Соединения SSL/TLS обычно аутентифицируют только сервер, поэтому на практике серверу нужен только ключ и цепочка, а клиенту нужен только корневой сертификат, но Java использует один и тот же формат файла хранилища ключей для обоих, и его легко просто закодировать оба.) Поскольку ваш код установил конкретный SSLContext sc для содержания подходящего ключа и сертификата, sc.getServerSocketFactory() создает фабрику, которая создает SSLServerSocket, которая, в свою очередь, создает SSLSocket (для каждого соединения, если их более одного), который использует этот ключ-и -(пока это позволяет поддерживаемый клиентом список шифров, и здесь это разрешено).

(добавить) SSLServerSocketFactory.getDefault() создает фабрику и, следовательно, сокеты, используя контекст SSL по умолчанию, который по умолчанию содержит БЕЗ цепочки ключей, хотя вы можете изменить это с помощью системных свойств, как описано в документации, искусно скрытой по адресу http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html . В результате он не может согласовать аутентифицированный набор шифров. Поскольку и Java, и OpenSSL по умолчанию отключают наборы шифров без проверки подлинности, вот почему вы не получаете «общих наборов шифров», если только вы .setEnabled не включаете наборы шифров без проверки подлинности и небезопасные наборы шифров в Java и по-прежнему получаете их для клиента OpenSSL, поскольку вы ничего не сделали. чтобы включить там неаутентифицированные и небезопасные наборы шифров.

(добавить) Если вы внимательно посмотрите на свою трассировку Wireshark, вы увидите в ServerHello, что выбранный набор шифров использует обмен ключами DH_anon или ECDH_anon -- "anon" является аббревиатурой от "anonymous", что означает " не аутентифицирован», как объяснялось выше, и нет сообщения Certificate от сервера, и (менее очевидно, если вы не знаете об этом) данные ServerKeyExchange не подписаны.
Также я предполагаю, что ваш Java-клиент будет проверять sslsocket.getSession().getCipherSuite() и/или sslsocket.getSession().getPeerCertificates() после выполнения рукопожатия, что, поскольку вы не сделаете это явно, будет на первом вводе-выводе на уровне сокета, который будет outputstreamwriter.flush(), вы увидите анонимный набор шифров и отсутствие сертификата партнера (он выдает PeerNotAuthenticated).

Другие пункты:

(1) Как правило, всякий раз, когда вы получаете SSL_ERROR из SSL_get_error() или какую-либо ошибку возвращают процедуры более низкого уровня, такие как EVP_* и BIO_*, вы должны использовать процедуры ERR_* для получения сведений об ошибке и регистрации/отображения их; см. https://www.openssl.org/docs/faq.html#PROG6 и https://www.openssl.org/docs/manmaster/crypto/ERR_print_errors.html и друзья. Тем более, что вы уже загрузили строки ошибок, тем самым избегая https://www.openssl.org/docs/faq.html#PROG7 . Однако в этом случае вы уже достаточно знаете со стороны сервера, поэтому детали со стороны клиента не нужны.

(2) Вам не нужны _add_all_ciphers и _add_all_digests, они включены в _add_all_algorithms.

(3) OP_NO_SSLv2 и 3 не влияют на TLSv1_2_method, а OP_SERVER_CIPHER_PREFERENCE не влияют на клиента. (Они не причиняют вреда, они просто бесполезны и, возможно, сбивают с толку.)

(4) После согласования шифра клиенту OpenSSL потребуется корневой сертификат для сервера; поскольку вы собираетесь использовать самозаверяющий сертификат (после того, как вы исправите сервер для использования хранилища ключей вообще), этот сертификат является его собственным корнем. В 1.0.2 (не ранее) вы также могли использовать якорь доверия без полномочий root, но не по умолчанию, и у вас его все равно нет. Я предполагаю, что certbio был предназначен для этого, но вы никогда не открываете его в реальном файле и не делаете с ним что-либо еще, и в любом случае библиотека SSL не может использовать BIO для своего хранилища доверия. У вас есть три варианта:

• поместите сертификат(ы) в файл или каталог, используя специальные хеш-имена, и передайте имя(я) файла и/или каталога в SSL_CTX_load_verify_locations. Если вам нужен только один корень (ваш собственный), проще использовать опцию CAfile.

• поместите или добавьте сертификаты в файл по умолчанию или хешированный каталог, определенный вашей компиляцией библиотеки OpenSSL, и вызовите SSL_CTX_set_default_verify_paths; обычно это что-то вроде /etc/pki или /var/ssl. Если вы хотите использовать один и тот же сертификат (сертификаты) для нескольких программ или для командной строки openssl, это общее расположение обычно проще.

• используйте BIO и/или другие средства для (открытия и) чтения сертификатов в память, создайте собственный X509_STORE, содержащий их, и поместите его в свой SSL_CTX. Это более сложно, поэтому я не буду распространяться об этом, если вы этого не хотите.

(5) Ваш dest_url является (по крайней мере, в этом случае?) адресной строкой, а не URL-адресом; это разные, хотя и связанные вещи, и думать, что они одинаковы, вызовет у вас гораздо больше проблем. Для большинства программ лучше обрабатывать строку name хоста с помощью классического gethostbyname и вернуться к inet_addr или, что лучше, к «новому» (с 1990-х годов) getaddrinfo, который может обрабатывать как строки имени, так и строки адреса, а также IPv4. и v6 (также новый с 1990-х годов, но, наконец, набирающий обороты). По крайней мере, вы должны проверить, что inet_addr возвращает INADDR_NONE, указывающее, что это не удалось.

SSLContext sc = SSLContext.getInstance("TLSv1.2");

Раньше Java делала две вещи с кодом, подобным этому:

• включить SSLv3
• отключить TLS 1.1 и 1.2

... Даже если вы вызвали TLS. По сути, все, что вы могли получить, — это SSLContext с SSLv3 и TLS 1.0 (если только вы не хотели выполнять дополнительную работу). Возможно, это уже не так, но это объясняет ошибку, которую вы видите (особенно если вы используете Java 7 или 8).

Вам нужно проделать больше работы в Java, чтобы получить «TLS 1.0 или выше» и «только TLS 1.2». Для этого см. Какие наборы шифров включить для сокета SSL?. Он показывает вам, как включать/отключать как протоколы, так и наборы шифров.

SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION | SSL_OP_CIPHER_SERVER_PREFERENCE);

Вы также должны установить список наборов шифров, поскольку OpenSSL по умолчанию включает сломанные/слабые/раненые шифры. Что-то типа:

const char PREFERRED_CIPHERS[] = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
long res = SSL_CTX_set_cipher_list(ssl_ctx, PREFERRED_CIPHERS);
ASSERT(res == 1);

Я думаю, что ваш последний шаг — убедиться, что самозаверяющий сертификат является доверенным.

Для Java-клиента см. Как правильно импортировать самозаверяющий сертификат в хранилище ключей Java, которое по умолчанию доступно для всех приложений Java? . Для клиента OpenSSL просто загрузите его, используя SSL_CTX_load_verify_locations, см. SSL_CTX_load_verify_locations Сбой с SSL_ERROR_NONE.

Обратите внимание: OpenSSL до версии 1.1.0 не выполнял проверку имени хоста. Вам придется сделать это самостоятельно. Если вам нужно выполнить проверку имени хоста, поднимите код из cURL's url.c. Кажется, я припоминаю, что смотрел на код Дэниела, и он очень солидный. Вы также можете получить код из проекта Google CT. . Я никогда не проверял его, поэтому я не знаю, каково это.

Есть еще две проверки, которые вы должны сделать; они обсуждаются в разделе SSL/TLS Client на вики OpenSSL.