The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Google и Apple присоединились к блокировке сертификатов WoSign и StartCom

01.11.2016 10:19

Следом за Mozilla компания Google объявила о введении ограничений в отношении сертификатов, выданных удостоверяющими центрами WoSign и StartCom. Начиная с Chrome 56 сертификаты, выданные WoSign и StartCom после 21 октября 2016 года, будут помечаться как не заслуживающие доверия. Похожее решение принято компанией Apple, которая начнёт помечать в iOS как небезопасные сертификаты WoSign и StartCom, выписанные после 19 сентября.

В ответ компания WoSign сообщила о прекращении бесплатной выдачи сертификатов, аудите и повышению безопасности своей внутренней инфраструктуры, проведении работы по выполнению требований Mozilla и запуске процесса перехода на новые корневые сертификаты. Компания WoSign также опубликовала отчёт с разбором отмеченных представителями Mozilla нарушений, в том числе августовского инцидента, в результате которого была зафиксирована выдача постороннему лицу сертификата для одного из доменов GitHub.

  1. Главная ссылка к новости (https://security.googleblog.co...)
  2. OpenNews: Mozilla перестаёт доверять новым сертификатам WoSign и StartCom
  3. OpenNews: Mozilla обсуждает прекращение доверия к удостоверяющему центру WoSign
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45405-wosign
Ключевые слова: wosign, cert, chrome
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (44) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, mozgoprav (ok), 10:52, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Отлично, WoSign сразу засуетились. Mozilla так держать!
     
     
  • 2.15, НеуловимыйДжо (?), 12:44, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ага кунг-ФУ ПАЛЕЦ все уважают
     
  • 2.19, Michael Shigorin (ok), 13:42, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Отлично, WoSign сразу засуетились. Mozilla так держать!

    Таки опять вспоминаю про комодо.  Где обструкция всем парткомом?

     
     
  • 3.34, Crazy Alex (ok), 20:27, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тебе справедливость нужна? Ещё раз поймают комодо - придушат. Или нет - не суть. Суть в том, что прямо сейчас технических причин с ним бороться - никаких.
     
  • 3.36, Аноним (-), 22:32, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут я с вами полностью согласен. Не банановый бизнес...
     

  • 1.5, Genues (?), 11:09, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Китайца птица гордая - пока не пнёшь, не полетит.
     
     
  • 2.7, odd.mean (ok), 11:30, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как и любой BigBiz: никто не любит накладные расходы и исполнение обязательств. Просто некоторые особо упорствуют в своей неповоротливости (хотя и так деньги делают почти из воздуха) => "Будут наказаны" ©
     

  • 1.8, Какаянахренразница (ok), 11:33, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > присоединились к блокировке

    Гуртом і батька добре бити © древняя мудрость

    > В ответ компания WoSign сообщила о прекращении бесплатной выдачи сертификатов

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

     
  • 1.9, asdf (?), 11:51, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > В ответ компания WoSign сообщила о прекращении бесплатной выдачи сертификатов

    Гдеже теперь делать бесплатные сертификаты? Платить за них так не хочется....

     
     
  • 2.11, Какаянахренразница (ok), 12:01, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Гдеже теперь делать бесплатные сертификаты?

    [шёпотом] letsencrypt

     
     
  • 3.18, Адекват (ok), 13:23, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Гдеже теперь делать бесплатные сертификаты?
    > [шёпотом] letsencrypt

    А чё шепотом то, даже такой ленивец как я разобрался, как их делать.
    ЭТО КАКПЕЦ КАК ПРОСТО !!!
    Я честно говоря в приятном шоке.

     
     
  • 4.51, Snaut (ok), 13:38, 07/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Гдеже теперь делать бесплатные сертификаты?
    >> [шёпотом] letsencrypt
    > А чё шепотом то, даже такой ленивец как я разобрался, как их
    > делать.
    > ЭТО КАКПЕЦ КАК ПРОСТО !!!
    > Я честно говоря в приятном шоке.

    попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивлены

     
     
  • 5.52, Anonimous (?), 15:48, 07/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивлены

    Попробуйте их сделать вообще без компьютера и интернета!

     
     
  • 6.53, Snaut (ok), 15:52, 07/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивлены
    > Попробуйте их сделать вообще без компьютера и интернета!

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

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

     

  • 1.10, Аноним (-), 11:56, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Пипец браткам пришел. Только LET'S ENCRYPT.
     
     
  • 2.12, Tihon (??), 12:06, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • –7 +/
    1. С его помощью ты не сделаешь нормальную авторизацию TLS если у тебя нет своего УД, или внешних (белых) адресов на каждого клиента.
    2. Совет перейти на IPv6 - в данном случае не имеет смысла, т.к. софт с ним работать пока не умеет. К тому же Lets Encrypt научился его использовать лишь недавно.
     
     
  • 3.13, XXXasd (ok), 12:20, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > К тому же Lets Encrypt научился его использовать лишь недавно.

    и где тут проблема?

    он научился недавно, а ты что -- якобы свой комментарий написал типа давно в прошлом?

    пусть хоть научился вчера. главное что теперь эта точка невозврата пройдена

     
  • 3.14, XXXasd (ok), 12:26, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > 1. С его помощью ты не сделаешь нормальную авторизацию TLS если у
    > тебя нет своего УД, или внешних (белых) адресов на каждого клиента.

    всё правильно.

    говнотехнологии не нужны (это я про вашу "мега секъюрную" клиенскую TLS-авторизацию).

    больше проблем чем пользы. геморой на пустом месте.

    основные (главные) проблемы безопасности, такие как CSRF, XSS, SqlInjection, ClickJacking, SessionHijacking, ... -- через TLS-авторизацию НЕ решаются.

    попробуй использовать для авторизации -- логин-пароль (через HTTPS).

    я даже разрешаю тебе использовать клиентские localStorage для хранения (на клиентской стороне) особо длинных паролей.. и разрешаю тебе использовать WebCryptoAPI (на той же клиентской стороне) для их шифрования кротким-человеко-понятным паролем пользователя.

    и да! авторизация через логин-пароль -- точно также не решает основные (главные) проблемы безопасности -- CSRF, XSS, SqlInjection, ClickJacking, SessionHijacking, ...

    зато на порядок проще.

     
     
  • 4.20, Michael Shigorin (ok), 13:44, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > попробуй использовать для авторизации -- логин-пароль (через HTTPS).

    Где, на SMTP?

     
     
  • 5.37, xm (ok), 00:47, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Что, логины и пароли для клиентской аутентификации в SMTP уже отменили?
     
     
  • 6.42, angra (ok), 05:57, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, https не завезли. Михаил тонко намекнул, что кроме http/https есть и другие протоколы, где сертификаты, в том числе заверенные, бывают востребованы.


     
  • 4.21, Crazy Alex (ok), 15:12, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Говоря как пользователь - я был бы рад иметь один, внятный и стандартизированный способ авторизации. Который бы гарантированно нормально ловился менеджером паролей, исключал бы глупости кривых реализаций и где сайт не мог бы вычудить очередной "супер-интерфейс" логина (во всяком случае, без возможности обхода).
     
  • 4.46, Аноним (-), 11:01, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Есть масса протоколов отличных от HTTP(s): SIPS, SRTP, SMTP, IMAP и некоторые СУБД также могут (и будут, если это настроенно) заворачивать данные в TLS.
     
  • 2.48, Аноним (-), 23:01, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Только LET'S ENCRYPT.

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

     

  • 1.16, Аноним (-), 13:13, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Про первый УЦ (WoSign) помню новости, а что произошло со вторым? Почему их блочить решили?
     
     
  • 2.17, Аноним (-), 13:23, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Про первый УЦ (WoSign) помню новости, а что произошло со вторым? Почему
    > их блочить решили?

    StartCom принадлежит WoSign и используется для перекрёстного утверждения сертификатов.

     
  • 2.25, Аноним (-), 17:58, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Второй был втихую куплен WoSign, но отрицал это. Однако, под грузом неопровержимых доказательств (они даже общую инфраструктуру стали использовать) признался.

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

     

  • 1.22, Аноним (-), 16:54, 01/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вот бы они еще добавили в JavaScript возможность получить доступ к тем же параметрам сертификата, которые доступны для расширений, чтобы скрипт на страничке мог эти данные отправить на сервер, для обнаружения MITM proxy и информировании пользователя.
     
     
  • 2.24, XoRe (ok), 17:50, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот бы они еще добавили в JavaScript возможность получить доступ к тем
    > же параметрам сертификата, которые доступны для расширений, чтобы скрипт на страничке
    > мог эти данные отправить на сервер, для обнаружения MITM proxy и
    > информировании пользователя.

    https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
    Тоже неплохо информирует пользователя.

     
     
  • 3.27, Аноним (-), 18:54, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    По мне так это абсолютно бесполезная технология Мелкие сайты она не защитит, а ... большой текст свёрнут, показать
     
     
  • 4.32, гооглер (?), 20:01, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Беда ещё и в том, что у гугла, амазона, и учи других больших контор одновременно в ходу по куче валидных сертификатов на многие урлы, и они меняются в зависимости от того, на какой кусок CDN попал. То есть они мельтешат постоянно.
     
  • 4.38, xm (ok), 00:52, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > У HTTP_Public_Key_Pinning эффективность меньше 10%.

    Очень хочется ответа за этот базар...
    Но "проблему первой ночи" с HPKP и частично с HSTS вы правильно заметили.

     
  • 3.39, xm (ok), 00:54, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
    > Тоже неплохо информирует пользователя.

    Она не информирует - она заходить не даёт через соединение с внезапно новым сертификатом.

     
     
  • 4.50, XoRe (ok), 23:10, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
    >> Тоже неплохо информирует пользователя.
    > Она не информирует - она заходить не даёт через соединение с внезапно
    > новым сертификатом.

    И это очень неплохо информирует пользователя о MITM, не находите? :)

     
  • 2.28, odd.mean (ok), 18:59, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    JavaScript разучился в запросы? Ну curl тогда используйте, раз такое бедствие... Или через пых там, не знаю, а ответ распарсить пайтоном... У openssl есть биндинги для любого фрик-языка, не то что для мэйнстримных, как не нашли?
     
     
  • 3.29, Аноним (-), 19:16, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты о чем вообще?

    Я написал про такой сценарий: пользователь со своего браузера (который под его контролем) заходит на сайт (сервер под контролем админа) и, получив ответ, парсит данные сертификата сервера с помощью JavaScript страницы, работающем в браузере клиента. В случае обнаружения MITM прокси, отдает эти данные на сервер. JavaScript страницы знает, какие параметры должны быть у сертификата сервера. Сбор такой статистики очень быстро отучит разные конторы типа Trustwave (http://www.opennet.dev/opennews/art.shtml?num=33034) продавать свои сертификаты третьим лицам. Таким образом доверие к TLS сильно прибавиться.

     
     
  • 4.33, Crazy Alex (ok), 20:25, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    И что помешает MITM подменить эти данные при отправке на сервер? Ну, то есть что-то такое накрутить можно, но только в варианте security by obscurity - пока никто не знает, что сайт грузит такой JS. Дальше - можно воротить всякие хитрые схемы с полиморфной генерацией скрипта, но мне тсрашно думать, как такое сделать работим на сколько-нибудь большом продакшне.
     
     
  • 5.35, Аноним (-), 20:39, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И что помешает MITM подменить эти данные при отправке на сервер?

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

     
     
  • 6.44, angra (ok), 06:12, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Зачем искусственный интеллект, если MITM это целевая атака и на этапе ее подготовки присутствует естественный интеллект, которому эта задача на раз плюнуть.
     
  • 4.40, xm (ok), 01:03, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Я написал про такой сценарий: ...

    "Нет, сынок, это фантастика".
    Вы заранее не можете знать какой сертификат именно "тот самый", который нужно проверять, если ранее не были на этом сервере. То есть та же "проблема первой ночи", которая возникает и с HPKP.
    Поскольку сначала идёт коннект (и, соответственно, акцепт сертификата), то что помешает MitM'щику отдать вам исправленный скрипт проверки или не отдавать его вовсе?
    На практике может спасти единая база выданных сертификатов, попытку создать которую предпринял Comodo - https://crt.sh Тогда, прежде чем соединяться, можно получить данные о выданных для сайта сертификатах и уже требовать при коннекте именно их.
    Но встаёт вопрос, во-первых, поддержки такого механизма на стороне браузера, а, во-вторых, и это главное, степени доверия содержимому такой базы.

     
  • 4.45, noway (??), 11:01, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чувак, прекрати https переизобретать
     
  • 2.41, Аноним (-), 01:17, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > мог эти данные отправить на сервер, для обнаружения MITM proxy и
    > информировании пользователя.

    Тогда MITM-ы, очевидно, начнут вырубать скрипт или патчить его чтобы не выделывался. А что им помешает то? :)

     
  • 2.43, angra (ok), 06:08, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > мог эти данные отправить на сервер, для обнаружения MITM proxy и информировании пользователя.

    Неужто мысль о том, что MITM возьмет и заменит эти данные на свои, даже не приходит в голову?


     
     
  • 3.49, Crazy Alex (ok), 00:28, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    можно сделать, чтобы это было нетривиально. О массовой подмены, вроде корпоративной - спасёт
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру