13.06 // Плановое июньское обновление SSL-сертификата сайта
В ближайшее время будет произведена замена SSL-сертификата. Обращаю внимание, что по многочисленным просьбам трудящихся было решено перейти на услуги удостоверяющего центра StartSSL™, корневой сертификат которого присутствует в хранилищах большинства ОС/браузеров.
Отпечатки нового сертификата сайта и УЦ приведены ниже.
Скажите, почему работа по https требует отсылки чего-то на 80ый порт вот таких вот идентичных страниц?
Пытаюсь зайти на https://mail.google.com, при этом браузер зачем-то отсылает что-то на http://199.7.59.72. Пытаюсь зайти на эту страницу, ответ — application/ocsp-response (5 bytes).
Захожу на https://torproject.org — вижу соединение на 199.7.59.72:80. При попытке зайти туда мануально мне скачивает файл с содержимым
Что это всё значит?
Вот тут пишут, что Но если заблокировать http, браузер ни на что не ругается. Ну, хорошо, допустим, я соглашусь, что это необходимая проверка, но тогда как различать вот такие отправки по http от обычных (веб-серфинг страниц) на уровне fw? Получается, никак?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
А как Вы думаете браузер должен сверяться с CRL УЦ? Через libastral.so? Понятно, что он должен выполнить HTTP(S)-запрос. (Наличие/отсутствие SSL роли не играет, т.к. ответ УЦ подписан его ключом.)
Кстати, если в настройках OSCP Вы не включили опцию "При ошибке соединения с сервером OSCP рассматривать сертификат как недействительный" (а по умолчанию она выключена, по-моему, во всех браузерах), то смысла в этой проверке не будет ровно никакого, особенно при работе через Tor, что Вы, собственно, и продемонстрировали, заблокировав отправку запросов на уровне брандмауэра.
Я, думаю, раз единственное назначение опции — проверять не отозван ли преждевременно сертификат (а это довольно-таки экзотический, имхо, случай), блокирование всего http не скажется плохим образом толком ни на чём.
Через Tor всё работает по умолчанию. Я спрашивал про неанонимный серфинг.
комментариев: 11558 документов: 1036 редакций: 4118
Настройки > Дополнительные > Настройки OCSP.
Хозяин — барин.
Часто наблюдается MITM гугловского поиска, например. Что интересно, проставляют в качестве даты notBefore время, соответствующее времени проведения MITM-атаки. По всей видимости, каждому клиенту, чей трафик MITM'ится, впаривают свой сертификат, тут же генерируемый на лету.
SATtva, может быть, сей сертификат всё же подписан каким-то CA? Я не умею такие вещи смотреть.
комментариев: 11558 документов: 1036 редакций: 4118
Ловите экзит по отображению цепочек в Видалии и сообщайте о таких приключениях в рассылку tor-talk, чтобы администраторы корневых серверов забанили его к чёрту.
комментариев: 9796 документов: 488 редакций: 5664
Эксит м.б. не виноват. Гипотетический великороссийский файрвол, на котором испытывают DPI, может подменять сертификаты при заходе на pgpru.com с любого эксита ибо мастерхост находится в российской юрисдикции.
Видимо они давно современный Firefox не запускали совсем. Для поиска этой кнопки столько кликов надо совершить, что проще сменить личину не выходя из браузера и повторить запрос.
А нельзя как-то попроще, типа дать консольную команду для управляющего порта Tor? Только там какая-то авторизация в TBB для этого порта используется, ещё надо пароль откуда-то выцеплять.
Если одновременно открыто несколько цепочек, то как посмотреть, какая из них использовалась для данной заданной вкладки в firefox? Ведь разные вкладки могут использовать разные цепочки, или я что-то путаю? В случае MITM, конечно, можно поступить проще: выцепить все используемые экситы на момент атаки, а потом вручную проверить каждый из них на вшивость, благо опции Tor-клиента это вроде бы позволяют (фиксировать заданный exit).
Вообще, я время от времени сталкиваюсь с такими же подменами, например, для гуглопоиска, так как он тоже на https. И, наверняка, сталкиваюсь не я один, но другие читатели сайта почему-то об этом молчат.
Может, но зачем ему MITMить только соединения с каких-то определённых экситов Tor'а? Тогда бы уж делали MITM, как минимум, для всех экситов, а как максимум — вообще всегда, вне зависимости от того, через Tor обращаются на pgpru.com или напрямую. Ещё теоретически MITM может делать любой промежуточный узел, через который идёт трафик от эксита к сайту. Однако же, всё вышеописанное — скорее домыслы, а существование всяких bad exits в стастистике Tor — медицинский факт, поэтому я склоняюсь к последнему. Где-то на скрытых ресурсах даже вывешивался список bad exit'ов.
Firefox — не единственный браузер, используемый через Tor, хотя каков его процент среди Tor-трафика, сказать не могу (понятно, что высокий, но вопрос насколько).
Молчат, т.к видели "поддельный" сертификат. Нет там атаки и подмен, а есть сбои в датацентре гугла. К примеру sorry.google иногда отдает сертификат для другого домена всё того же гугла.