Как стать автором
Обновить

Комментарии 62

пользовался раньше… но теперь это уже не важно. С тех пор как LE обещал сделать wildcard со след года — всё стало не важно
Да, раньше многие пользовались. Более того, многие оплачивали у StartCom платные аккаунты (точнее, проходили платную проверку), тем самым формирую и себе лучшие условия, и проект подпитывая. Как так они умудрились удавить корову курицу, приносившую золотые яйца?
китайцы. насколько я слышал, они не работают на репутацию и долгосрочные перспективы. схватить и бежать, короче. и желательно ночью.
Вот действительно :) Благодарю этот случай за то, что наконец-то нашел желание и силы разобраться с Let's Encrypt. Теперь только захожу иногда, проверяю как сертификаты обновляются сами собой. И главное, что не забудешь через год это сделать вручную, как в случае с WoSign было у меня раньше пару раз…
Насчет обновления согласен полностью. Знаю людей, которые покупали платные сертификаты на несколько лет сразу не из-за цены (она уменьшалась при оплате, скажем, на 3 года вперед), а чтобы просто менять их в системе раз в 3 года, а не каждый год.

CA то выписывал такие сертификаты. Но то, что серт истечет через большее время, заодно влияет на шанс его быть скомпроментированным за это время — собственно, потому LE и сделали 3 месяца. Причем, коммерческие CA по поводу автообновления вроде не очень согласны, или я плохо искал? Но, даже если оно и есть, многие просто ленятся его настроить, и руками (да-да, желательно пореже) обновляются.

А с LE, хочешь или нет, а отладишь раз автообновление (раз в 3 месяца бегать и ручками заниматься — это уже перебор), и дальше уже живешь отлично!
НЛО прилетело и опубликовало эту надпись здесь
C xmpp либо самоподписанный, либо скриптом (я делал, но там возникает проблема — надо бы, чтобы еще и клиенты верили LE-ному серту; старые версии PSi не верят), либо, да, купить domain-validated сертификат за чуть меньше чем $13 на три года (опять надо смотреть, чтобы клиенты такое приняли), и ну его нафиг со скриптом бороться, проще раз в 3 года руками обновить.
На три года, получил бесплатный серт от StartSSL. Pidgin доверяет. С новых версий он и LE должен доверять, но мне лень рестартовать ejabberd так часто.
Интересно, можете мне предложить какое-нибудь применение xmpp, которое требовало бы сертификат, полученный от доверенного публичного СА? То есть такое, для которого не подходит самоподписанный сертификат? Не могу придумать, любой же Jabber сейчас — это такая сеть, внутреннего характера.
Признаться, кроме того момента, что xmpp-клиент сообщит юзеру при первом подключении, что сертификат ему неизвестен и проверить он его не может — нет. Да и то, в настойках многих клиентов ест галочка «принимать самоподписанные сертификаты»

Но — если так, то и MITM можно пропустить. Т.е. по уму все же даже сертификат своего самопального CA неплохо на машинах клиентов заранее принять, а упомянутую галочку не ставить.

Но это все от того, зачем вам серт. Шифрование есть — этого многих хватает, чтобы не передавать общение с сервером открытым текстом даже по локалки, а MITM не всех актуально бояться.
При всём уважении к LE и к идее сертификатов с публичным известным CA, необходимость заниматься зарегулированным байтолюбством и установкой ненужных решений для автоматизации, а также непредсказуемость — бесят вкрай. Тем более, что принцип «если ты не платишь за продукт — то продукт — это ТЫ» здесь более чем применим.

Баны мозиллы, хрома без обьяснения причин — это же идеальная причина признать, что X509 устарел, и время переходить на WoT.
Имхо, место всех этих сертификатов — один раз отдать пользователю страничку с инструкцией «1) поставьте наш корневой сертификат 2) перейдите на домен, обслуживающийся с этим сертификатом», может хоть после какого-то количества таких акций неповиновения нам прекратят навязывать ненужную услугу.
Пока LE не появился, многие некоммерческие сайты работали с самоподписанными — и работали.
Другое дело что если меня на каждом сайте будут спрашивать поставить в моей сисеме чей-то корневой серт — лично я рад не буду.
НЛО прилетело и опубликовало эту надпись здесь
История показательна прежде всего тем что производители популярных браузеров могут при желании удавить любую компанию имеющую представительство в сети Интернет и ведущую бизнес в Интернет, просто потому что они большие и могут себе это позволить.
Двоякая ситуация.

