Следом за Mozilla (https://www.opennet.ru/opennews/art.shtml?num=45368) компания Google объявила (https://security.googleblog.com/2016/10/distrusting-wosign-a...) о введении ограничений в отношении сертификатов, выданных удостоверяющими центрами WoSign и StartCom. Начиная с Chrome 56 сертификаты, выданные WoSign и StartCom после 21 октября 2016 года, будут помечаться как не заслуживающие доверия. Похожее решение принято (https://support.apple.com/en-us/HT204132) компанией Apple, которая начнёт помечать в iOS как небезопасные сертификаты WoSign и StartCom, выписанные после 19 сентября.
В ответ компания WoSign сообщила (https://www.wosign.com/english/News/announcement_about_Mozil...) о прекращении бесплатной выдачи сертификатов, аудите и повышению безопасности своей внутренней инфраструктуры, проведении работы по выполнению требований Mozilla и запуске процесса перехода на новые корневые сертификаты. Компания WoSign также опубликовала отчёт (https://www.wosign.com/report/WoSign_Incident_Report_Update_...) с разбором отмеченных представителями Mozilla нарушений (https://wiki.mozilla.org/CA:WoSign_Issues), в том числе августовского инцидента (https://www.opennet.ru/opennews/art.shtml?num=45049), в результате которого была зафиксирована выдача постороннему лицу сертификата для одного из доменов GitHub.
URL: https://security.googleblog.com/2016/10/distrusting-wosign-a...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45405
Отлично, WoSign сразу засуетились. Mozilla так держать!
Ага кунг-ФУ ПАЛЕЦ все уважают
> Отлично, WoSign сразу засуетились. Mozilla так держать!Таки опять вспоминаю про комодо. Где обструкция всем парткомом?
Тебе справедливость нужна? Ещё раз поймают комодо - придушат. Или нет - не суть. Суть в том, что прямо сейчас технических причин с ним бороться - никаких.
Тут я с вами полностью согласен. Не банановый бизнес...
Китайца птица гордая - пока не пнёшь, не полетит.
Как и любой BigBiz: никто не любит накладные расходы и исполнение обязательств. Просто некоторые особо упорствуют в своей неповоротливости (хотя и так деньги делают почти из воздуха) => "Будут наказаны" ©
> присоединились к блокировкеГуртом і батька добре бити © древняя мудрость
> В ответ компания WoSign сообщила о прекращении бесплатной выдачи сертификатов
Идиоты. Единственный шанс выжить -- это раздавать сертификаты бесплатно всем желающим и надеяться, что крупный УЦ не станут банить.
> В ответ компания WoSign сообщила о прекращении бесплатной выдачи сертификатовГдеже теперь делать бесплатные сертификаты? Платить за них так не хочется....
> Гдеже теперь делать бесплатные сертификаты?[шёпотом] letsencrypt
>> Гдеже теперь делать бесплатные сертификаты?
> [шёпотом] letsencryptА чё шепотом то, даже такой ленивец как я разобрался, как их делать.
ЭТО КАКПЕЦ КАК ПРОСТО !!!
Я честно говоря в приятном шоке.
>>> Гдеже теперь делать бесплатные сертификаты?
>> [шёпотом] letsencrypt
> А чё шепотом то, даже такой ленивец как я разобрался, как их
> делать.
> ЭТО КАКПЕЦ КАК ПРОСТО !!!
> Я честно говоря в приятном шоке.попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивлены
> попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивленыПопробуйте их сделать вообще без компьютера и интернета!
>> попробуйте их сделать не имея доступ до технической учетки и не имея linux на компьютере. будете сильно удивлены
> Попробуйте их сделать вообще без компьютера и интернета!сарказм не уместен. я владелец сайта третьего уровня, хостинг у меня. у меня нету линукса, чтобы выписывать там не понятные скрипты летс энкрипт. у меня есть только доступ до веб=директории и возможность установить сертификат, передав его админу сервера. все. не сможете.
и да, у платных сервисов вы это сможете сделать, лишь имея доступ до веб-директории сайта... и о боже, можно прям из веб-интерфейса запросить сертификат, оплатить и получить код, разместив который вы получите свой сертификат..
Пипец браткам пришел. Только LET'S ENCRYPT.
1. С его помощью ты не сделаешь нормальную авторизацию TLS если у тебя нет своего УД, или внешних (белых) адресов на каждого клиента.
2. Совет перейти на IPv6 - в данном случае не имеет смысла, т.к. софт с ним работать пока не умеет. К тому же Lets Encrypt научился его использовать лишь недавно.
> К тому же Lets Encrypt научился его использовать лишь недавно.и где тут проблема?
он научился недавно, а ты что -- якобы свой комментарий написал типа давно в прошлом?
пусть хоть научился вчера. главное что теперь эта точка невозврата пройдена
> 1. С его помощью ты не сделаешь нормальную авторизацию TLS если у
> тебя нет своего УД, или внешних (белых) адресов на каждого клиента.всё правильно.
говнотехнологии не нужны (это я про вашу "мега секъюрную" клиенскую TLS-авторизацию).
больше проблем чем пользы. геморой на пустом месте.
основные (главные) проблемы безопасности, такие как CSRF, XSS, SqlInjection, ClickJacking, SessionHijacking, ... -- через TLS-авторизацию НЕ решаются.
попробуй использовать для авторизации -- логин-пароль (через HTTPS).
я даже разрешаю тебе использовать клиентские localStorage для хранения (на клиентской стороне) особо длинных паролей.. и разрешаю тебе использовать WebCryptoAPI (на той же клиентской стороне) для их шифрования кротким-человеко-понятным паролем пользователя.
и да! авторизация через логин-пароль -- точно также не решает основные (главные) проблемы безопасности -- CSRF, XSS, SqlInjection, ClickJacking, SessionHijacking, ...
зато на порядок проще.
> попробуй использовать для авторизации -- логин-пароль (через HTTPS).Где, на SMTP?
Что, логины и пароли для клиентской аутентификации в SMTP уже отменили?
Нет, https не завезли. Михаил тонко намекнул, что кроме http/https есть и другие протоколы, где сертификаты, в том числе заверенные, бывают востребованы.
Говоря как пользователь - я был бы рад иметь один, внятный и стандартизированный способ авторизации. Который бы гарантированно нормально ловился менеджером паролей, исключал бы глупости кривых реализаций и где сайт не мог бы вычудить очередной "супер-интерфейс" логина (во всяком случае, без возможности обхода).
Есть масса протоколов отличных от HTTP(s): SIPS, SRTP, SMTP, IMAP и некоторые СУБД также могут (и будут, если это настроенно) заворачивать данные в TLS.
> Только LET'S ENCRYPT.Лучше не только, чтобы конкуренция не давала им особо расслабляться.
Про первый УЦ (WoSign) помню новости, а что произошло со вторым? Почему их блочить решили?
> Про первый УЦ (WoSign) помню новости, а что произошло со вторым? Почему
> их блочить решили?StartCom принадлежит WoSign и используется для перекрёстного утверждения сертификатов.
Второй был втихую куплен WoSign, но отрицал это. Однако, под грузом неопровержимых доказательств (они даже общую инфраструктуру стали использовать) признался.Так что, это одна контора, и нарушения у них (выпуск задним числом сертификатов со слабым алгоритмом) были одни и те же.
Вот бы они еще добавили в JavaScript возможность получить доступ к тем же параметрам сертификата, которые доступны для расширений, чтобы скрипт на страничке мог эти данные отправить на сервер, для обнаружения MITM proxy и информировании пользователя.
> Вот бы они еще добавили в JavaScript возможность получить доступ к тем
> же параметрам сертификата, которые доступны для расширений, чтобы скрипт на страничке
> мог эти данные отправить на сервер, для обнаружения MITM proxy и
> информировании пользователя.https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
Тоже неплохо информирует пользователя.
По мне так это абсолютно бесполезная технология. Мелкие сайты она не защитит, а сертификаты популярных (Google, Facebook) уже встроены в браузер. Суть в том, что эта технология не защищает при первом заходе. Посмотри на статистику любого сайта, кроме любимой социалочки - процент новых пользователей больше 50%. Т.е. сегодня ты включаешь HTTP_Public_Key_Pinning и защищаешь те 30% пользователей, которые пришли не первый раз, но уже завтра среди этих 30% не новых заходов будут те, кто пришел сегодня и получил данные через MITM.Ну, или другое объяснение - любая ссылка на сайт, на котором ты еще не был потенциально может быть загружена через MITM прокси. Посмотри в истории своего браузера сколько сегодня новых сайтов ты посетил и сколько тех, где бываешь регулярно. У HTTP_Public_Key_Pinning эффективность меньше 10%.
Беда ещё и в том, что у гугла, амазона, и учи других больших контор одновременно в ходу по куче валидных сертификатов на многие урлы, и они меняются в зависимости от того, на какой кусок CDN попал. То есть они мельтешат постоянно.
> У HTTP_Public_Key_Pinning эффективность меньше 10%.Очень хочется ответа за этот базар...
Но "проблему первой ночи" с HPKP и частично с HSTS вы правильно заметили.
> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
> Тоже неплохо информирует пользователя.Она не информирует - она заходить не даёт через соединение с внезапно новым сертификатом.
>> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
>> Тоже неплохо информирует пользователя.
> Она не информирует - она заходить не даёт через соединение с внезапно
> новым сертификатом.И это очень неплохо информирует пользователя о MITM, не находите? :)
JavaScript разучился в запросы? Ну curl тогда используйте, раз такое бедствие... Или через пых там, не знаю, а ответ распарсить пайтоном... У openssl есть биндинги для любого фрик-языка, не то что для мэйнстримных, как не нашли?
Ты о чем вообще?Я написал про такой сценарий: пользователь со своего браузера (который под его контролем) заходит на сайт (сервер под контролем админа) и, получив ответ, парсит данные сертификата сервера с помощью JavaScript страницы, работающем в браузере клиента. В случае обнаружения MITM прокси, отдает эти данные на сервер. JavaScript страницы знает, какие параметры должны быть у сертификата сервера. Сбор такой статистики очень быстро отучит разные конторы типа Trustwave (https://www.opennet.ru/opennews/art.shtml?num=33034) продавать свои сертификаты третьим лицам. Таким образом доверие к TLS сильно прибавиться.
И что помешает MITM подменить эти данные при отправке на сервер? Ну, то есть что-то такое накрутить можно, но только в варианте security by obscurity - пока никто не знает, что сайт грузит такой JS. Дальше - можно воротить всякие хитрые схемы с полиморфной генерацией скрипта, но мне тсрашно думать, как такое сделать работим на сколько-нибудь большом продакшне.
> И что помешает MITM подменить эти данные при отправке на сервер?MITM придется либо "исправить" скрипт проверки, причем так, чтобы все остальные скрипты остались работоспособными (иначе непонятно что произойдет со страницей), либо исправлять отправку результатов проверки (которая может быть замаскирована под запрос картинки, например, и без получения правильного результата запроса опять же непонятно как изменится страничка в браузере). В обоих случаях для нестандартной проверки такому MITM потребуется недюжинный искусственный интеллект (а если ее еще временами слегка изменять...).
Зачем искусственный интеллект, если MITM это целевая атака и на этапе ее подготовки присутствует естественный интеллект, которому эта задача на раз плюнуть.
> Я написал про такой сценарий: ..."Нет, сынок, это фантастика".
Вы заранее не можете знать какой сертификат именно "тот самый", который нужно проверять, если ранее не были на этом сервере. То есть та же "проблема первой ночи", которая возникает и с HPKP.
Поскольку сначала идёт коннект (и, соответственно, акцепт сертификата), то что помешает MitM'щику отдать вам исправленный скрипт проверки или не отдавать его вовсе?
На практике может спасти единая база выданных сертификатов, попытку создать которую предпринял Comodo - https://crt.sh Тогда, прежде чем соединяться, можно получить данные о выданных для сайта сертификатах и уже требовать при коннекте именно их.
Но встаёт вопрос, во-первых, поддержки такого механизма на стороне браузера, а, во-вторых, и это главное, степени доверия содержимому такой базы.
чувак, прекрати https переизобретать
> мог эти данные отправить на сервер, для обнаружения MITM proxy и
> информировании пользователя.Тогда MITM-ы, очевидно, начнут вырубать скрипт или патчить его чтобы не выделывался. А что им помешает то? :)
> мог эти данные отправить на сервер, для обнаружения MITM proxy и информировании пользователя.Неужто мысль о том, что MITM возьмет и заменит эти данные на свои, даже не приходит в голову?
можно сделать, чтобы это было нетривиально. О массовой подмены, вроде корпоративной - спасёт