LINUX.ORG.RU

Firefox и Chrome полностью прекратят доверие к CA Symantec

 , , , ,


3

2

Из-за многочисленных нарушений в подконтрольных компании Symantec центрах сертификации ранее уже рассматривались меры снижения доверия, однако тогда не обсуждался полный отказ в доверии (В Google Chrome рассматривают меры постепенной блокировки всех CA Symantec).

Сегодня обсуждается уже полная «блокировка» сертификатов от подконтрольных Symantec центров: в Chrome ориентировочно с выпуска 66 (запланирован на 17 апреля 2018) предлагается отвергать сертификаты выпущенные ранее 1 июня 2016 и с 70 — полностью все; в Firefox несколько ранее — с декабря 2017 года, также поэтапно с полным отказом ориентировочно в выпусках 63 (16 октября 2018) или 64 (27 ноября 2018).

Под санкции попадают также CA GeoTrust, Thawte и RapidSSL, которые связаны с проблемными центрами цепочкой доверия.

>>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/gn1i2JNVCnc

>>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Oaeqtddo_Cw

★★★★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 3)

Ответ на: комментарий от anonymous

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

Надеюсь после первого такого случая веб браузеры в этой стране работать перестанут. Чтоб судья по ошибке не перевёл свои деньши куда не надо

NextGenenration ★★
()
Ответ на: комментарий от bodqhrohro_promo

Незашифрованный трафик не предлагать

Обоснуй. Параноик, что ли?

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

dimgel ★★★★★
()
Ответ на: комментарий от Legioner

препятствовать в том числе и активным атакующим, а против таких self signed не даст ровным счётом ничего.

Спасибо, этот момент я не учитывал.

dimgel ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Впрочем, поделом, SSL/TLS не нужен, а его принудительное навязывание всем подряд вне сферы финансов не нужно в кубе.

Расскажи, ка мне, как сделать так, чтобы при просмотре моего сайта, где-нибудь в метро, провайдер не вставлял туда свою рекламу?

Если тебе не нужно, не значит, что никому не нужно. Для многих этот ваш Linux ненужен.

anonymous
()
Ответ на: комментарий от entefeed

то, что такими темпами только letsencrypt и останется?

mrdeath ★★★★★
()

Тем временем американцы вот просто так отжали домен btc-e.com и уже запилили сертификат на него: http://rgho.st/7FFlWK7hg

Спрашивается, какой толк от этого SSL/TLS, если можно отжать домен, если ты американское правительство, а потом не составляет труда и получить сертификат на него и делать любой фишинг?

gentoo_root ★★★★★
()
Ответ на: комментарий от ilammy

Можешь пояснить, пожалуйста, что это за особенные атакующие? Я думал, TLS без разницы, кем выпущены сертификаты от конечного до корневого --- Google или dimgel.

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

Legioner ★★★★★
()
Ответ на: комментарий от gentoo_root

Тем временем американцы вот просто так отжали домен btc-e.com и уже запилили сертификат на него: http://rgho.st/7FFlWK7hg

И что тебя удивляет? Контролируешь домен, значит можешь получить сертификат.

Спрашивается, какой толк от этого SSL/TLS, если можно отжать домен, если ты американское правительство, а потом не составляет труда и получить сертификат на него и делать любой фишинг?

Может ты не совсем понимаешь, зачем нужен TLS? Он нужен для того, чтобы ты был уверен, что ты общаешься с владельцем домена, а не третьим лицом. Владельцем домена btc-e стало американское правительство, значит теперь ты можешь быть уверен, что общаешься именно с ним. TLS прекрасно выполнил свою задачу.

Вот если бы доменом продолжан владеть исходный владелец, а сертификат бы выпустили на американское правительство, вот тут уже можно было бы насторожиться.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Он нужен для того, чтобы ты был уверен, что ты общаешься с владельцем домена, а не третьим лицом.

А какой мне смысл быть уверенным, что я общаюсь с владельцем домена, если владелец домена может в один момент поменяться, а я об этом даже не узнаю?

Я хочу общаться с Васей и быть уверенным, что это Вася, а не Петя. TLS мне этого не даёт. С TLS я просто подхожу к закрытой комнате и получаю уверенность, что общаюсь через закрытую дверь с человеком в этой комнате, но какой в этом практический смысл, если в комнате может оказаться кто угодно? Да, я могу в теории определить по голосу, что это не Вася (посмотреть в whois), но, скорее всего, я не замечу подвоха.

gentoo_root ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Ну ходите тогда по всем пользователям своего сайта с паспортом и флешкой и ставьте им свой серт сами, если не доверяете симантекам.

vzzo ★★★
()
Ответ на: комментарий от gentoo_root

