Проблема неполноты SSL на сайте www.pgpru.com и petname для Firefox – [решено]
Большинство серьёзных проектов используют SSL-хостинг, а для сохранения доступа к аккаунту через сеть tor он просто необходим, иначе его просто угонят с исходящего узла.
Впрочем и без сети tor пароль в открытом виде проходит через кучу узлов, а значит через кого попало.
К счастью, pgpru.com перешёл на такой защищённый хостинг, хотя это затратно и тяжело для небольшого некоммерческого проекта.
Но по понятным причинам (например для компенсации тех же затрат на хостинг) на сайте крутятся баннеры, Но эти же баннеры не дают покоя в том смысле, что даже если их полностью
заблокировать, браузер будет получать смешанный контент, как защищённый так и нет (http + https).
При этом он не будет его подробно различать по степени защищённости, а просто посчитает не всю страницу защищённый, выведет битый значёк SSL и предупреждение "Broken https".
Злоумышленник, находящийся посредине, может произвольно менять соотношение между защищённым и незащищённым контентом, оставаясь незамеченным (если не разбирать полученный браузером исходный код страницы), например модифицировав отдаваемую страницу так что поле ввода пароля пойдёт через простой http, а декоративные элементы страницы отдавать через https.
Пользователь конечно может заблокировать http://www.pgpru.com и разрешить только https://www.pgpru.com, чтобы избавиться от возможной подмены, но это неполноценное решение, так как всё равно получим битую страницу и видимость защиты.
Кстати существует простой плагин к Firefox – petname. Вот какую задачу он решает.
Пусть мы не доверяем центрам сертификации, пусть корневой сертификат будет похищен, пусть даже центр сертификации сдаст свои ключи полиции, чтобы она могла организовать подставной сайт, чтобы отслеживать соединения пользователя (полиция – это самый опасный злоумышленник :-) ). Но если не похищен сертификат самого сайта, то браузер будет показывать правильное соединение для другого (подставного) сайта, заверенное корневым сертификатом, хотя отпечаток сертификата сайта и будет отображаться другой.
Другая проблема – если пользоваться самоподписанными сертификатами, а также что один корневой сертификат может быть использован для подписи сертификата другого сайта, если раздатчик сертификатов это позволяет по неосторожности или по умыслу.
Заметить это трудно, Не сверять же каждый раз отпечатки по бумажке. Для в этого в плагине petname проблема решена самым простым и изящным способом: каждому посещённому SSL-сайту при первом заходе прелагается сопоставить его хэш-отпечаток с некоторым кратким названием-кличкой. Если при последующем заходе [кличка]-[url]-[отпечаток сертификата] совпадут -получим
зелёный значок, иначе предупреждение о смене сертификата, но и подмену url можно заметить по не той "кличке" рядом с адресной строкой.
Клички сайтов и хэши сертификатов (сверяется и md5 и sha) хранятся в закладках, так что ими легко обмениваться.
А вот с https://www.pgpru.com это не работает из-за тех же баннеров. Получаем статус untrusted.
Решение может быть в том, чтобы пропускать все баннеры через https://, такое можно теоретически сделать на отдельном сервере, но решать такую задачу на виртуальном хостинге это конечно изврат. С другой стороны, SSL тоже должен быть полноценным, а не для показухи.
Какие мнения?
комментариев: 271 документов: 13 редакций: 4
Я глянул в исходник: программный код, который хэширует SSL-сертификат, был удалён в версии 1.1. Ну, я ещё увидел, что в Firefox3 интерфейс закладок не позволяет сохранять описания закладок, так что не уверен, можно ли вообще поправить положение.
комментариев: 11558 документов: 1036 редакций: 4118
Имеете в виду, API не имеет таких функций? Ибо поле Description там есть.
комментариев: 271 документов: 13 редакций: 4
Совершенно верно.
комментариев: 271 документов: 13 редакций: 4
Я думаю, что keyword — это "Скорочення", то есть слово, позволяющее использовать данную закладку для поиска. Впрочем, можно и туда срать. :)
комментариев: 155 документов: 20 редакций: 5
Кукки вообще не украдешь, так как они передаются на домен www.pgpru.com который зашифрован.
Причем, этой уязвимостью можно воспользоваться лишь с помощью mitm, так как в противном случае она не имеет смысла, если вы доверяете сайту.
Причем mitm возможен лишь в случае некорректного кода на сайте.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Смешанный контент – всё равно что его отсутствие. По хорошему, браузер сначала должен вообще на такие страницы не пускать и только если юзер ответит "да, я сам себе злобный буратино", открывать их с битым значком.
комментариев: 155 документов: 20 редакций: 5
комментариев: 9796 документов: 488 редакций: 5664
Вот, начинаем верить в доменные имена и IP-адреса вместо криптостойких протоколов с сертификатами.
Вместо баннеров можно произвести MITM, который добавит к странице нечто, якобы исходящее из этого же домена.
При смешанном контенте можно подсунуть браузеру код, который получит доступ к тому, что передается в якобы защищенной части.
комментариев: 155 документов: 20 редакций: 5
Хотелось бы подробнее. JavaScript движок браузера не делает различия между https и http, подобно тому как он делает различия между разными доменами?
Или баннер может воспользоваться уязвимостью браузера в iframe?
комментариев: 9796 документов: 488 редакций: 5664
Collin Jackson, Adam Barth
Stanford University
комментариев: 9796 документов: 488 редакций: 5664
...всё равно что отстуствие HTTPS конечно же.
комментариев: 155 документов: 20 редакций: 5
Ага! Теперь ясно! Очередная дырка в браузере. Или эту уже пофиксили? Если конечно Коллин Джексон проверял это на практике.
комментариев: 9796 документов: 488 редакций: 5664
Не очередная дырка, а концептуально повторяющаяся плачевная ситуация, которая будет проявляться в разных дырках. Фиксить это практически бесполезно. Там авторы предлагают кое-что, но можно сделать вывод, что разделение смешанного контента в браузерах хоть по доменам, хоть по протоколам, хоть по чему-угодно всегда было и будет реализовано небезопасно.