С одной стороны — StartCom облажались, спору нет. И их лажу надо как-то прекратить. И прекратили — остановили доверие к новым сертификатам (= приостановили весь бизнес), потребовали аудитов и всего-всего. Справедливо. Окей.

С другой стороны — ну хорошо, ну остановили вы негодяев. А вот дальше начинается вопрос «а в чём же виноваты легитимные получатели их услуг?» Сначала прибили всех кто не попал в топ Алексы (окей, то-есть почти всех вообще, так как топ алексы — это уже кандидат в клиенты Comodo / GoDaddy / КтоТамЕщёЕсть). Теперь хотят добить оставшихся (а они остались?)

По-моему шумиха уже улеглась, LE взлетел, но история показательна для всех. И для поставщиков «доверия» («не злоупотребляй»), и для разработчиков («бесплатный сыр и всё такое»).

Сертификаты скомпрометированы. Эти черти могут выпустить другой сертификат и подписать его, не отозвав оригинальный, давая возможность устроить MitM на HTTPS.


По-хорошему давно пора было забанить этот CA с такими приколами.

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

Думаю, StartCom, так же, как и WoSign, получали множество вежливых, невежливых и всяких других намеков от браузеростроителей. И, раз уж они никак не внимали (простите за тавтологию) «последним китайским предупреждениям», дошло до такой точки. Казуистически говоря, перед пользователями все же виноваты не авторы браузеров, а CA, который, «давая зуб», что будет честным, обманул их доверие.

С другой стороны, а что Гуглу с Мозиллой было делать? Сказать «мы против обмана, но ради пользователей закроем глаза»? Тем более что и платных альтернатив хватает, и вот бесплатная, в лице LE, имеется и развивается.

Причем к последней приложили кошельки и руки многие «большие игроки», и есть какая-то надежда, что свое детище они (опосредованно, но все же) постараются держать как надо.
НЛО прилетело и опубликовало эту надпись здесь
Судя по вопросам Google к Symantec, в рамках наведения порядка следует ждать продолжения чистки — давайте посмотрим, оздоровит ли это ситуацию!
На мой взгляд, это просто борьба государств. LE сделан, чтобы анб могло без лишних проблем посмотреть что там гуляет по https нажав на спонсоров LE. А StartSSL это китай, который хотел сделать тоже самое. Напрягает во всей этой ситуации, что LE единственный такой центр сертификации, монополист имхо, что не есть правильно.

CA необходимо наказывать, причём максимально жёстко! И очень плохо, что это начинают делать только сейчас.


Сейчас на доверии CA держится почти полностью весь https (исключая редко используемые pinned сертификаты), и если CA не будут максимально серьёзно относиться к своей репутации и безопасности своей инфраструктуры — надёжность https может сильно пострадать.


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

Очень легко перегнуть палку между необходимым (достаточным) и избыточным. Особенно в нашей стране.
Если создать дополнительные издержки CA, за них заплатит конечный потребитель.

В свое время StartCom смогли себе позволить не брать денег за сертификаты первого уровня, которые выпускаются автоматически без участия человека. Теперь к ним нет доверия, на их место пришел Let's Encrypt. На мой взгляд это правильно, что должны быть бесплатные сертификаты, иначе это очень смахивает на продажи воздуха.
Не совсем так. Продажа доверия всё таки, не воздуха.
Все бы хорошо, но в мире, как кажется, маловато осталось CA, которым можно доверять на том основании, что они прошли аудит и за ними не числится ни одной откровенное некорректной операции — кроме LE.

Причем, если брать именно «больших ребят», то они точно не белые и пушистые, а цены за ими выпущенные сертификаты высоки.

Так что иногда торговля доверием похожа, увы, на торговлю воздухом.
Nobody's perfect. Однако стремится к этому можно и нужно.
Кто против? Но для завоевания доверия нужно, таки, завоевывать доверие. Вот, китайские товарищи показали, как его можно потерять в таких масштабах, что даже Мозилла с Гуглом на них обиделись. Давайте спросим уважаемых ребят из Symantec, например, что они думают по поводу повышения доверия ко всем CA, что им принадлежат?

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

Не обязательно. Издержки CA более-менее фиксированные (не зависят от количества выпущенных сертификатов), так что их вполне реально покрывать за счёт платных EV сертификатов для средних/крупных компаний. Кроме того, их издержки могут покрываться гигантами вроде Google или дотациями из гос.бюджета — теми, кто заинтересован в безопасном вебе.


