Впервые увидел как выглядит в файрфоксе отозванный сертификат

ГОСТ 34.10

о, я только про симметричный ГОСТ 34.12-2018 (и более ранний 1986 года) была в курсе

Perfect Forward Secrecy не обеспечить, потому что в случае компроментации можно размотать handshake и получить ключ. Правильный путь – вырабатывать его по DHE/ECDHE.

вот эфемерный промежуточный ключ и генерируется соответственно, хотя я изложила свое понимание «на пальцах» т.к. если поднять понимание шифрования до четких математических материй, то это будет выше моего «двоечного» понимания.

только они не будут нам ничего подписывать (
Им тоже не нужны возможные неприятности, от которых у них будут убытки финансовые и другие...

Может будут, может не будут. Почему у них должны быть неприятности и убытки? Китайцы так-то если не друзья России, то и не враги. В любом случае мой поинт в том, что УЦ много и я пока не убеждён, что все они без исключения не будут работать с Россией. Вот mail.ru нашли какую-то харику, а сколько там ещё таких харик?

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

Пользователь не может ничего решать. Он тупой.

Он ленивый. Пока не пнёшь - не полетит. А как пнёшь - так не только с ВПНом каким прекрасно разберётся, но и с сертификатами своими прекрасно разберётся.

За него должны решать умные люди. И эти люди те, кто пишут браузер.

Бруазер пишут отнюдь не умные люди. Жадные, наглые и жуликоватые. Ничего из этого ума не требует.

Если сертификат отозвали, значит доверия ему больше нет.

Кто отозвал, почему вообще тогда выдали, кому и у кого доверия нет?

У меня вот вообще нет ни грамма доверия ни к одной конторке из списка Trusted CA. Там жулик на жулике и жуликом погоняет.

То, что ещё одни жулики решают за пользователя кому из других жуликов доверять, это вообще никак ничего не делает ни безопасным, ни создаёт никакого доверия.

Проверка сертификата на отзыв это неотъемлемая часть современной модели безопасности TLS

И в системе этим занимается openssl.

И без CRL получится обходиться

И CRL должны проверятся именно системным openssl и храниться в единственном месте в системе, целиком и полностью подконтрольном владельцу компа.

Если браузер не использует CRL, можно тогда вообще ничего не проверять

Зачем браузеру вообще знать о существовании CRL? Есть openssl - он знает. Надо установить соединение - открыл сокет - работай. Не открыл (CRL там, просрочка, просто no route to host или ещё что) - выведи сообщение о том, почему openssl не открыл сокет. Всё. Не собачье дело браузера лезть в работу сокетов. И не его дело решать, можно этот сокет открыть или нет. Этим система занимается.

Я вообще фигею - какие-то жулики напихали в сраную смотрелку страничек всё подряд, чтобы накрысить себе ништяков за счёт пользователей без их ведома и самыми гнусными способами, и при этом на ЛОРе находятся мимокрокодилы, которые этих подонков пытаются обелять.

Ее нет у тех сайтов, у которых настроен HSTS.

В Firefox можно отключить HSTS? Фича от которой только неудобства.

Поддомены vk.com тоже отвалились.

Да, стакан или наполовину полон или наполовину пуст, в зависимости от точки зрения наблюдателя.

Посмотрим...

Через «забыть о сайте» можно удалить сайт и его данные полностью, включая кешированные заголовки HSTS.

В целом игнорировать HSTS... ну можно как-то поломать, наверное, у меня ж браузер выдает, что он не умеет image/webp


PS: (претензии к алиске, если не сработает)
Введите

about:config

в адресной строке Firefox.
Примите предупреждение о рисках.
Найдите параметр

security.cert_pinning.enforcement_level

и установите его значение на

0

. Это полностью отключает проверки HSTS и позволяет обращаться к сайтам с включённым HSTS по HTTP.

В Firefox можно отключить HSTS? Фича от которой только неудобства.

HSTS ставил владелец сайта по собственному желанию. У пользователя нет механизма его отключить, максимум наверное можно сбросить его кеш.

Это не вообще не дело браузера какие-то левые CRL откуда-то скачивать

Они не левые, а прописаны в самом сертификате и являются частью стандарта TLS.

что в наших условиях становится незаменимо

По мне так всегда было полезно, и вовсе не из-за «условий», а из-за того что например может возникнуть желание при наборе в браузере https://some.domain.tld/prefix/ показывать содержимое http://127.0.0.1:34567/, который может быть например локальным тестируемым ресурсом (нафиг ему своё https и прибивание к 80/443 порту в угоду браузеру? ещё и с hosts возиться или локальным днсом). Хотя

Но это уже не TLS, это пародия на безопасность.

Но если использовать CRL то оно всё так же остаётся пародией на безопасность. Так что разница не такая большая как можно подумать.

Если, конечно, в CRL вообще есть эта причина отзыва и кодов там хватает, чтобы отличить одно от другого.

Ты такой наивный? Ну конечно они тебе признаются «с этим сертификатом всё норм, просто мы поссроились с его владельцем и решили ему нагадить, поэтому сайт не открывай».

экзотично немножко, но да, вполне себе use-case

Называть пародией на безопасность протокол, на котором зиждется вся безопасность в интернете по сути, это экстраординарные заявления. А такие заявления без экстраординарных же аргументов кажутся не слишком серьёзными.

Они не левые, а прописаны в самом сертификате и являются частью стандарта TLS.

Если они не в /etc/ssl - то они левые. А на запись в /etc/ssl у жуликов прав нет. И не им решать, как и с каким сертификатами работают системные сокеты.

Безопасность в интернете держится скорее на ssh. А в вебе безопасности и нет, там только пародия на неё. И зря ты сразу сказал «протокол», основные дыры не в нём, а в инфраструктуре. Впрочем, регулярное нахождение дыр в ssl-движках тоже вполне демонстрирует суть.

может возникнуть желание при наборе в браузере https://some.domain.tld/prefix/ показывать содержимое http://127.0.0.1:34567/, который может быть например локальным тестируемым ресурсом (нафиг ему своё https и прибивание к 80/443 порту в угоду браузеру? ещё и с hosts возиться или локальным днсом). Хотя

С этим проблем почти не возникнет. localhost считается безопасным источником и к http://localhost можно обращаться с https://anything.com сайта.

«Почти» потому, что в последних версиях хрома (за другие браузеры не в курсе) подобное требует отдельного подтверждения пользователя при первом использовании. Будет запрос из разряда «сайт обращается к локальной службе, разрешить?». После разрешения всё будет просто работать как ожидается (конечно это будет отдельный домен со всеми последствиями вроде SOP защит, поэтому, возможно, придётся отдавать CORS-заголовки, но, думаю, это и так понятно.

Как раз ssh это пародия на безопасность с его «вот вам куча непонятных цифр и букв, вы им точно доверяете?» при первом подключении и с его «шеф, кругом враги, мы под обстрелом, я сжёг все мосты» при смене ключа на той стороне. TLS с PKI на порядок лучше и продуманней.

Если они не в /etc/ssl - то они левые. А на запись в /etc/ssl у жуликов прав нет. И не им решать, как и с каким сертификатами работают системные сокеты.

Вот там у тебя находятся CA, которым ты доверяешь. CA выписывает сертификат сайта, в нем ссылка на CRL который нужно проверять. Соответственно если ты доверяешь CA, то доверяешь его CRL. Вроде все логично.

* _ты_

* _создатели/сопровождающие пакета_ с содержимым /etc/ssl /etc/ssl/ca-certificates.crt


сомневаюсь что кто-то лично проверял все содержащиеся там сертификаты и вычищал те, к которым _лично_ доверия нет. Кстати недоверенные (revoked) сертификаты там тоже есть. Не к ночи будет помянут Дигинотар например там был в свое время, сейчас убрали, т.к. наверное истек уже и сам сертификат.


А еще есть /usr/share/ca-certificates/mozilla

Ты такой наивный? Ну конечно они тебе признаются «с этим сертификатом всё норм, просто мы поссроились с его владельцем и решили ему нагадить, поэтому сайт не открывай».

Но по факту именно это и случилось.

тут (crt.sh) видно, что сертификат отозван с причиной «privilegeWithdrawn»

Если почитать интернеты, то этот статус четко отличается от статуса, когда ключ скомпрометирован (keyCompromise). Поэтому клиентское ПО вполне может обрабатывать его по-другому. Конечно игнорировать такую ситуацию точно не стоит, но всё же это не значит, что есть повышенный риск атаки MITM и нужно рубить с плеча.

С того хотя бы, что у меня например десяток профилей файрфокса и не во всех них одинаковые списки CA. Уметь использовать системные списки - норм, но обязательным это делать уже плохо. Тут вспоминается совершенно идиотское решение хрома по отсутствию собственных настроек прокси - наверно как раз твоей логикой руководствовались.

С другой стороны - абсолютно все программы используют системные сетевые сокеты.

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

Ну через OCSP можно обходиться без CRL, но почему-то он не слишком развит.

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

Тут вспоминается совершенно идиотское решение хрома по отсутствию собственных настроек прокси

Это как? Каждый день запускаю chromium с --proxy-server=×××. --proxy-pac-url=××× там тоже есть.

Тут вспоминается совершенно идиотское решение хрома по отсутствию собственных настроек прокси

вот тут как раз приходит на помощь Squid )

собственно никто юзерской проге и не даст прямой доступ к сетевухе

стеки mTCP, watTCP, picoTCP так и работают, через пакетный драйвер сетевой карты, но это «развлечение» для DOS систем

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

Так его уже приняли. Я ж пишу - странно что про GlobalSign нет новостей. А вот в тех местах, где они есть, вот что написано:

В опубликованном на сайте CA/Browser Forum документе, который вступил в силу 4 мая, содержится прямой запрет для удостоверяющих центров выдавать сертификаты компаниям из санкционных списков — проверка по OFAC SDN List, BIS Denied Persons List и их европейским аналогам стала не рекомендательной, а обязательной.

В CA/Browser Forum входят, кроме крупных CA, такие компании как Google, Apple, Microsoft, Mozilla. То есть если какое-то CA данные правила не соблюдает, теоретически его могут выкинуть из браузеров американских компаний.

для этого придумали ocsp_staple
где подписанный ответ кешировался и передавался вместе с сертификатом,
уважающие себя сайты это использовали, втч и с сертификатами ЛЕ, но потом там решили, что содержать OCSP сервера - дорого и перешли на CRL


Так или иначе, это не задумывалось как проверка в реальном времени

Ты не понял. Я не хочу, чтобы браузер видел какие-то локалхосты итд, я хочу чтобы браузер считал что он на указанном сайте с указанным урлом. А вот что на этом сайте будет показано, решать уже хочу сам, не оставаясь в рамках «запросим айпи по днс, подключимсмя к айпи, пошлём ему http-запрос». Вот для этого и нужно маршрутизирующее прокси, которое всё это делает незаметно для брузера.

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

Хм, и правда.

security.cert_pinning.enforcement_level

Спасибо, но с поддоменами vc.com это не помогло. Но помогло отключить защиту от отслеживания.

Как их на лету без перезапуска сменить? Так то можно и в env их прописывать.

И CRL должны проверятся именно системным openssl и храниться в единственном месте в системе, целиком и полностью подконтрольном владельцу компа.

А как владелец компа обновляет этот список в твоём понимании? Вот у какого-то банка подломили фронтенд и спёрли серт с ключом. Или растяпа инженер слил каким-то образом. Факт один серт ушел к злоумышленнику и он может через dns poisoning или ещё как заполучить тебя на свой хост с этим сертификатом когда ты идёшь оплачивать свой кофе. В итоге злоумышленник уводит уже у тебя токен доступа к твоему банковскому аккаунту. Поэтому важно иметь оперативную возможность отзывать серты. А не когда юзер почешется

Нет, там не так. Там есть такая штука, когда сервер сам с определённой периодичностью (например раз в час) запрашивает OCSP статус (подписанный) и потом в подключении он этот статус прикладывает к сертификату. Браузеру никуда ходить не надо.

Я думаю, что это враньё. Попробуй найти оригинал этого документа. Я не смог. Я тоже видел это утверждение в каких-то странных блогах.

Цифры не непонятные, это отпечаток ключа. Который ты должен (если тебе действительно важна безопасность) сравнить с настоящим отпечатком, полученным по безопасному каналу.

Посоветуй, где найти безопасный канал, по которому можно получить отпечаток ключа сервера github.com. HTTPS конечно же считаем небезопасным, раз такое дело.

В случае же с браузером тебе эти отпечатки не показывают

При желании всё показывают. Ровно 3 клика в хроме.

предлагают доверить эти проверки каким-то левым конторам, которые на словах пообещали быть честными.

Не просто на словах. А тут целая индустрия, которая проверяет, что эти левые конторы выполняют ряд весьма жёстких требований.

Хуже того, даже если они и правда захотят быть честными, ключи с истинными ключами они тоже в большинстве случаев не сравнивают, то есть дырявы даже в не имея злого на то умысла.

Не понимаю, что ты имеешь в виду. Когда ты хочешь получить сертификат от letsencrypt, ты отправляешь ему CRL, в котором твой публичный ключ и который подписан твоим закрытым ключом. И в выписанном сертификате закодирован ровно этот публичный ключ.

Я это утверждение видел в куче мест в т.ч. СМИ. Возможно друг у друга перепечатывают.

Правила кажется тут https://cabforum.org/working-groups/server/baseline-requirements/requirements/ но вроде там санкционные списки и правда не упоминаются. Сложно разобраться.

Посоветуй, где найти безопасный канал, по которому можно получить отпечаток ключа сервера github.com. HTTPS конечно же считаем небезопасным, раз такое дело.

Нигде. Поэтому при подключении к github.com ты вынужден доверять неопределённой третьей стороне, что очевидно небезопасно. От того, что настоящего безопасного способа нет, другие безопасными не становятся. Они всё так же подвержены подменам. Повторю ещё раз, в вебе нет безопасности.

Не понимаю, что ты имеешь в виду. Когда ты хочешь получить сертификат от letsencrypt, ты отправляешь ему CRL, в котором твой публичный ключ и который подписан твоим закрытым ключом. И в выписанном сертификате закодирован ровно этот публичный ключ.

Да, LE в свои сертификаты кладёт именно тот ключ, который ему прислали в запросе. Только вот удостовериться, что ему его прислал настоящий владелец домена, он достоверно не может - делает это через незашифрованный http. И сразу оговорюсь: да, у него нет других способов, но от этого этот способ безопасным не становится.

И ещё хуже: а что именно он собственно должен проверять? То что доменная запись на чьём-то днсе ведёт именно на твой сервер? А днс не подменили? А ссылку на твой днс из корневых не подменили? А вдруг провайдер у тебя айпи адрес забрал и отдал другому, а днс ведёт всё ещё на него? И даже если никого в этой цепочке не взломали, это всё третьи лица, и даже само доменное имя на них неизбежно завязано, то есть тут неустранимая дыра. Домен могут тупо административным решением некоего лица конфисковать и передать злоумышленнику, и тебе будет нечего предъявить кому-то вообще.

Я в гугл забил: «ca/browser forum ofac sdn» и в результатах поиска исключительно российские СМИ, которые, очевидно, перепечатывают друг у друга. Так что пока я склонен считать это всё чьей-то бурной фантазией, которую все начали разносить не проверяя. Всё, что произошло, это решение отдельной конкретной компании GlobalSign, скорей всего следующей законодательству конкретной страны, в которой эта компания расположена.

Всё я докопался до истины.

Про санкции упоминается тут (github.com).

Если поискать, то находится:

Acceptable Methods of Verification The CA MUST take reasonable steps to verify with the following lists and regulations:

A. If the CA has operations in the U.S., the CA MUST take reasonable steps to verify with the following US Government denied lists and regulations:

B. If the CA has operations in any other country, the CA MUST take reasonable steps to verify with all equivalent denied lists and export regulations (if any) in such other country.

Т.е. этот пункт для компаний из США требует придерживаться санкционных списков США, а для компаний из других стран требует придерживаться эквивалентных списков для других стран. Пункт, конечно, странный, про то, что не надо есть желтый снег, но юристы такие юристы.

Никакого обязательства для всех CA придерживаться списков США там нет.

Ну вообще-то это пользователю решать, доверять CA на каждом этапе, и на каждый момент времени, или уже нет. Раньше пользователь, например, доверял, а теперь нет, например. Так с какого перепугу надо доверять новому CRL от этого CA?

Системный ca-certificates это позволяет. Какое-то собственное хранилище браузера, да ещё и доступное для изменения самим браузером из-под обычного юзера - нет.

Вообще странная какая-то ситуация с этими Trusted CA. С чего вообще все решили что этим CA можно доверять? Просто потому что кто-то назвал их Trusted? Доверие нужно заслужить. Чем какой-либо из Trusted CA заслужил доверие рандомного ЛОРовского мимокрокодила? Какими своими действиями? Кто тут знает хоть что-то про тот же Global Sign? Тогда откуда доверие?

Понятно, о чём ты. Да, такая проблема есть и она эксплуатировалась при атаке на jabber.ru и при поддержке хетцнера. Когда кто-то (вероятно менты) установил MITM на сетевой порт и выпустил дополнительный сертификат для jabber.ru через который впоследствии осуществлял MITM-атаку.

У letsencrypt есть такая фича, ты можешь создать DNS запись с типом CAA и параметром accounturi в котором есть в том числе ID аккаунта. Подробней тут (letsencrypt.org). Если letsencrypt видит такую запись, то он проверяет этот uri. Для использования аккаунта используется дополнительный публичный и закрытый ключ. Обычно оно всё работает под капотом (автоматически создаёт аккаунт при первом использовании), но можно и явно этим управлять. Если ты используешь эту фичу, то никто не сможет использовать letsencrypt с другим аккаунтом или любой другой УЦ, правильная обработка этой записи это обязательное требование для всех УЦ.

Ещё упомяну, что ключ присылается через HTTPS, а не через незашифрованный HTTP. Поэтому подменить его нельзя. Можно лишь сымитировать этот запрос. Ты, наверное, имел в виду, что проверка домена осуществляется через HTTP. Это верно, но если использовать упомянутую выше фичу, то можно обезопаситься и от подобной атаки. Конечно когда у ментов есть физический доступ к оборудованию, то в конечном счёте всё, что можно сделать, это лишь затруднить им взлом, но хотя бы и так.

С того хотя бы, что у меня например десяток профилей файрфокса и не во всех них одинаковые списки CA

Завтра, десяток этих CA решит, что сертификаты на домены принадлежащие гражданам второго сорта можно раздавать всем. Браузер по прежнему будет рассказыаать тебе что они Trusted и молчать как партизан, если от домена ты внезапно получил какой-то другой сертификат, даже подписанным другим Trusted CA. Во всех твоих профилях.

Сокеты это низкоуровневая штука (собственно никто юзерской проге и не даст прямой доступ к сетевухе)

У используемых нынче в HTTP способов шифрования даже в названии прямо указано что они транспортного уровня, а не уровня приложения. И при использовании этих способов приложению предоставляются именно сокеты.

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

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

А как владелец компа обновляет этот список в твоём понимании?

Так, как ему заблагорассудится.

Вот у какого-то банка подломили фронтенд и спёрли серт с ключом.

Как только об этом узнал - немедленно едешь лично в такой банк, закрываешь там счёт и забираешь все свои деньги оттуда. Всё.

Поэтому важно иметь оперативную возможность отзывать серты. А не когда юзер почешется

Если юзер не закрыл счёт в таком банке - то он ССЗБ и заслужил.

Ну вообще-то это пользователю решать, доверять CA на каждом этапе, и на каждый момент времени, или уже нет. Раньше пользователь, например, доверял, а теперь нет, например.

Системный ca-certificates это позволяет. Какое-то собственное хранилище браузера, да ещё и доступное для изменения самим браузером из-под обычного юзера - нет.

Ты выбери уже или А или Б. То юзер должен сам решать кому доверяет, то ты не доверяешь юзеру, а доверяешь администратору компа

/me помнит времена http, все доверяли

У меня работает вход на эту помойку, серт валидный.

Ты выбери уже или А или Б. То юзер должен сам решать кому доверяет, то ты не доверяешь юзеру, а доверяешь администратору компа

Название «Персональный компьютер» тебе что-нибудь говорит? Юзер и администратор личного ПК это в 99.99999% случаев одно и то же лицо.

А на предприятиях, где ПК не личные, пусть штатный админ и следит и решает кому доверять. Ему в том числе за это деньги платят.

/me помнит времена http, все доверяли

Тогда беспроводная связь так не была распространена, и сетевое оборудование было дорогим и требовало знания, а всякие сниферы проводные были дороги ибо не справлялись с потоком. А мощности выросли и каждый дебил получил возможность врезаться в провод / послушать эфир и снять трафик без потери производительности.

Не доверяли, вероятности реализации риска были меньше, равно как и ущерб.