Создание эфемерного сокета SSL / TLS с использованием свежей пары ключей

Question

Каждый учебник, который я нашел, объясняет, как создать соединение SSL / TLS с SSLSocket s, используя файл хранилища ключей и хранилище доверенных сертификатов для хранения сертификата SSL после его создания вручную с помощью утилиты keytool.

Мне бы хотелось узнать, как сделать то же самое, но с открытым ключом / сертификатом, сгенерированным на лету (эфемерно).

Так просто создать пару ключей RSA / EC в Java, так почему же мы не можем просто использовать ее для SSLSocket? На мой взгляд, у этого есть два больших преимущества: он обеспечивает прямую секретность, и в то же время мне не приходится иметь дело с паролями, утилитами, программами для чтения файлов и конвертерами хранилища ключей для Android.

Answer 1

Как технически правильная, но довольно бесполезная альтернатива:

TLS фактически определяет «анонимные» методы обмена ключами DH_anon и ECDH_anon (и шифровальные комплекты, использующие их), которые выполняют согласование прямого секретного ключа с использованием эфемерных пар ключей и не требуют аутентификации, поэтому не требуют любой сертификат или хранилище ключей на сервере или (потенциально) хранилище доверенных сертификатов на клиенте.

Будучи не прошедшими проверку подлинности, они легко уязвимы для активных атак, и поэтому люди (и власти), которые действительно хотят безопасности, считают их неприемлемыми для использования. Java (JSSE) действительно реализует их, но не включает их по умолчанию; Ваш код должен вызвать .setEnabledCiphers с соответствующим измененным или заданным списком. Большинство других реализаций SSL / TLS либо отключают их аналогичным образом, либо вообще не реализуют.

Но технически это правильный способ создания TLS без долгосрочных ключей и сертификатов и, следовательно, без ручных усилий по их администрированию.

Кроме того, я верю , поэтому создание (SSLContext и) SSLSocketFactory с (KeyManager для) хранилища ключей, не связанного с действительным privateKeyEntry, не выдает ошибку, потому что в принципе он может создавать сокеты (или механизмы), используемые для анонимных соединений. Вместо этого, поскольку на практике анонимный обмен ключами никогда не используется, эти фабрики приводят к сбоям всех последующих соединений, как это бывает у многих неопытных программистов с проблемами диагностики. (Напротив, попытка создать валидатор для пустого хранилища доверенных сертификатов выдает определенное исключение, что-то вроде «набор привязок доверия не должен быть пустым».)

Answer 2

На мой взгляд, у этого есть два больших преимущества: он обеспечивает прямую секретность

Прямая секретность обычно касается соглашения о ключах, такого как ECDHE или DHE (хотя последнее в настоящее время широко осуждается из-за перебоев в работе).

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

Так просто создать пару ключей RSA / EC в Java, так почему же мы не можем просто использовать ее и для SSLSocket?

Вам также нужен сертификат X509, а не просто ключ. Вы можете сделать это на лету, но вам придется подписать сертификат. Либо сертификат будет самоподписанным, либо вам потребуется центр сертификации, который может подписывать сертификаты очень быстро по требованию. Практически, последний не существует и будет означать очень медленные рукопожатия.

Если сертификат является самоподписанным, браузеры или любой другой пользовательский агент не будут знать, как доверять сертификату, и использование самозаверяющих сертификатов серьезно влияет на использование TLS.