А какой мне смысл быть уверенным, что я общаюсь с владельцем домена, если владелец домена может в один момент поменяться, а я об этом даже не узнаю?

Не знаю, какой тебе смысл. Мне смысл есть. Просто так владелец домена не меняется.

Я хочу общаться с Васей и быть уверенным, что это Вася, а не Петя. TLS мне этого не даёт. С TLS я просто подхожу к закрытой комнате и получаю уверенность, что общаюсь через закрытую дверь с человеком в этой комнате, но какой в этом практический смысл, если в комнате может оказаться кто угодно? Да, я могу в теории определить по голосу, что это не Вася (посмотреть в whois), но, скорее всего, я не замечу подвоха.

Можешь попросить Васю использовать HPKP, это частично решит твою проблему. Можешь использовать аддон для браузера, который будет информировать тебя о смене ключа у сайта. Можешь попросить Васю использовать не Domain Validation сертификат, а Extended Validation сертификат. Его выдают именно Васе и браузеры его выделяют особым образом.

Domain Validation сертификаты заверяют тебя, что ты общаешься с владельцем домена. Большего от них ждать не стоит. Но для стандартных задач этой гарантии хватает с головой.

Legioner ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Потому что не всегда хочется, чтобы одинаковый логин/пароль пользователя на сайте утёк всем слушателям его публичного вайфая.

vzzo ★★★
()
Ответ на: комментарий от Legioner

Просто так владелец домена не меняется

Ага, ага, даже у гугла угоняли на полчаса.

bodqhrohro_promo
()
Ответ на: комментарий от dexpl

А я-то думал, что это Mr_Alone так за Symantec вступился.

Во первых я там уже не работаю, а во вторых ознакомься с портфолио Симантек и расскажи с какими продуктами ты работал? Только не нужно избитую песню про то, что вирусы пишут антивирусные конторы чтоб бабла срубить, и любой антивирус плохо работает. Пруфоф то конечно не будет?

Mr_Alone ★★★★★
()
Ответ на: И не жалко от dexpl

А как же Veritas (VxVM, VxFS, VCS и т.д.)? Сейчас они, правда, снова разделились.

shlag
()
Ответ на: комментарий от menangen

За self будут сажать в клетку.

... и надевать цак.

monk ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Для того, чтобы избежать MitM при шифровании, всё равно нужна третья доверенная сторона. Даже если шифровать/расшифровывать на фронте, ключ для этого шифрования должен откуда-то взяться.

vzzo ★★★
()

и при всем при том - файрфокс одновременно отказывается применить гостовскую криптографию


kto_tama ★★★★★
()
Ответ на: комментарий от Mr_Alone

я там уже не работаю

А что ж тогда так волнуешься?

dexpl ★★★★★
()
Ответ на: комментарий от vzzo

вот в этом и есть проблема реализации PKI браузерами

Ну ходите тогда по всем пользователям своего сайта с паспортом и флешкой и ставьте им свой серт сами, если не доверяете симантекам

есть мнение, что браузер не доверяет самоподписанным сертификатам исключительно из жадности, поскольку отследить отсутсвие пересечений множества самоподписанных сертификатов и множества подтвержденных СА не представляет никакой технической проблемы

MHz
()
Ответ на: комментарий от vzzo

не совсем так

Для того, чтобы избежать MitM при шифровании, всё равно нужна третья доверенная сторона. Даже если шифровать/расшифровывать на фронте, ключ для этого шифрования должен откуда-то взяться.

при первом контакте с сайтом для избежания MITM действительно нужна проверка при втором и далее третья сторона не нужна, требуется только проверять сохраненные параметры

для проверки можно использовать как dns так и и базы whois регистраторов (это при первом контакте)

то есть разработчикам браузеров надо задать вопрос: «работать не пробовали ?»

MHz
()
Ответ на: не совсем так от MHz

В целом — наверно можно было бы кидать в зону, подписанную dnssec хеш ключа, и он бы считался доверенным. Тогда доверять придётся регистратору, а не CA. Может быть, через 10 лет так и будет.

vzzo ★★★
()

отследить отсутсвие пересечений множества самоподписанных сертификатов и множества подтвержденных СА не представляет никакой технической проблемы

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

https://habrahabr.ru/post/332730/

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

anonymous
()
Ответ на: не совсем так от MHz

при втором и далее третья сторона не нужна, требуется только проверять сохраненные параметры

Когда у меня был сайт с 100 посещений в сутки, только 30% из них пришли не первый раз. Т.е. 2/3 посетителей не защищены перед MitM.

для проверки можно использовать как dns так и и базы whois регистраторов (это при первом контакте)

