Проблема неполноты 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[link1].Вот какую задачу он решает.
Пусть мы не доверяем центрам сертификации, пусть корневой сертификат будет похищен, пусть даже центр сертификации сдаст свои ключи полиции, чтобы она могла организовать подставной сайт, чтобы отслеживать соединения пользователя (полиция – это самый опасный злоумышленник :-) ). Но если не похищен сертификат самого сайта, то браузер будет показывать правильное соединение для другого (подставного) сайта, заверенное корневым сертификатом, хотя отпечаток сертификата сайта и будет отображаться другой.
Другая проблема – если пользоваться самоподписанными сертификатами, а также что один корневой сертификат может быть использован для подписи сертификата другого сайта, если раздатчик сертификатов это позволяет по неосторожности или по умыслу.
Заметить это трудно, Не сверять же каждый раз отпечатки по бумажке. Для в этого в плагине petname проблема решена самым простым и изящным способом: каждому посещённому SSL-сайту при первом заходе прелагается сопоставить его хэш-отпечаток с некоторым кратким названием-кличкой. Если при последующем заходе [кличка]-[url]-[отпечаток сертификата] совпадут -получим
зелёный значок, иначе предупреждение о смене сертификата, но и подмену url можно заметить по не той "кличке" рядом с адресной строкой.
Клички сайтов и хэши сертификатов (сверяется и md5 и sha) хранятся в закладках, так что ими легко обмениваться.
А вот с https://www.pgpru.com это не работает из-за тех же баннеров. Получаем статус untrusted.
Решение может быть в том, чтобы пропускать все баннеры через https://, такое можно теоретически сделать на отдельном сервере, но решать такую задачу на виртуальном хостинге это конечно изврат. С другой стороны, SSL тоже должен быть полноценным, а не для показухи.
Какие мнения?
Ссылки
[link1] http://petname.mozdev.org/installation.html
[link2] https://addons.mozilla.org/en-US/firefox/addon/10
[link3] https://addons.mozilla.org/en-US/firefox/reviews/display/957
[link4] https://developer.mozilla.org/en/nsINavBookmarksService
[link5] https://developer.mozilla.org/en/nsINavBookmarksService#setKeywordForBookmark()
[link6] http://w2spconf.com/2008/papers/s2p1.pdf
[link7] http://www.mozdev.org/pipermail/petname/2009-February/000019.html
[link8] http://crypto.stanford.edu/websec/origins/
[link9] http://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
[link10] http://blog.sjinks.org.ua/wordpress/tips-and-tricks/486-simultaneous-login-for-http-and-https/
Вначале написал про фильтры Privoxy, но потом вспомнил, что он, вообще-то, HTTPS фильтровать не может. По идее, нужен какой-то плагин к браузеру, который способен фильтровать по регулярным выражением. Тогда достаточно вырезать блоки
Вебмастер рассказывает, что нужно делать, чтобы отфильтровать баннеры с его сайта. :-)
Вариант – отказаться от HotLog'а и поставить какую-то свою систему статистики (например, CNStats) и баннеры продавать напрямую, с оплатой за время размещения.
А вообще, SATtva, посмотрите на Sape, например. Возможно, это даст большую прибыль.
И ещё, до кучи: Вы некрасиво поступаете, продавая рекламу (/Проект/Реклама/Dmitriy) с неиндексируемых страниц.
Некрасиво — высказывать обвинения и ставить под сомнение порядочность и репутацию человека, не имея представления о сути вопроса (воистину, суждения выносят, меряя по себе). У меня такое вообще в голове не укладывается. Страница запрещена к индексированию по просьбе рекламодателя, потому что её содержимое инклюдится на главную! Какое вообще это имеет отношение к предмету данного топика?
Ляпнул, не подумав. Всё, ни слова больше. Прошу прощения. :-[
Извинения приняты.
Если вернуться к изначально поставленному вопросу unknown'а, у кого-нибудь есть на примете такие расширения к Firefox, которые умеют фильтровать по регулярным выражениям?
Adblock[link2]?
А страница разве не будет отображаться битой, если в ней смешанный контент, пусть даже и заблокированный?
Оценку о "битости" выносит ведь сам браузер по итогу загруженного документа. Adblock показал свою работоспособность. Вот каких правил достаточно для устранения смешанного контента (в настройках нужно включить Remove ads):
Проблему считаем закрытой?
Firefox не единственный браузер.
Тогда ставьте фильтрующий прокси, способный выполнять собственный SSL. Или переходите на не-единственный Firefox. ;-)
Или используйте браузер, к которому можно поставить аналогичный плагин или как-то его пропатчить и все ваши проблемы будут закрыты, а сайт раскроет перед вами свою подлинную полноту SSL :-)
Сайты часто меняют сертификаты (продлевают, видимо), поэтому постоянно сталкиваюсь с "подозрительными сайтами". Постоянно приходится вбивать имя в жёлтенькое поле. Не только надоедает, но ведь так можно пропустить и настоящий поддельный сайт. Зачем было вообще этот petname ставить?
Не нашёл специальной темы про petname. Вопрос в общем-то пустяковый, решил не стоит открывать новую тему.
Что-то с petname не так.
Firefox 3.0.5, Petname Tool 1.6.
Заходим на сайт с SSL (для примера – https://www.verisign.com/ ), добавляем кличку. Идём в настройки apache, поднимаем локально сайт с SSL. В Ubuntu :-] по умолчанию для тестирования используется самоподписанный сертификат, выданный "ubuntu" для домена "ubuntu". Добавляем в /etc/hosts строку
127.0.0.1 www.verisign.com
При необходимости вносим www.verisign.com в список исключений для использования прокси броузером. Набираем в адресной строке https://www.verisign.com/ Получаем предупреждения от броузера: "самоподписанный, выдан неизвестным CA, выдан для другого домена", petname показывает вопросики – правильно, на сайт мы ещё не попали. Добавляем исключение, оказываемся в корне нашего веб-сервера, petname показывает ранее установленную кличку.
После проверки осмотрелся внимательнее на страничке расширения[link3], там есть комментарий от 9 января, в котором говорится, что после обновления сертификата кличка не сбросилась.
Может быть, оно проверяет только адрес (защита от похожих урлов)? Либо баг?
По идее он должен сравнивать опечаток хэша сертификата для конкретного имени сайта в SSL-сеансе. Самоподписанный или нет – это его не волнует.
Наверное, я плохо объяснил.
В теории: идём на verisign, добавляем кличку, petname запоминает отпечаток. Поднимаем локально для тестирования сервер с SSL, настраиваем возможность обращаться к нему по адресу www.verisign.com. Заходим, petname видит, что отпечаток сертификата другой и не показывает кличку.
А на самом деле, если проделать это, petname всё равно отображает кличку.
И там есть комментарий от человека, который сменил сертификат на своём сайте. Он ожидал, что petname увидит другой сертификат и будет считать сайт неизвестным. А оно продолжило показывать присвоенное раньше имя.
На самом деле с petname что-то не так. Это расширение добавляет собственную панель закладок. Когда пользователь присваивает кличку сайту, petname добавляет в эту панель одноимённую закладку, внося в поле описания DN и отпечаток сертификата (по SHA-1). В этом случае, при смене сертификата есть с чем его сравнить. Так petname вёл себя во втором Firefox'е.
Сейчас проверил с третьим: новый сайт, которому дана кличка, внесён в панель закладок petname, но поле описания оставлено пустым. Получается, на соответствие проверяется только доменное имя. От фишеров это может и спасёт, но не от скрытной смены сертификата.
Я глянул в исходник: программный код, который хэширует SSL-сертификат, был удалён в версии 1.1. Ну, я ещё увидел, что в Firefox3 интерфейс закладок не позволяет сохранять описания закладок, так что не уверен, можно ли вообще поправить положение.
Имеете в виду, API не имеет таких функций? Ибо поле Description там есть.
Совершенно верно.[link4]
А разве это[link5] не подходит?
Я думаю, что keyword — это "Скорочення", то есть слово, позволяющее использовать данную закладку для поиска. Впрочем, можно и туда срать. :)
Мне кажется что проблема с SSL логином на сайте легко решается, если по клику на ссылке "вход" будет грузится страница без баннеров. Тогда вы будете точно знать, что пароль передается на страницу без открытого контента.
Кукки вообще не украдешь, так как они передаются на домен www.pgpru.com который зашифрован.
Причем, этой уязвимостью можно воспользоваться лишь с помощью mitm, так как в противном случае она не имеет смысла, если вы доверяете сайту.
Причем mitm возможен лишь в случае некорректного кода на сайте.
В случае использования сети типа Tor – MITM на исходящих узлах это обычное явление. А вслучае некорректного кода на сайте и вообще никакой MITM не нужен.
Кстати, наберите в поисковике "HTTPS SSL mixed content" и ужаснитесь размаху проблемы. Коммерция на баннерах, экономия ресурсов сервера на отображении графики HTTPS и безопасность в данном случае противостоят друг другу.
Смешанный контент – всё равно что его отсутствие. По хорошему, браузер сначала должен вообще на такие страницы не пускать и только если юзер ответит "да, я сам себе злобный буратино", открывать их с битым значком.
mitm то возможен, но если не хранить сертификат сайта. а в чем проблема смещанного контента? По ssl вы грузите index.html и все скрипты включая форму логина зашифрованы, если не используется ajax. содержимое index.html защищается от mitm сертификатом. баннеры не могут вывести свою форму логина поверх основной или спереть кукки не со своего домена
Вот, начинаем верить в доменные имена и IP-адреса вместо криптостойких протоколов с сертификатами.
Вместо баннеров можно произвести MITM, который добавит к странице нечто, якобы исходящее из этого же домена.
При смешанном контенте можно подсунуть браузеру код, который получит доступ к тому, что передается в якобы защищенной части.
Хотелось бы подробнее. JavaScript движок браузера не делает различия между https и http, подобно тому как он делает различия между разными доменами?
Или баннер может воспользоваться уязвимостью браузера в iframe?
"Beware of Finer-Grained Origins"[link6]
Collin Jackson, Adam Barth
Stanford University
...всё равно что отстуствие HTTPS конечно же.
unknown:
Ага! Теперь ясно! Очередная дырка в браузере. Или эту уже пофиксили? Если конечно Коллин Джексон проверял это на практике.
Там хороший теоретический обзор, который строился не на пустом месте, а в сотрудничестве с коммандой Mozilla в том числе.
Не очередная дырка, а концептуально повторяющаяся плачевная ситуация, которая будет проявляться в разных дырках. Фиксить это практически бесполезно. Там авторы предлагают кое-что, но можно сделать вывод, что разделение смешанного контента в браузерах хоть по доменам, хоть по протоколам, хоть по чему-угодно всегда было и будет реализовано небезопасно.
То есть решено, что petname в Firefox3 не использует отпечатки сертификатов?
Гость (12/02/2009 22:49), похоже на то. А разработчик на странице расширения что-нибудь об этом упоминает? Может быть баг?
Кажется, не упоминает. Если на то пошло, не помню, чтобы автор когда-нибудь что-то писал об отпечатках сертификатов. Надо бы у него спросить...
Я написал о сертификатах в список рассылки: https://www.mozdev.org/mailman/listinfo/petname
Спасибо. Правда на мой взгляд Вы были чересчур суровы: "Ко мне поступают сообщения, что petname не проверяет сертификаты..." :-)
Tyler Close уже ответил[link7]. Не мог бы кто-то кратко перевести суть? Дело в том, что убрали API, или нет?
Привет, poptalk.
Приспосабливая Petname Tool к Firefox 3, я изменил алгоритм привязки кликухи к сайту в соответствии с исследованием Collin Jackson-а относительно различения источников. См.: "Origin Granularity"[link8]
В исследовании Collin сообщает, что политика броузера такова: страницы, имеющие одинаковый источник (origin) (URL scheme, имя хоста, номер порта), могут свободно читать и записывать друг в друга. Таким образом, уровень доверия к страницам с одинаковыми источниками и разными сертификатами тоже одинаков. Поэтому Petname Tool привязывает кликуху к источнику, а не к сертификату. К сожалению, сертификаты не задают границ доверия в броузере, только источники задают.
Если вы хотите проверять сертификат, то следует удалить все сертификаты CA из броузера и использовать the certificate pinning UI, включенный в Firefox 3. Тогда броузер позволит использовать для named origin только pinned certificate. Так как Petname Tool привязывает кликуху к источнику, получится твердая привязка кликухи к сертификату.
Это всё, что я могу сделать с учетом текущей модели безопасности броузера.
--Tyler
poptalk, спасибо.
А что значит "страницы, имеющие одинаковый источник (origin) (URL scheme, имя хоста, номер порта), могут свободно читать и записывать друг в друга"?
Если js-код загружен из источника https://somesite.com:443, то он может производить активные изменения (через DOM) в документах, загруженных из того же источника, но не из http://www.othersite.ru:80. То есть разделение доверия производится по источнику, но не по SSL-сертификатам.
А нет ли у Вас примера кода, SATtva? Не знаком с JS сколько-нибудь хорошо, но, кажется, он не должен иметь возможности изменить что-то за пределами собственного документа.
Вышеуказанный документ не говорит, к каким броузерам это относится, но ясно сказано "read and modify (i.e., control completely) another document", то есть "читать и изменять (то есть полностью контролировать) другой документ". Ждём заплаток. Как бы включать в origin еще и SSL-сертификат никому вроде мешать не должно.
Писать в баг-тракер Мозиллы.
Развивая тему смешанного контента. Стоило лишь Мокси Марлинспайку миксануть, для слета черных вязанных шапочек (http://blackhat.com/presentati.....ke-Defeating-SSL.pdf[link9]) парочку известных в прошлом трюков против пользователей (подойдя к этому творчески, однако), как пресса (чуть более светлых цветов и без шапочек) назначила SSL'у маленькую пушистую северную лисицу в награду.
Он всего-то взял за аксиому наличие смешанного контента, когда доступ к странице с безопасным логином производится (для пользователя) с обычной страницы полученной по незащищенному каналу, через чудеса веб технологий или просто по ссылке. Немного фокусов с иконками для сайта. Или немного игры с сертификатами для интернациональных доменов, для пущей убедительности. И вот он какой эффект, для широких слоев народонаселения. Вот она сила смешанного контента.
Ну вот 13 числа и сменится сертификат безопасности....
В 12 часов 21 минуту 58 секунд он истекает в понедельник..
Проблема неполноты SSL опять открыта:
http://www.pgpru.com/themes/plastiq/icons/file.gif
http://www.pgpru.com/themes/plastiq/icons/web.gif
Видимо что-то хотели загрузить)
Наверное, не совсем понятно выразился. Приведённые мною ссылки присутствуют в атрибуте src тега img на HTML-странице, загружаемой по HTTPS с сайта www.pgpru.com. Эту ошибку в HTML-странице, думаю, нетрудно исправить.
А не проще ли будет разделить все страницы на две группы в зависимости от их функций на сайте? На одних будут содержаться рекламные банеры и они будут отдаваться только по http, а на других смешанного контента не будет совсем и они будут отдаваться только по https.
Видимо нельзя. Юзера-то кормят банерами против его воли :-) а так он просто заражет http и вообще смотреть их не будет.
Интересно, а как будет выглядеть переключение между http и https ?
Я думаю просто линковку можно сделать. Версия https, где все адреса и содержимое будут принимать виртуально вид https://www.хххх.сом.
Хотя есть проблемы, например в вордпрессе:
http://blog.sjinks.org.ua/word.....-for-http-and-https/[link10]
Он и так весь этот ad.* фильтровать может. Только лень.
бабки, брат!
бабки вещь суровая ...