vitus_wagner (
vitus_wagner) wrote2010-10-06 02:18 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Entry tags:
Не понимаю
Почему такая простая концепция, как X.509 PKI никак не укладывается в голове большинства людей.
Даже профессиональных программистов.
Казалось бы чего проще - есть понятие электронной подписи:
Есть пара взаимосвязанных последовательностей байт - секретный ключ и открытый. Открытый по секретному сгенерировать легко, наоборот - практически невозможно.
Есть некий черный ящик, в который человек может запустить сообщение и секретный ключ и получить на выходе некоторую последовательность байт, которую без наличия данного секретного ключа никак из сообщения не получить.
И есть второй черный ящик, куда пихается сообщение, подпись, и открытый ключ, и на выходе получается вывод - выработана подпись тем секретным ключом, открытую половинку которого мы пихнули в ящик, или не тем.
Очевидно, что то, что подпись выработана на данном ключе, ничего не говорит нам о том, какой именно человек или какой именно компьютер ее выработал. Соответсвенено появляется понятие доверия ключу. Поскольку собрать открытые ключи всех, чью подпись потребуется проверить заранее и надежным способом - нереально, появлется PKI, public key infrasturcture - способ получить открытый ключ кого надо (или открытый ключ, которым подписано данное сообщение) и убедиться что это именно ключ данного конкретного персонажда. Обычно для этого комбинация из ключа и данных о ее владельце подписывается кем-то, чьему ключу мы уже доверяем (например потому, что ему доверяет поставщик нашей операционной системы и включил его сертификат в дистрибутив). Такой электронный документ называется сертификатом.
Очевидно, что самоподписанный сертификат не удостоверяет ничего, кроме того, что с момента как владелец ключа его подписал, никто его не редактировал. То что владелец ключа - именно тот, чье имя написано в сертификате - ничего не значит. Вот возьму и сделаю себе самоподписанный сертификат на имя Рене де Карт. От этого я изобретателем прямоугольных координат не стану.
Очевидно, что когда мы хотим установить защищенное соединение по TLS, мы должны убедиться что мы устанавливаем соединение именно с тем, с кем хотели. Потому что в противном случае сколь угодно сильное шифрование бесполезно. "Человек посередине" легко перехватит наш пароль, потому что именно ему-то мы его и пошлем, из-за того, что не проверили что он не является нашим сервером.
И ведь создать внутрикорпоративный удостоверяющий центр чтобы выдать пять сертификатов на свои сервера, и выложить сертификат этого УЦ, чтобы пользователи его себе установили не просто, а очень просто.
Такое впечатление, что 90% тех, кто пользуется TLS и электронной почты защита не нужна. И даже security theater не нужен. Потому что свежий firefox такой театр с security exceptions устраивает, что можно было бы задуматься. Нет, продолжают выполнять чисто ритуальные действия по включению tls с самоподписанными сертификатами (или еще смешнее - создают честный УЦ, а его сертификат не распространяют).
Даже профессиональных программистов.
Казалось бы чего проще - есть понятие электронной подписи:
Есть пара взаимосвязанных последовательностей байт - секретный ключ и открытый. Открытый по секретному сгенерировать легко, наоборот - практически невозможно.
Есть некий черный ящик, в который человек может запустить сообщение и секретный ключ и получить на выходе некоторую последовательность байт, которую без наличия данного секретного ключа никак из сообщения не получить.
И есть второй черный ящик, куда пихается сообщение, подпись, и открытый ключ, и на выходе получается вывод - выработана подпись тем секретным ключом, открытую половинку которого мы пихнули в ящик, или не тем.
Очевидно, что то, что подпись выработана на данном ключе, ничего не говорит нам о том, какой именно человек или какой именно компьютер ее выработал. Соответсвенено появляется понятие доверия ключу. Поскольку собрать открытые ключи всех, чью подпись потребуется проверить заранее и надежным способом - нереально, появлется PKI, public key infrasturcture - способ получить открытый ключ кого надо (или открытый ключ, которым подписано данное сообщение) и убедиться что это именно ключ данного конкретного персонажда. Обычно для этого комбинация из ключа и данных о ее владельце подписывается кем-то, чьему ключу мы уже доверяем (например потому, что ему доверяет поставщик нашей операционной системы и включил его сертификат в дистрибутив). Такой электронный документ называется сертификатом.
Очевидно, что самоподписанный сертификат не удостоверяет ничего, кроме того, что с момента как владелец ключа его подписал, никто его не редактировал. То что владелец ключа - именно тот, чье имя написано в сертификате - ничего не значит. Вот возьму и сделаю себе самоподписанный сертификат на имя Рене де Карт. От этого я изобретателем прямоугольных координат не стану.
Очевидно, что когда мы хотим установить защищенное соединение по TLS, мы должны убедиться что мы устанавливаем соединение именно с тем, с кем хотели. Потому что в противном случае сколь угодно сильное шифрование бесполезно. "Человек посередине" легко перехватит наш пароль, потому что именно ему-то мы его и пошлем, из-за того, что не проверили что он не является нашим сервером.
И ведь создать внутрикорпоративный удостоверяющий центр чтобы выдать пять сертификатов на свои сервера, и выложить сертификат этого УЦ, чтобы пользователи его себе установили не просто, а очень просто.
Такое впечатление, что 90% тех, кто пользуется TLS и электронной почты защита не нужна. И даже security theater не нужен. Потому что свежий firefox такой театр с security exceptions устраивает, что можно было бы задуматься. Нет, продолжают выполнять чисто ритуальные действия по включению tls с самоподписанными сертификатами (или еще смешнее - создают честный УЦ, а его сертификат не распространяют).
no subject
Но вот почему-то браузеры и почтовые клиенты поддерживают почти исключительно X.509 PKI. Поэтому приходится играть по ее правилам. А там должна быть иерархия.
Впрочем многие почтовые клиенты (pine, mutt, evolution) поддерживают для доступа к imap-серверам ssh-вую pki.
Посредством пайпинга imap-протокола в ssh, запускающий на другом конце imapd.
no subject
Согласен. Видимо я несколько узко трактовал понятик инфраструктуры.
Иерархичность X.509 PKI как я понимаю не является неотемлемой частью стандарта X.509, а являестя повсеместно распространённым частным случаем. В часности "cross-certificates" как я понимаю это сертификат одного CA подписанный ключом другого CA. На основе этого могла бы быть реализована "Web of trust" (http://www.ietf.org/rfc/rfc2510.txt)
Вообще я хотел сказать первым комментарием следующее - "Чем архитектурно (оговорка чтобы исключить кривости в частных реализациях пользовательского интерфейса), безопасность в случае подтверждения нового неизвестного ключа в SSH отличается от безопасности добавления исключения для нового самоподписанного сертификата в TSL?"
PS. Вообще пост провокационный. И я поддался.
no subject
no subject
2. Принятие решения о включении сертификат сервера ssh в known_hosts и принятие решения о корректности сайта электронной коммерции - существенно разный уровень риска.
В первом случае ты рискуешь только своим паролем.
Во-втором - непосредственно деньгами.
Аутентификация сайта по степени риска ближе к аутентификации пользователя ssh-сервера, чем к аутентификации самого сервера. ssh-сервер - это площадка для действий. Сайт (веб-приложение) - это партнер по действиям.
no subject
Это смотря что стоит на том сервере. Если я хожу через ssh администрировать сайт электронной коммерции - ...
У меня на девелоперских серверах самоподписанные сертификаты с отдельно лежащим ключом, который через get certificate браузеры нормально запоминают.
no subject