А вот если эти дополнительные издержки на обеспечивание высокого уровня защиты и контроля не создать, то какой в этих CA вообще смысл и чем они надёжнее моего собственного CA? По хорошему, используемый код и базовая инфраструктура CA должны быть выложены в открытый доступ для проведения публичного аудита. Поверх этого ядра они могут городить любые фичи/интерфейсы, но валидация того, можно ли выдать сертификат и сама выдача должна быть реализована одинаково у всех CA, и этот код должен лежать на гитхабе.

И Apple тоже. Я до недавнего времени использовал платный сертификат от StartCom (OV).
А с выходом новой бета-версии MacOS сайт превратился в тыкву. Пришлось быстро переключаться на LE.
Правильный порядок событий: StartCom продалась китайцам, стала играть по их правилам (тем самым превратясь постепенно в тыкву — и подставляя юзеров, которые ей доверяли), браузеры эту историю заметили, и начали банить серты от такого CA, ставшего тыквой. Сайты с сертификатами от этого CA тоже сделались тыквами (спасибо, StartCom, да), и тут уж, хочешь или нет, а пришлось в LE идти, или к «платным» товарищам.
В принципе, вся эта история наглядно показала, что разрекламированная безопасность https сводится не к шифрованию, а к дорверию.

Интересно, почему под раздачу попали именно китайские CA, а в замен по сути предложена альтернатива в виде LE из Калифорнии, у которого chrome и mozilla платиновые спонсоры?
Так любое шифрование сводится к доверию. Есть ли закладки в алгоритме шифрования? Надежен ли канал передачи ключей? Не скомпрометирован ли ключ получателем? И так далее и тому подобное.

Поэтому в рамках https даже самоподписанный сертификат является дефакто обеспечивающим безопасность, если пользователь доверяет издателю ключа (как это, например, делается в OpenVPN серверах — Ваш трафик все-таки надежно защищен на пути к и от сервера).
Как говорят немцы: доверие хорошо, а контроль еще лучше. По идее, большинство их этих рисков поддаются верификации и закрываются аудитом локальным систем. Но в случае с публичными ключами приходится доверять еще и внешним CA (и как следствие, тем, кто их контролирует). Но контролировать их, со своей стороны, практически нет ни какой возможности. Так что да, в случае частных сетей, самоподписные сетрификаты обеспечивают больший уровень контроля безопасности.
Так вот в том и дело, что в любом случае чему-то, но доверять надо :) А вдруг СА частной сети окажется скомпрометирован? Вот и вопрос минимум доверия к самому себе, насколько сам защитил свою сеть…

Даже есть взять какую-нибудь сверх секретную военную систему, в которой обмен информацией зашифрован, то опять же возникает вопрос доверия к людям, которые вводят ключевые данные, да и даже к тому, насколько верно разработан этот сверх секретный алгоритм. Все на принципе веры :)
Вот к слову, известный случай, когда летчик Виктор Беленко в СССР улетел из страны на военном самолете и сел в Японии. Результатом стала компрометация системы госопознавания (тоже системы, основанной на шифровании). А ведь летчику доверяли
Доверять приходится, вопрос масштаба. Вот если бы летчика контролировали снаружи — из Японии, или там пентагона — это бы сильно помогло СССР? :)

Вангую:


  1. При первом заходе на сайт будет спрашиваться "Сертификат этого сайта подписан таким-то известным CA. Продолжить? Да/Нет + (флажок 'сохранить')"


  2. При смене CA будет вопрос "Внимание, опасность! Новый сертификат сайта подписан другим CA." + #1


  3. Чтобы не возникало проблем с внешними ресурсами, HTML будет расширен атрибутом а-ля "cert-ca" для link/script/img/etc. или же добавлен в уже рекомендованный "integrity" атрибут.


  4. Будет глобальный платный реестр CA -аля ICANN:
    4.1. Не будет препятствия в добавление, кроме денежных взносов.
    4.2. Каждый участник сможет выдвигать закрепляемые в реестре обвинения с градацией по серьёзности.
    4.3. Организация будет отвечать за проверку


  5. В случае регистрации нарушений CA, пользователи браузеров так же будут получать предупреждения об этом.

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

… можно еще отказаться от слова «вангую», очень уж оно не русское.

Первые два пункта уже и сегодня есть. Заходите на сайт с самоподписанным сертификатом — именно это и увидите, примерно. Только тот же Chrome однажды стал думать, что вы «верите сертификату» не навсегда, а на время.

А если серьезно, то вот вопрос про «отвечать» очень скользкий. Перед кем отвечать, чем и как? Вот, китайские товарищи «ответили», так?

