Не понимаю
Oct. 6th, 2010 02:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПочему такая простая концепция, как 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 с самоподписанными сертификатами (или еще смешнее - создают честный УЦ, а его сертификат не распространяют).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-10-06 10:59 am (UTC)no subject
Date: 2010-10-06 01:00 pm (UTC)no subject
Date: 2010-10-06 01:02 pm (UTC)Хотя да, если есть возможность перехватить то обычно можно и проспуфить. Но мало ли, вдруг кто-то постфактум дампы трафика смотрит, или при массовом перехвате нет ресурсов на проксирование всех сразу..
no subject
Date: 2010-10-06 02:25 pm (UTC)Не, я могу представить себе место, где разница между пассивным перехватом и MiTM принципиальна. Когда надо обеспечить, чтобы прослушку гарантированно не заметили. Но в этой ситуации у атакуемого информация обычно настолько важна, что отсутствие аутентификации для него недопустимо.
no subject
Date: 2010-10-06 04:13 pm (UTC)Но при этом защита от перехвата проще чем от MitM - для последней надо разворачивать инфраструктуру, не забыв ещё о CRL. Возможно, по соотношению риски/расходы от неё и отказываются.
no subject
Date: 2010-10-06 04:27 pm (UTC)no subject
Date: 2010-10-06 04:09 pm (UTC)А самый простой реальный пример - популярный Radmin (хотя там и не TLS). В некоторых VNC тоже шифрование бывает, а сертификатов - нет.
no subject
Date: 2010-10-06 04:22 pm (UTC)И что в природе встречается шифрование без аутентификации - для меня тоже не секрет. Я хочу увидеть ситуацию, где оно действительно практически полезно, и модель угроз для этой ситуации (чтобы видеть, что тот, кто это делал, таки да, понимал, что делал, а не вкручивал шифрование для галочки, как чаще бывает).
no subject
Date: 2010-10-07 07:46 am (UTC)no subject
Date: 2010-10-07 07:49 am (UTC)no subject
Date: 2010-10-07 08:00 am (UTC)Просто целью защиты вовсе не обязательно должно быть устранение угроз - часто вполне достаточным является снижение реально наблюдающихся угроз до приемлемого уровня - ну примерно как замки на дверях, которые профессионалы открывают легко и быстро - от но 99% желающих они помогают.
В принципе - с тем же успехом можно спрашивать зачем вообще пароли на незащищенном соединии - их же перехватить можно.
no subject
Date: 2010-10-07 08:01 am (UTC)no subject
Date: 2010-10-07 08:09 am (UTC)no subject
Date: 2010-10-07 09:56 am (UTC)