SSL / TLS без сертификатов

Question

Я работаю над любимым проектом, который (в конце концов, когда это будет сделано) обеспечит безопасную передачу файлов (это больше, чем просто, но остальное не имеет особого значения).Я хотел бы использовать библиотеку OpenSSL, так как она кажется наиболее полной бесплатной библиотекой криптографии (и мне нужна поддержка базового симметричного шифрования и хеширования в дополнение к SSL / TLS).

I'mищу реализацию схемы безопасности , аналогичной SSH.Обычно пользователь подключается к моему компьютеру по протоколу TLSv1 (SSLv3.1).Я бы хотел, чтобы соединение было успешным независимо от безопасности.Затем я хочу иметь возможность проверять открытый ключ (не полный сертификат), который использовал пользователь.Этот ключ сравнивается с известными открытыми ключами, и если он совпадает, то пользователю будет разрешен доступ к определенному набору команд.Если он не совпадает, у пользователя будет возможность использовать соединение, чтобы подать заявку на добавление его / ее открытого ключа в мою коллекцию, но в противном случае он не сможет получить доступ к моим услугам.

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

К сожалению, документация большинстваOpenSSL, ну, в общем, не существует.Все соответствующие статьи, которые я нахожу, кажутся занятыми настройкой «стандартного» соединения SSL / TLS, при котором сертификат сервера проверяется вплоть до набора корневых сертификатов.Это может быть полезно, но мне сложно понять, как настроить и запустить эти нетрадиционные соединения SSL.

Может кто-нибудь предложить какие-либо статьи или документацию, которые могут помочь мне понять, как этого добиться?

(Использование OpenSSL в камне не установлено, и я мог бы переключиться на другую библиотеку, если бы она обеспечивала лучший способ сделать это, а также хэширование [SHA-512] и симметричное шифрование [AES].Я нацеливаюсь на Linux, но было бы неплохо, если бы конечный продукт был переносим на Windows, чтобы мои друзья тоже могли его использовать.)

Answer 1

Чтобы расширить ответ Юджина (я бы назвал это комментарием, но он немного длинный) ...

Сделав такого рода вещи с проектом FOAF + SSL (позже переименованный в WebID), использование сертификатов X.509 облегчает реализацию, просто потому, что большинство стеков SSL / TLS разработаны с их помощью в ум (и их API отражают это).

В прошлый раз, когда я проверял FOAF + SSL, традиционные проверки PKI все еще были на месте, чтобы клиент мог проверить сертификат сервера. Другой вариант, аналогичный SSH, заключается в том, чтобы принять открытый ключ / сертификат при первом обращении к нему и предупредить пользователя при его изменении. Так или иначе, так или иначе работает SSH (в частности, я полагаю, что мало кто на самом деле проверяет отпечаток ключа вне полосы при первом его просмотре).

Учитывая только использование клиентского сертификата (хотя некоторые из них могут относиться к сертификатам сервера аналогичным образом):

• Кажется, что большинство серверных библиотек способны обрабатывать сертификаты X.509, но позволяют изменить способ их проверки (например, X509TrustManager в Java).
• Хотя вы не сможете доверять тому, что говорит клиентский сертификат, пока вы не подтвердите это, в противном случае вы сможете внедрить некоторую дополнительную информацию (например, «Имя субъекта» или «Альтернативное имя субъекта»), чтобы увидеть, кто пользователь утверждает, что он является ) может помочь (а) пользователям организовать свои сертификаты и (б) дать подсказку проверяющему, чтобы он знал, что искать. Открытым открытым ключом может быть трудно управлять.
• Ряд существующих клиентских инструментов (особенно браузеров) используют сертификаты X.509 при выполнении аутентификации клиента SSL / TLS. Чтобы настроить клиент для использования самозаверяющего сертификата X.509 (в отличие от сертификата из PKI), не нужно много делать. (Существует очень мало инструментов, поддерживающих OpenPGP для TLS, я не уверен, что кто-либо сможет использовать его как форму сертификата клиента.)
• Поскольку вы не сможете доверять сертификату без внешних проверок, не имеет значения, является ли он самоподписанным или нет (то есть, являются ли издатель и субъект одинаковыми), по крайней мере, предполагая, что пользователь не будет ' не отправит вам сертификат, с которым он не согласится (поэтому его не нужно будет запечатывать своим собственным ключом). Следствием этого является то, что вы можете создать сервис для выдачи сертификатов довольно легко. Например, генерация ключей в браузере удобна для пользователей, которые не хотят использовать команды openssl или keytool. Здесь - это пример службы, которая будет выдавать сертификат с SAN, которую хочет пользователь (могут быть более свежие версии, если вы проверите с помощью проекта FOAF + SSL / WebID ). Независимо от того, какой личный ключ или имя эмитента использует такая служба, это практически не имеет значения, но поскольку браузеры спроектированы на основе традиционных PKI, это не облегчает использование действительно самозаверяющих сертификатов.

Есть также проблемы, когда дело касается запроса конкретного клиентского сертификата. Спецификация TLS 1.1 явно допускает пустое значение certification authorities (см. RFC 4346 ), тогда как в TLS 1.0 ничего не говорилось об этом. На практике, даже с TLS 1.0, большинство клиентских инструментов, похоже, довольны пустым списком (они просто предложат больший выбор). Если вы хотите, чтобы ваши сертификаты для вашей системы были легко идентифицируемыми, вы можете использовать один и тот же DN издателя для всех этих сертификатов, даже если на практике они не подписаны одним и тем же закрытым ключом (опять же, поскольку вы проигнорируете подпись).

Answer 2

Использовать самозаверяющие сертификаты - это то же самое, что и «необработанные» ключи, но им легче управлять (см. этот вопрос о том, как принять или не принять самоподписанный сертификат в openssl).