Шифрование и аутентикация web-сервисов
Каждый из нас пользуется довольно большим количеством сервисов, которые так или иначе требуют аутентикации пользователя через web. Порой приходится пользоваться этими сервисами в откровенно "недружественной" сетевой среде - публичный wifi, интернет-кафе и тому подобные случаи, когда наши аутентикационные данные особенно нуждаются в защите.
... Для этого придуман протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security), осуществляющий прозрачное для веб-приложения шифрование всего трафика, который, вроде как, должен обезопасить все подобные сервисы.

Определить, используются ли должные меры безопасности, не всегда легко. В простом случае, если в строке броузера написано "https://", а не "http://", а также в строке статуса броузера присутствует логотип в виде защелкнутого амбарного замка, а броузер не выдавал никаких подозрительных предупреждений, можно сказать с большой вероятностью, что все в порядке (я предполагаю, что идиоты, использовавшие "ослабленную" криптографию к этому времени уже вымерли от бытовых травм). Если его нет, все может быть плохо, но не очень - в достаточной степени, чтобы удовлетворить невзыскательным требованиям: то есть в некоторых сервисах (gmail, yandex со включенным javascript) https используется для передачи идентификатора пользователя и пароля при получении login cookie, то есть некой хранимой на клиентском компьютере информации о том, что пользователь успешно вошел в систему. Таким образом, предполагаемый оппонент может в течении определенного периода времени воспользоваться сервисом под вашими правами, но этот период ограничен. А может быть и совсем плохо (mail.ru, vkontakte, odnoklassniki), когда используется открытая аутентикация, полностью доступная для перехвата. К сожалению, нет решительно никакого простого (без изучения исходного кода html) способа определить, что именно происходит в каждом конкретном случае.

Почему если есть адекватный способ защиты, создатели сервисов все еще подвергают своих пользователей риску? Тому есть несколько причин.

Любой сервис развивается эволюционно и на раннем этапе важна любая экономия. Вина лежит не только на хозяевах сервисов, но и на авторах веб-броузеров. Проблема вот какая: протокол ssl/tls предназначен для выполнения двух функций: подтверждения идентификации сторон (сервера и клиента, но для клиента используется гораздо реже) и шифрования информации в канале связи. Часто ключевой функцией оказывается вторая, а первая превращается в навязанную коммерческую услугу! Дело в том, что подлинность сервера через его сертификат подтверждается третьей стороной - удостоверяющим центром. И да, это коммерческая услуга и она стоит денег; оплата связана с необходимостью подтвердить "реальную" (оффлайновую) аутентичность организации, получающей сертификат, с использованием таких смехотворных по нынешним временам мер, как официальное письмо на бланке организации и т д. А ведь зачастую эта аутентичность никого не интересует.. Мне не важно, является ли сервер odnoklassniki.ru собственностью ЗАО "Одноклассники". Меня интересует возможность, когда я захожу на сервер в первый раз, сохранить его сертификат и использовать в дальнейшем. И именно эту возможность веб-броузер не предоставляет! Если я владелец сервера, у меня есть три варианта - 1) купить за деньги коммерческий сертификат 2) использовать сертификат, который каждый раз будет выдавать пользователю утомительное окно с предупреждением, от которого он, как правило, не в состоянии избавиться и 3) отказаться от использования SSL вообще. Стоит ли удивляться, что многие идут по третьему пути.

Остальные причины менее значимы - можно назвать то, что виртуальный сервер с поддержкой ssl требует выделенного ip-адреса, нагрузка на вычислительные ресурсы возрастает, ssl не кэшируется, у некоторых пользователей поддержка ssl отсутствует вообще (большой сюрприз для меня, но по данным одного заметного на российском рынке онлайнового сервиса, который попросил на него не ссылаться, около пяти процентов). Кроме того, некоторые броузеры приобетают неприятную болтливость - они считают своим долгом каждый раз информировать о том, что теперь информация шифруется, а теперь не шифруется, а теперь шифруются некоторые элементы и уверены ли вы, что это то, что вы хотите видеть..

С удостоверяющими центрами тоже не так все просто. Их количество растет, и, несмотря на то, что ни одни популярный дистрибутив операционной системы не идет с корневыми сертификатами бесплатных удостоверяющих центров (наличие корневого сертификата необходимо, чтобы подписанные данным удостоверяющим центром сертификаты принимались без предупреждений), использование платного также не спасает от всех проблем. Особенно страдают мобильные устройства, которые часто имеют устаревшие списки корневых сертификатов, в которых отсутствуют вполне респектабельные и общепринятые удостоверяющие центры.

Есть еще новомодное средство взимания платы за воздух - Extended Validation. Оно означает, что сертификат выдан с "усиленными" мерами безопасности. То есть, взяли побольше денег и запросили (я не шучу) фотографии офисного здания и стойки рецепшна.

Вообще говоря, SSL - штука чудовищно неудобная и совершенно не вписывающаяся в нормальную корпоративную инфраструктуру безопасности, так как предназначена для создания закрытого канала между двумя точками, который невозможно контролировать. Все, что можно придумать для его использования в корпоративной среде - набор невероятно уродливых костылей. Но пока ему нет вменяемой альтернативы, нет и не может быть извинения тем, кто подвергает пользователей риску, передавая аутентикационные данные в открытом виде.


Небольшой совет: если к gmail.com обращаться по url https://mail.google.com , то будет шифроваться не только аутентикационная информация, но и вся сессия. А icq просто пользоваться не надо, вообще.

источник-arkanoid@lj

читать полный текст со всеми комментариями