SSL/TLS без сертификатов
Я работаю над любимым проектом, который (в конце концов, когда это будет сделано) обеспечит безопасную передачу файлов (это еще не все, но остальное не имеет особого значения). Я хотел бы использовать библиотеку OpenSSL, так как она кажется наиболее полной бесплатной библиотекой криптографии (и мне нужна поддержка базового симметричного шифрования и хеширования в дополнение к SSL/TLS).
Я ищу реализовать схему безопасности, аналогичную SSH. Обычно пользователь подключается к моему компьютеру по протоколу TLSv1 (SSLv3.1). Я хотел бы, чтобы соединение было успешным независимо от безопасности. Затем я хочу иметь возможность проверять открытый ключ (не полный сертификат), который использовал пользователь. Этот ключ сравнивается с известными открытыми ключами, и, если он совпадает, то пользователю будет разрешен доступ к определенному набору команд. Если он не совпадает, у пользователя будет возможность использовать соединение, чтобы подать заявку на добавление его / ее открытого ключа в мою коллекцию, но в противном случае он не сможет получить доступ к моим службам.
У меня нет особой необходимости в сертификатах здесь. Для меня было бы намного проще, если бы я мог просто пропустить все детали сертификата и работать только с необработанными ключами шифрования. Это связано с тем, что эта модель следует модели веб-доверия, а не иерархической модели, используемой большинством соединений SSL / TLS, поэтому мне не нужны какие-либо ЦС или подписанные сертификаты.
К сожалению, документация большинства OpenSSL, ну, в общем, отсутствует. Все соответствующие статьи, которые я нахожу, кажутся занятыми настройкой "стандартного" соединения SSL / TLS, где сертификат сервера проверяется вплоть до набора корневых сертификатов. Это может быть полезно, но мне трудно понять, как настроить и запустить эти нетрадиционные соединения SSL.
Может кто-нибудь предложить какие-нибудь статьи или документацию, которые могут помочь мне понять, как это сделать?
(Использование OpenSSL не стоит на пороге, и я мог бы переключиться на другую библиотеку, если она предоставит лучший способ сделать это, а также хеширование [SHA-512] и симметричное шифрование [AES]. Я нацеливаюсь на нацеливание Linux, но было бы неплохо, если бы конечный продукт был переносим на Windows, чтобы мои друзья тоже могли его использовать.)
2 ответа
Чтобы расширить ответ Евгения (я бы поставил это как комментарий, но это немного длинно)...
Сделав такого рода вещи с проектом FOAF+SSL (позже переименованным в WebID), использование сертификатов X.509 облегчает реализацию, просто потому, что большинство стеков SSL/TLS разработаны с учетом их требований (и их API отражают это).
В прошлый раз, когда я проверял FOAF+SSL, традиционные проверки PKI все еще были на месте, чтобы клиент мог проверить сертификат сервера. Другой вариант, похожий на SSH, - принять открытый ключ / сертификат при первом обращении к нему и предупредить пользователя при его изменении. Так или иначе, так или иначе работает SSH (в частности, я полагаю, что мало кто на самом деле проверяет отпечаток ключа вне полосы при первом его просмотре).
Рассматривая только использование клиентского сертификата (хотя часть этого может относиться к сертификатам сервера аналогичным образом):
- Кажется, что большинство серверных библиотек способны обрабатывать сертификаты X.509, но позволяют изменить способ их проверки (например,
X509TrustManagerна Яве). - Хотя вы не сможете доверять чему-либо, что говорит клиентский сертификат, пока вы не подтвердите это, в противном случае может помочь встраивание некоторой дополнительной информации (например, "Имя субъекта" или "Альтернативное имя субъекта", чтобы увидеть, на что претендует пользователь). (а) пользователи упорядочивают свои сертификаты и (б) дают подсказку проверяющему, чтобы он знал, что искать. Открытым открытым ключом может быть сложно управлять.
- Ряд существующих клиентских инструментов (особенно браузеров) используют сертификаты 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 эмитента для всех этих сертификатов, даже если на практике они не подписаны одним и тем же закрытым ключом (опять же, поскольку вы проигнорируете подпись).
Используйте самозаверяющие сертификаты - это то же самое, что и "необработанные" ключи, но им легче управлять (см. Этот вопрос относительно того, как принять или не принять самоподписанный сертификат в openssl).