В жизни же ничего такого не будет, уверен. Тут до сих пор часть браузеров верят старым, необновленным спискам корневых сертов, а вы такую революцию…

Нет такого. Принятие сертификата для самоподписанного сайта != разрешение использовать конкретный заранее известный сертификат CA.


Если организация, заведующая реестром не будет справляться, то тот же Google и Mozilla смогут создать альтернативу, как например был создан Yarn вместо npm, а потом npm Inc. резко засуетились и добавили долгожданных фич.


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

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

Не уверен, скорее тенденция прямо противоположна. Подконтрольный MITM, сейчас является штатно поддерживаемым сценарием в системе (не-)предупреждения об атаках браузеров.

В крайних версиях google chrome, возможность посмотреть глазками на сертификат сайта хорошо запрятали. В пределах видимости остался только зеленый замочек со словом «Надежный» и сообщение, что соединение и информация надежно защищены.

Больше всего такая надежная защищенность внушает оптимизм, при серфинге через Fiddler прокси, чей self-signed сетрификат добавлен в «trusted root certificate authority» девайсов для тестирования. Этот прокси, для удобства разработки, дешифрует весь проходящий через него https и подменяет в нужных местах ответы сайтов. Заметить подвох (фактически MITM атаку) на стороне браузера можно по характеристикам сертификата, только специально покопавшись где-то во вкладках chrome dev-tools.
У меня на маке Chrome 58 не даёт заходить на сайты с сертификатами WoSign. Firefox заходит.
Вроде как от «мачности» вашего ПК это не должно зависеть: это же поведение Chrome и Firefox, и я сомневаюсь, чтобы производители не сделали эту политику одинаковой для всех платформ.

А Chrome и FF каких версии у вас?

P.S. Хотя я тут задумался — а на каком сайте проверить, кроме wosign.com? Их-то сайт как раз могут оставить в белом списке, мало ли…

А вот не знаю, зависит или нет — в виндах-то всё вроде как через родной центр сертификатов сделано… и только FF юзал свой. Может и здесь всё через keychain.


Проверить можно на, например, https://xinit.ru/bs/

Я тут недавно «споткнулся» о следующую мысль. Блокчейн — это технология доверия, когда нет доверия никому конкретно. И тут я понял — этож лучше, чем грядущая проверка сертификатов через CAA-запись. CAA-запись частично решает вопрос доверия CA, но тот же CA может выпустить второй сертификат. А ведь еще есть и DNS-спуфинг.
Хранение всех выданных сертификатов в блокчейне тоже имеет свои минусы, но идея, на мой взгляд, интересная.
Мысль интересная. Только вопрос, какой размер база сертификатов примет, и как эту технологию встроить в существующий техпроцесс работы с сертификатами?
Размер базы — это проблема, особенно для мобильных устройств. Впрочем, как и процедура отзыва сертификата.

Возможно, необязательно хранить всю базу локально. Ведь и сейчас при создания SSL-тунеля, в частности для проверки сертификата на отзыв, требуется обращение ко внешним ресурсам. Что если для проверки сертификатов обращаться к случайным узлам, в стиле p2p, может даже к узлам в сети onion/tor?

А для вопросов непосредственной реализации, достаточно чтобы этим заинтересовались Google и Mozilla =)
Распределенная схема с персональными сетями доверия, в целом, реализована для верификации подписей PGP, но на практике не сильно популярна из-за сложностей в использовании.

А у Google и Mozilla уже есть Let's Encrypt, который теоретически способен продуцировать аналитику — кто, когда и на какие сайты. Зачем еще какие-то заморочки?)
Let's Encrypt лишь следует существующей формальной логике — цепочка до CA и пр. Для клиента нет никаких различий между выпуском сертификата от Let's Encrypt и другого CA или же двумя разлиными выпусками сертификатов от Let's Encrypt для одного и того же домена.

Вобщем все проблемы существующей инфраструктуры CA присутствуют и здесь. Идеально было бы избавиться от CA вообще.
Теоретически вы правы. Просто когда вендоры отдельного CA, которые по совместительству владеют подавляющей долей рынка браузеров и двигают технологии, так же являются его платиновыми спонсорами, это создает интересную ситуацию. Возможно, в целом, такая централизация не так уж плоха — браузеру ведь в любом случае приходится доверять. Но сам рост уровня консолидации ключевых технологий в руках отдельных корпораций впечатляет.
Странно, что более мелкие игроки на рынке браузеров, типа Яндекса, до сих пор не сделали свой домашний CA, по аналогии с LE.
Яндекс как-то писал, что для своих целей они сами себе CA (искать пост не буду), так что не исключено, что они скоро появятся на рынке с идеей «нового, никому в голову не приходившего сервиса» DavayShifruy. Я был бы рад хоть одному CA в Росии, но вот как они с товарищами майорами и господами депутатами договорятся…
Импортозамещение :)
Кривоптозамещение.
Не знаю, но я в своем Firefox нашел и Yandex (SHA1: DD:F1:0E:6D:A7:2C:44:7E:CA:D8:74:EB:53:1B:49:66:2D:2C:6E:D2) и RU-CENTER (SHA1: 0D:C4:12:DB:C9:BF:0B:4F:CA:C7:7A:3B:73:AA:07:AA:4F:DE:BD:45)