Про замену TLS с помощью DNS (возможно, DNSSEC) я как-то читал, насколько я понял, способ достаточно трудоемкий. Что касается DNSSEC, то однажды почитав, как его нужно настраивать для bind (а главное, каждый год обновлять), я понял, что сам этого делать никогда не буду. Поэтому эта технология никогда не станет популярной (она должна быть удобной, а настройка DNSSEC - это для задротов). Ну, а запросы к базе whois (точнее ответы) также можно подделать. Насколько я понимаю, они передаются в открытом виде.

anonymous
()
Ответ на: комментарий от vzzo

В целом — наверно можно было бы кидать в зону, подписанную dnssec хеш ключа, и он бы считался доверенным. Тогда доверять придётся регистратору, а не CA. Может быть, через 10 лет так и будет.

Возможно, если бы браузеры сверяли хеши разрешенных ключей через DNSSEC, это уменьшило бы уязвимость CA к «случайной» выдаче левых сертификатов. Однако кеширующий DNS клиент скорее всего будет использовать провайдеровский... А TLS как раз и работает почти исключительно для случая, когда твой провайдер захочет вставить в закачиваемую страницу свою рекламу (которая открывается на всю страницу на мобилке в метро). Т.е. либо у браузера будет dns клиент, проверяющий подписи DNSSEC, либо провайдер (когда захочет вклиниться в твой трафик) подставит туда какие ему нужно хеши...

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

Но ни один производитель браузера на это не пойдет, потому что властью делиться не захотят.

anonymous
()
Ответ на: комментарий от anonymous

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

Человек, подделавший сертификат, легко может вырезать этот клиентский js. Против метро, перехватывающего * сработает, но против подмены интернет-банка — нет.

vzzo ★★★
()

раньше друг друг посылали науйх, а шас новая мода — санкции вводят

fMad ★★
()
Ответ на: комментарий от vzzo

Человек, подделавший сертификат, легко может вырезать этот клиентский js.

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

Против NSA, ФСБ и других трехбуквенных организаций, защищаться вообще смысла нет, против остальных может сработать достаточно эффективно.

anonymous
()
Ответ на: комментарий от anonymous

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

это проблема браузеров, нарушающая процедуры PKI

MHz
()
Ответ на: комментарий от anonymous

Про замену TLS с помощью DNS (возможно, DNSSEC) я как-то читал, насколько я понял, способ достаточно трудоемкий. Что касается DNSSEC, то однажды почитав, как его нужно настраивать для bind (а главное, каждый год обновлять), я понял, что сам этого делать никогда не буду. Поэтому эта технология никогда не станет популярной (она должна быть удобной, а настройка DNSSEC - это для задротов). Ну, а запросы к базе whois (точнее ответы) также можно подделать. Насколько я понимаю, они передаются в открытом виде.

сложность настройки чего бы то ни было для Васяна никогда не будет достойным аргументом

как подделаете ответ от RIPE не контролируя маршрутизатор провайдера ?? если Вы не находитесь в подсетях RIPE или провайдера, то подделка ответов это только мечты или мега баг браузера, который почему-то задаст вопрос именно Вам, но такая ситуация ниже критики

MHz
()
Ответ на: комментарий от anonymous

А TLS как раз и работает почти исключительно для случая, когда твой провайдер захочет вставить в закачиваемую страницу свою рекламу (которая открывается на всю страницу на мобилке в метро)

я вот всегда думал, что трафик шифруют чтобы пароли в открытом виде не передавать и прочую конфиденциалку...а рекламу можно подсунуть на мобилку (на всю страницу) в режиме рекламаТРАФФИКТРАФИКТРАФИКреклама и т.д.

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

попробуйте структурировать этот поток сознания с указанием объектов, субъектов, действий и т.д.

MHz
()
Ответ на: комментарий от vzzo

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

Расскажите нам, какие CA при выдаче DV делают ручные проверки и как они укладываются в малые десятки секунд.

grossws
()
Ответ на: комментарий от vzzo

Кагбэ DANE и CAA RR есть давно. Другое дело, что нужен поднятый человеческий DNSSEC и соответствующие ресолверы у клиентов.

grossws
()
Ответ на: комментарий от anonymous

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

Почитай про HPKP на досуге. Оно, конечно, TOFU, но гораздо лучше чем ничего.

grossws
()
Ответ на: комментарий от grossws

Расскажите нам, какие CA при выдаче DV делают ручные проверки и как они укладываются в малые десятки секунд.

Абсолютно все платные CA это делают (при чём Symantec это делал в намного большей степени). Разумеется, вручную проверяются не все сертификаты. Но paupalcom.idfnvskjdhfnvksjdfnvkjsdnfvklsdnfv.cn бы без сомнения бы попал на ручную проверку и был бы отклонён.

vzzo ★★★
()
Ответ на: комментарий от grossws

Почитай про HPKP на досуге.

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

anonymous
()
Ответ на: комментарий от ckotinko

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

mandala ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.