В пытающемся конкурировать с Lets'Encrypt сервисе автоматической выдачи SSL-сертификатов StartEncrypt (https://www.opennet.me/opennews/art.shtml?num=44603), развиваемом удостоверяющим центром StartCom (торговая марка StartSSL), выявлена (https://www.computest.nl/blog/startencrypt-considered-harmfu.../) критическая проблема с безопасностью, позволяющая получить заверенный удостоверяющим центром сертификат для не принадлежащего пользователю домена. Например, можно получить SSL-сертификаты для google.com и facebook.com, которые будут восприняты в браузерах как заслуживающие доверия.Проблема присутствует в реализации механизма проверки принадлежности домена заявителю. Как упоминалось в опубликованном две недели назад анонсе (https://www.opennet.me/opennews/art.shtml?num=44603), проверка выполняется закрытым приложением, представляющим собой "черный ящик", отправляющий сетевые запросы к внешнему API. Энтузиасты заинтересовались подобной сетевой активностью и в процессе анализа приложения, нашли в нём серию уязвимостей, позволяющих запросить сертификат, обманув стадию проверки принадлежности домена.
Первая уязвимость связана с тем, что для проверки контроля за доменом запрашивается файл "/signfile", но путь к этому файлу также указывается при запросе к API, что позволяет указать в запросе к API любой другой путь и получить сертификат для любого сайта, на который могут быть загружены сторонние данные. Например, файл можно загрузить на dropbox.com и указать путь к этому файлу при обращении к API, после чего StartEncrypt посчитает, что домен dropbox.com принадлежит данному пользователю.Вторая уязвимость расширяет возможности атаки сайтами, на которых допускаются перенаправления URL. При загрузке проверочного файла StartEncrypt обрабатывает редиректы, поэтому для получения сертификата чужого сайта не обязательно загружать на него данные, достаточно организовать пернаправление на свой хост. Функция перенаправления на URL при завершении сеанса определена в спецификации OAuth 2.0, что позволяет получить сертификат для любого сайта, поддерживающего OAuth 2.0. Например, сертификат можно получить для google.com, facebook.com, paypal.com, linkedin.com, login.live.com и т.п.
Кроме того, несколько уязвимостей выявлены в коде клиентского приложения: клиент не проверяет сертификат сервера при обработке ответов API, при загрузке проверочного файла не выполняется проверка типа контента (проверочный файл можно загрузить под видом изображения), приватный ключ (/usr/local/StartEncrypt/conf/cert/tokenpri.key) сохраняется с правами 0666, что позволяет любому локальному пользователю прочитать и изменить его.URL: https://www.computest.nl/blog/startencrypt-considered-harmfu.../
Новость: http://www.opennet.me/opennews/art.shtml?num=44708
Чудесно и ожидаемо
Пост-фактум всегда все "ожидаемо". А пруф в виде ссылочки на такие ожидания месячной и более давности не найдется ли?
> Пост-фактум всегда все "ожидаемо". А пруф в виде ссылочки на такие ожидания
> месячной и более давности не найдется ли?Да, вот http://www.opennet.me/openforum/vsluhforumID3/101910.html#63 же. Прямо _ждёт_.
И всем того же советует
http://www.opennet.me/openforum/vsluhforumID3/105773.html#59
http://www.opennet.me/openforum/vsluhforumID3/105125.html#32
http://www.opennet.me/openforum/vsluhforumID3/102930.html#32Крэзи - Голова! Почти Шнайер. Как сертифицировать, ка кбанки организоать -- всё знает. </>
Кто там в каждой новости про Let's Encrypt плевался и советовал использовать StartSSL? :-) Теперь настоящие профессионалы показали своё истинное лицо. Даже не верится, что в CA может быть такая некомпетентность.
> Даже не верится, что в CA может быть такая некомпетентность.это после дигинотара‐то?
Я в прошлых новостях агитировал за китайцев.
Ждём аналогичную историю про Comodo. Их хоть не жалко растерзать будет.
комодо выдаёт серты кому надо, а не первому встречному
Ну да. А кому - надо?
Кто платит -- тому и надо.
В Let's Encrypt, кстати, проблема с редиректом всплывала на ранней стадии бета-тестирования.
Ну вот разница в том числе в том, что там было огромное долгое бета-тестирование
> Ну вот разница в том числе в том, что там было
> огромное долгое бета-тестированиеКоторое ничего не вылавливает, на самом деле. Что неоднократно практика и показывала с другими софтами и продуктами. Британская Энциклопудия.
>> Ну вот разница в том числе в том, что там было
>> огромное долгое бета-тестирование
> Которое ничего не вылавливает, на самом деле. Что неоднократно практика и показывала
> с другими софтами и продуктами. Британская Энциклопудия.Практика показала на ситуацию с другими софтами и продуктами, а не с Let's Encrypt.
Да, было дело получал у них бесплатный сертификат, но столько проблем было. Получить смог только авторизовавшись под IE и т.д. Сложилось впечатление что это недоделанная чья та курсовая, но никак не серьезный проект. Номер кредитки я бы им не доверил. Как они поднялись не ясно. Не иначе как связи.
Через постель
Я, как вебмастер, вообще не хочу иметь доступ к приватным ключам своих сертификатов. Пускай мой хостер или name server их у себя хранит/обновляет, как AWS Certificate Manager делает.
Какая прелесть. Сегодня вроде первое июля, а не первое апреля.
Типичный вебмастер.
На aws закрытые ключи лежат в днс, чтобы вебмастер не мог их достать?
На ELB же
Ну читай потс на который я отвечаю
и ftp! обязательно доступ по ftp!!!блин....
раз http://lugasoft.ru/ok/etks/3501
два http://lugasoft.ru/ok/etks/4001
три http://lugasoft.ru/ok/etks/5104
...что же вас в вебмастера-то несёт...
> Я, как вебмастер,Ты не вебмастер.
> Я, как вебмастер, вообще не хочу иметь доступ к приватным ключам своих
> сертификатов. Пускай мой хостер или name server их у себя хранит/обновляетЧего мелочиться, сразу в роскомнадзор шли.
БРАВО!!!!
рукоплескаем!впрочем это было предсказуемо, еще в прошлой новости.
балбесы спалили дырку
> позволяла получить сертификат для чужого доменаЧего же они сразу не сказали-то? Полезная фича. Надо попробовать.
Вот это провал! По идеи надо у них отзывать доверие после такого.
>Проблема присутствует в реализации механизма проверки принадлежности домена заявителю.проблема присутствует в самой концепции ssl-сертификатов в том виде в котором они есть сейчас. защита https - это по большому счету мираж.
Вообще-то защита https - это как минимум два фактора:
1. Удостовериться, что имеешь дело именно с тем сайтом, на который зашел. Это работает, прямо скажем, неидеально.
2. Шифрование общения между пользователем и сайтом. А вот это нормально работает, причем с любым - хоть самоподписанным - сертификатом. Если, конечно, какие-нибудь защитнички не влезли в процесс со своими интересами.
Можно подробнее про первый пункт? (Вебмастер-мимокрокодил, не особо разбирающийся в тонкостях)
Загляните нормальным браузером на https-сайт уважающей себя конторы (vtb, например) - увидите рядом с замком сертификата "подтвержденье, что в пакете - не ослиная моча, а прекрасный вкусный сок".
> Загляните нормальным браузером на https-сайт уважающей себя конторы (vtb, например) - увидите
> рядом с замком сертификата "подтвержденье, что в пакете - не ослиная
> моча, а прекрасный вкусный сок".Вообще-то это подтверждение не сайта, а конкретного лица либо корпорации, стоящих за сайтом.
Если вам нужна точность - то это подтверждение принадлежности сервера, с которым вы установили соединение, тому самому лицу. Правда, не вижу, в чем тут практическая разница.
Бывают еще EV/OV сертификаты которые кроме домена подтверждают личность/организацию.
> Вообще-то защита https - это как минимум два фактора:к сожалению, они работают только в комплексе (точнее, никогда не работали и не будут, ибо комплекс гораздо сложнее и принципиально непроверяем)
> Удостовериться, что имеешь дело именно с тем сайтом, на который зашел. Это работает,
> прямо скажем, неидеально.это вообще не работает. Можно лишь с некоторой степенью достоверности это предположить.
> Шифрование общения между пользователем и сайтом. А вот это нормально работает, причем с
> любым - хоть самоподписанным - сертификатом.шарик, ты балбес. Кто тебе сказал, что сертификат, который видит твой браузер - тот, с которым ему отвечал сервер, если предыдущий пункт - пропущен? И чего после этого стоит твое "шифрование"?
А если у тебя нет никакого man in the middle - то зачем тебе шифрование вообще?То есть это нормально работает только с _тобой_ лично самоподписанным сертификатом, вручную проверенным, прежде чем установить его в браузер. Когда ты абсолютно уверен что флэшку из рук по дороге не выпускал.
К сожалению, браузеров, которым можно отключить нахрен идиотские "доверенные центры" и при этом сохранить возможность пользоваться современным интернетом (где в любой момент может оказаться шифрованный css или js из какой-нибудь совершенно неведомой cdn помойки даже на сайте без всякого шифрования) - не существует.
Во всяком случае, мне таковые неведомы.Вместо этого имеет место только стройная система костылей и подпорок, вроде cert pinning - опять не на той стороне, на которой ему нужно быть. Он должен быть на моей стороне - чтобы я, прочитав сертификат, подумав, сделал вывод - этому сертификату можно доверять, если (и только!) его предъявляет такой вот сайт (возможно - все сайты указанные в расширении, но это опять же должен вручную подтвердить я) и нет причин (revocation list или negative ocsp) считать его утратившим достоверность. Как только с той стороны предъявят что-то другое (или попытаются этим подтвердить валидность другого сайта) - надо все остановить, вывести красное окошко и снова ждать моего решения.
Так - оно было бы безопасно. Но, повторяю, этого не умеет ни один браузер на свете. Удали все trusted ca - у тебя вообще ничего работать не будет, кроме примитивных наколенных страничек (браузеры не умеют спросить про валидность сертификата для чего-либо кроме "страницы". Ни для картинок, ни для css/js). Подтверди постоянное разрешение использовать невалидный сертификат - у тебя им сможет подписаться кто угодно и когда угодно.Отчасти из-за ориентации всей системы на тупого пользователя, которому проще передоверить свою безопасность дядям, чем самому хоть что-то сделать. Отчасти явно потому, что кто-то кому-то очень даже неплохо платит.
Cистемой, выполняющей ваши требования безопасности, для серфинга настолько же невозможно будет пользоваться, как браузером, работающим только с HTTPS и дропающим запросы к HTTP.
Разве что для пульта, работающего с одним конкретным сервером, желательно вам же и подконтрольным.
Скажем так - SSL (именно в "стандартном" виде, и иерархией CA) сильно ограничивает круг тех, кто может влезть в ваш трафик. Настолько сильно, что, к примеру, для абсолютного большинства бизнеса этого абсолютно достаточно. Точно так же, как достаточно для защиты от всяких мелких хакеров, любителей снифить общественный вайфай и т.д. Для дефолта, достающегося задарма - более чем.
> Скажем так - SSL (именно в "стандартном" виде, и иерархией CA) сильно
> ограничивает круг тех, кто может влезть в ваш трафик. Настолько сильно,
> что, к примеру, для абсолютного большинства бизнеса этого абсолютно достаточно. Точно
> так же, как достаточно для защиты от всяких мелких хакеров, любителей
> снифить общественный вайфай и т.д. Для дефолта, достающегося задарма - более
> чем.Туфта. Себя успокаиваешь?
Ну я же как-то онлайн-банкингом пользуюсь и деньги не украли. На счет сильно ограничивает - автор предыдущего комментария перегнул. Я бы сказал сильно увеличивает стоимость атаки (относительно, а не абсолютно). Вот и выходит так, что от того, кто может себе это позволить нет смысла защищать ибо он и так может влезть в дела большинства (мелкий, средний) бизнеса. Так и живем - чем дальше тем страшнее.
Это не бага, это фича! Эх, что ж вы, спалили контору!
Сама идея публичных УЦ и вся отрасль сертификатов - одна сплошная уязвимость.
> Сама идея публичных УЦ и вся отрасль сертификатов - одна сплошная уязвимость.Абсолютно с тобой согласен, Анон.
Это тот самый случай, когда иллюзия безопасности много хуже полной небезопасности.
И что, теперь CA, который использовали под это дело заблэклистят во всех дистрибутивах? С другими УЦ, которые были скомпрометированы поступали ведь именно так
> И что, теперь CA, который использовали под это дело заблэклистят во всех
> дистрибутивах? С другими УЦ, которые были скомпрометированы поступали ведь именно тактам, скорее всего, достаточно самому startssl отозвать скомпроментированный intermediate (который был отдельный для этой автоматической херни)
Но что-то мне подсказывает - не дождемся даже этого.
Теперь все сертификаты StartSSL отзовут?
> Теперь все сертификаты StartSSL отзовут?Надо бы. Но это вряд ли.
Epic fail