CAA не решает вопрос доверия вообще ни разу, однако существенно ограничивает возможность выпуска сертификата неавторизованным через неё CA.
Решение на сегодня это DANE. Однако, производители прикладного софта её внедрять не спешат.
По поводу блокчейн. Я вижу, что большинство вообще не понимает что это, для чего её целесообразно использовать и, тем более, как он работает. В большинстве случаев, в частности и этом, блокчейн не нужен, поскольку вполне достаточно куда менее сложных и затратных способов реализации. Это, к примеру, цифровые подписи которые с успехов функционируют в рамках даже такой не слишком складно спроектированной системы, как DNSSEC.

Любой кейс с наличием вменённой доверенной части не решает проблему.


Единственное решение — это когда для каждого конкретного сервиса пользователь сам сможет выбирать/подтверждать "корни доверия", от которых уже далее выстраивается и проверка имён, и установка защищённого соединения, и проверка содержимого, и т.д.


Для обывателя это мало чего даст, но в режиме параноика другого пути нет.


В условиях противодействия разработчиков сложного клиентского ПО, дельным решением может быть собственный локальный системный MITM-proxy, который будет выполнять требуемые проверки независимо с удобством для пользователя. Пример выше.


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

Любой кейс с наличием вменённой доверенной части не решает проблему.

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

Блокчейн в его классическом (биткоиновском) понимании тут не нужен, я не хочу что бы «завтра» «плохие люди», купив за 100$ (1000-10,000-не важно сколько) немного мощностей на амазоне(azure, google cloud, etc), построили альтернативную ветку этого блокчейна, выкинув «мой» сертификат в утиль и подставив туда свой.
В остальном идея правильная, и уже реализованная, смотрите RFC 6962, оно же Certificate Transparency оно же на Хабре.

Осталось ни так много: набрать критическую массу и выкинуть из основных браузеров поддержку тех CA, которые не начали играть по этим правилам (читайте: перестать принимать сертификаты, которых нет в данном логе).

Это конечно в корне не решит проблему «приходиться доверять какому-то непонятному дяде», но как минимум даст «технический» инструмент намного быстрей выявлять недобросовестных «дядь» и применять к ним административные меры.

Ну а для решения проблемы «хранения данного лога на устройстве» уже придумали OCSP, только к сожалению он не работает как надо.
Безопасность проще переводить в деньги, чтобы было понятно что является эффективным, что — нет. Это как гаечный ключ за 10$. Всегда можно дать админу на лапу или шантажировать его, чтобы получить сертификат. Сертификаты «ломают» и будут «ломать» всегда. В конечном счете, можно взломать вебсервер и вытащить ключ от туда (у мнгоих ли он запаролен?).

Я говорю не об этом. Мне приятней думать, что есть какая-то надежда на децентрализацию в вопросе доверия сертификатов. Что мы доверяем архитектуре/алгоритму/модели, нежели чем вот этим вот 3-5 организациям.

С новыми расширениями сертификатов тоже есть сложности. Есть (и всегда будет) старое ПО. Хотим мы или не хотим, но вопрос внедрения не может не занять множество лет. Я до сих пор в работе сталкиваюсь с Cisco PIX, редко, но сталкиваюсь. Так вот настройка этого «чуда» через браузер требует совсем старую JAVA и IE. Или вот, пример поближе VSphere 5.5 — вышел чуть меньше 4 лет назад, но требует Flash, который как мы знаем «выпиливается» из браузеров. С предлагаемыми расширениями, получится все тоже что и со всеми предыдущими — кто-то реализует, кто-то нет, кто-то реализует по своему. Это как внедрить очередной, 15-ый стандарт, который наконец объеденит все предыдущие (да, снова отсылка к Ренделу =) ). На мой взгляд, тут может сработать только принципиально новая идея (необязательно про блокчейн).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации