LINUX.ORG.RU

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

 , , , ,


3

2

Из-за многочисленных нарушений в подконтрольных компании Symantec центрах сертификации ранее уже рассматривались меры снижения доверия, однако тогда не обсуждался полный отказ в доверии (www.linux.org.ru/news/security/13311135).

Сегодня обсуждается уже полная «блокировка» сертификатов от подконтрольных 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 ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

anonymous ()

Тем временем американцы вот просто так отжали домен 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 ★★★★★ ()
Ответ на: комментарий от gentoo_root

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не совсем так

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

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

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

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

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

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

vzzo ★★ ()

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

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

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

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

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

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

Re: не совсем так

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

Когда у меня был сайт с 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 ★★ ()
Ответ на: комментарий от vzzo

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ★★★ ()