Согласно сообщению от компании Google, в скором времени (а именно — начиная с выпуска Chrome 61, который ожидается в середине сентября) будет полностью прекращено доверие к сертификатам, выданным удостоверяющими центрами WoSign и StartCom. Речь ведётся о сертификатах, выданных до 21 октября 2016 года, срок действия которых ещё не истёк (более новые сертификаты были заблокированы в прошлом году).В Chrome 57 (вышедшем в марте 2017 года) частично уже было прекращено доверие к старым сертификатом, но для сайтов, входящих в первый миллион по рейтингу Alexa, было сделано исключение. Теперь данный белый список будет убран и блокировка станет действовать в отношении выданных указанными СФ сертификатов к любому домену.
Стоит напомнить, что аналогичные меры уже действуют со стороны Mozilla: начиная с Firefox 51 (появившемся в января 2017 года) введено ограничение для новых сертификатов WoSign и StartCom, но поддержка сертификатов, выданных до 21 октября 2016 года, пока сохранена.
История началась с того, что в прошлом году представители Mozilla выявили ряд серьёзных нарушений в работе WoSign и StartCom. В ответ компания WoSign инициировала аудит, работу по устранению замечаний и повышению безопасности своей внутренней инфраструктуры, а также начала процесс получения новых корневых сертификатов. Из нарушений можно отметить:
- Игнорирование предписания, регламентирующего деятельность удостоверяющих центров, запрещающего использовать при создании сертификатов алгоритм SHA-1 с 1 января 2016 года (WoSign выписывал сертификаты с SHA-1 задним числом);
- Получение контроля за другим удостоверяющим центром (StartCom) без раскрытия сведений о совершённой сделке;
- Халатное отношение к безопасности, в частности применение устаревших версий сетевых приложений, без надлежащей установки обновлений (используемый на DNS-сервере пакет Bind последний раз обновлялся в 2011 году и содержит 19 неисправленных уязвимостей);
- Был зафиксирован инцидент, в результате которого была произведена выдача постороннему лицу сертификата для одного из доменов GitHub.
Трудно объяснить логику, которой руководствовались в WoSign, производя столь рискованные для репутации действия, однако прецедент налицо.
UPD: Goolge некоторое время назад озвучил свои вопросы в отношении компании Symantec: примерно 30000 сертификатов, выданных этой компанией, были, судя по всему, выпущены без должной валидации владельцев доменов. Похоже, можно ожидать, что в ближайшем будущем Chrome перестанет доверять этому списку сертификатов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (62)
selenite
08.07.2017 23:31-7При всём уважении к LE и к идее сертификатов с публичным известным CA, необходимость заниматься зарегулированным байтолюбством и установкой ненужных решений для автоматизации, а также непредсказуемость — бесят вкрай. Тем более, что принцип «если ты не платишь за продукт — то продукт — это ТЫ» здесь более чем применим.
Баны мозиллы, хрома без обьяснения причин — это же идеальная причина признать, что X509 устарел, и время переходить на WoT.
Имхо, место всех этих сертификатов — один раз отдать пользователю страничку с инструкцией «1) поставьте наш корневой сертификат 2) перейдите на домен, обслуживающийся с этим сертификатом», может хоть после какого-то количества таких акций неповиновения нам прекратят навязывать ненужную услугу.dmitry_ch
09.07.2017 00:04+2Пока LE не появился, многие некоммерческие сайты работали с самоподписанными — и работали.
Другое дело что если меня на каждом сайте будут спрашивать поставить в моей сисеме чей-то корневой серт — лично я рад не буду.
dartraiden
09.07.2017 01:24+1Баны мозиллы, хрома без обьяснения причин
Причины были озвучены ещё в прошлом году.
sumanai
09.07.2017 09:50+2и время переходить на WoT
Жутко ненадёжная система, незащищённая от накруток.sasha1024
09.07.2017 12:40Напомните, плиз, что такое WoT?
Upd.: А, вспомнил, web of trust.
AngReload
09.07.2017 17:41Кстати, об Web of Trust.
Сервисы Web of Trust оказались скомпрометированы (https://geektimes.ru/post/282406/)
andreylartsev
09.07.2017 00:49+9История показательна прежде всего тем что производители популярных браузеров могут при желании удавить любую компанию имеющую представительство в сети Интернет и ведущую бизнес в Интернет, просто потому что они большие и могут себе это позволить.
DjPhoeniX
09.07.2017 01:13+3Двоякая ситуация.
С одной стороны — StartCom облажались, спору нет. И их лажу надо как-то прекратить. И прекратили — остановили доверие к новым сертификатам (= приостановили весь бизнес), потребовали аудитов и всего-всего. Справедливо. Окей.
С другой стороны — ну хорошо, ну остановили вы негодяев. А вот дальше начинается вопрос «а в чём же виноваты легитимные получатели их услуг?» Сначала прибили всех кто не попал в топ Алексы (окей, то-есть почти всех вообще, так как топ алексы — это уже кандидат в клиенты Comodo / GoDaddy / КтоТамЕщёЕсть). Теперь хотят добить оставшихся (а они остались?)
По-моему шумиха уже улеглась, LE взлетел, но история показательна для всех. И для поставщиков «доверия» («не злоупотребляй»), и для разработчиков («бесплатный сыр и всё такое»).
Gendalph
09.07.2017 04:22+1Сертификаты скомпрометированы. Эти черти могут выпустить другой сертификат и подписать его, не отозвав оригинальный, давая возможность устроить MitM на HTTPS.
По-хорошему давно пора было забанить этот CA с такими приколами.
mxms
09.07.2017 21:20Все эти CA "черти" могут выпустить другой сертификат не отозвав оригинальный, по умыслу или случайно. И это уже было, в том числе и с "хорошими" CA. Иными словами, вся система имеет фундаментальную уязвимость, поскольку построена на доверии к сторонней организации.
dmitry_ch
09.07.2017 11:41Думаю, StartCom, так же, как и WoSign, получали множество вежливых, невежливых и всяких других намеков от браузеростроителей. И, раз уж они никак не внимали (простите за тавтологию) «последним китайским предупреждениям», дошло до такой точки. Казуистически говоря, перед пользователями все же виноваты не авторы браузеров, а CA, который, «давая зуб», что будет честным, обманул их доверие.
С другой стороны, а что Гуглу с Мозиллой было делать? Сказать «мы против обмана, но ради пользователей закроем глаза»? Тем более что и платных альтернатив хватает, и вот бесплатная, в лице LE, имеется и развивается.
Причем к последней приложили кошельки и руки многие «большие игроки», и есть какая-то надежда, что свое детище они (опосредованно, но все же) постараются держать как надо.
Aingis
09.07.2017 12:14+1С точки зрения пользователя скомпрометированный сертификат ничем не отличается от самоподписанного или даже полного отсутствия. Так что их ни за что не наказывают, лишь приводят к реальному состоянию дел.
dmitry_ch
09.07.2017 12:22Судя по вопросам Google к Symantec, в рамках наведения порядка следует ждать продолжения чистки — давайте посмотрим, оздоровит ли это ситуацию!
5m1l3
10.07.2017 17:03+2На мой взгляд, это просто борьба государств. LE сделан, чтобы анб могло без лишних проблем посмотреть что там гуляет по https нажав на спонсоров LE. А StartSSL это китай, который хотел сделать тоже самое. Напрягает во всей этой ситуации, что LE единственный такой центр сертификации, монополист имхо, что не есть правильно.
Zakyann
09.07.2017 11:33Монополия же. Ничто не ново под Луной. Хотя в данном конкретном случае скорее благо.
powerman
09.07.2017 01:22CA необходимо наказывать, причём максимально жёстко! И очень плохо, что это начинают делать только сейчас.
Сейчас на доверии CA держится почти полностью весь https (исключая редко используемые pinned сертификаты), и если CA не будут максимально серьёзно относиться к своей репутации и безопасности своей инфраструктуры — надёжность https может сильно пострадать.
Более того, я бы вообще список корневых сертификатов в браузерах сократил примерно на порядок — адекватно контролировать текущее количество должно быть очень сложно, поэтому стоит ужесточить требования к CA и отобрать корневые сертификаты у тех, кто будет не в состоянии выполнять эти требования.
alex0nik
09.07.2017 09:11Очень легко перегнуть палку между необходимым (достаточным) и избыточным. Особенно в нашей стране.
Если создать дополнительные издержки CA, за них заплатит конечный потребитель.
В свое время StartCom смогли себе позволить не брать денег за сертификаты первого уровня, которые выпускаются автоматически без участия человека. Теперь к ним нет доверия, на их место пришел Let's Encrypt. На мой взгляд это правильно, что должны быть бесплатные сертификаты, иначе это очень смахивает на продажи воздуха.Zakyann
09.07.2017 10:04+1Не совсем так. Продажа доверия всё таки, не воздуха.
dmitry_ch
09.07.2017 10:07+1Все бы хорошо, но в мире, как кажется, маловато осталось CA, которым можно доверять на том основании, что они прошли аудит и за ними не числится ни одной откровенное некорректной операции — кроме LE.
Причем, если брать именно «больших ребят», то они точно не белые и пушистые, а цены за ими выпущенные сертификаты высоки.
Так что иногда торговля доверием похожа, увы, на торговлю воздухом.Zakyann
09.07.2017 11:32Nobody's perfect. Однако стремится к этому можно и нужно.
dmitry_ch
09.07.2017 11:36Кто против? Но для завоевания доверия нужно, таки, завоевывать доверие. Вот, китайские товарищи показали, как его можно потерять в таких масштабах, что даже Мозилла с Гуглом на них обиделись. Давайте спросим уважаемых ребят из Symantec, например, что они думают по поводу повышения доверия ко всем CA, что им принадлежат?
И, да, по поводу того, что одна компания контролирует несколько CA — это как раз похоже не на создание доверия, а на уменьшение числа конкурентов на рынке, что потенциально ведет к уменьшению веры в честность.
powerman
09.07.2017 12:13Если создать дополнительные издержки CA, за них заплатит конечный потребитель.
Не обязательно. Издержки CA более-менее фиксированные (не зависят от количества выпущенных сертификатов), так что их вполне реально покрывать за счёт платных EV сертификатов для средних/крупных компаний. Кроме того, их издержки могут покрываться гигантами вроде Google или дотациями из гос.бюджета — теми, кто заинтересован в безопасном вебе.
А вот если эти дополнительные издержки на обеспечивание высокого уровня защиты и контроля не создать, то какой в этих CA вообще смысл и чем они надёжнее моего собственного CA? По хорошему, используемый код и базовая инфраструктура CA должны быть выложены в открытый доступ для проведения публичного аудита. Поверх этого ядра они могут городить любые фичи/интерфейсы, но валидация того, можно ли выдать сертификат и сама выдача должна быть реализована одинаково у всех CA, и этот код должен лежать на гитхабе.
igurylev
09.07.2017 09:54И Apple тоже. Я до недавнего времени использовал платный сертификат от StartCom (OV).
А с выходом новой бета-версии MacOS сайт превратился в тыкву. Пришлось быстро переключаться на LE.dmitry_ch
09.07.2017 13:15Правильный порядок событий: StartCom продалась китайцам, стала играть по их правилам (тем самым превратясь постепенно в тыкву — и подставляя юзеров, которые ей доверяли), браузеры эту историю заметили, и начали банить серты от такого CA, ставшего тыквой. Сайты с сертификатами от этого CA тоже сделались тыквами (спасибо, StartCom, да), и тут уж, хочешь или нет, а пришлось в LE идти, или к «платным» товарищам.
funca
09.07.2017 12:59В принципе, вся эта история наглядно показала, что разрекламированная безопасность https сводится не к шифрованию, а к дорверию.
Интересно, почему под раздачу попали именно китайские CA, а в замен по сути предложена альтернатива в виде LE из Калифорнии, у которого chrome и mozilla платиновые спонсоры?
artyums
09.07.2017 15:40+1Так любое шифрование сводится к доверию. Есть ли закладки в алгоритме шифрования? Надежен ли канал передачи ключей? Не скомпрометирован ли ключ получателем? И так далее и тому подобное.
Поэтому в рамках https даже самоподписанный сертификат является дефакто обеспечивающим безопасность, если пользователь доверяет издателю ключа (как это, например, делается в OpenVPN серверах — Ваш трафик все-таки надежно защищен на пути к и от сервера).funca
09.07.2017 18:36Как говорят немцы: доверие хорошо, а контроль еще лучше. По идее, большинство их этих рисков поддаются верификации и закрываются аудитом локальным систем. Но в случае с публичными ключами приходится доверять еще и внешним CA (и как следствие, тем, кто их контролирует). Но контролировать их, со своей стороны, практически нет ни какой возможности. Так что да, в случае частных сетей, самоподписные сетрификаты обеспечивают больший уровень контроля безопасности.
artyums
09.07.2017 18:50Так вот в том и дело, что в любом случае чему-то, но доверять надо :) А вдруг СА частной сети окажется скомпрометирован? Вот и вопрос минимум доверия к самому себе, насколько сам защитил свою сеть…
Даже есть взять какую-нибудь сверх секретную военную систему, в которой обмен информацией зашифрован, то опять же возникает вопрос доверия к людям, которые вводят ключевые данные, да и даже к тому, насколько верно разработан этот сверх секретный алгоритм. Все на принципе веры :)artyums
09.07.2017 18:57Вот к слову, известный случай, когда летчик Виктор Беленко в СССР улетел из страны на военном самолете и сел в Японии. Результатом стала компрометация системы госопознавания (тоже системы, основанной на шифровании). А ведь летчику доверяли…
funca
09.07.2017 19:51Доверять приходится, вопрос масштаба. Вот если бы летчика контролировали снаружи — из Японии, или там пентагона — это бы сильно помогло СССР? :)
andvgal
09.07.2017 13:04Вангую:
При первом заходе на сайт будет спрашиваться "Сертификат этого сайта подписан таким-то известным CA. Продолжить? Да/Нет + (флажок 'сохранить')"
При смене CA будет вопрос "Внимание, опасность! Новый сертификат сайта подписан другим CA." + #1
Чтобы не возникало проблем с внешними ресурсами, HTML будет расширен атрибутом а-ля "cert-ca" для link/script/img/etc. или же добавлен в уже рекомендованный "integrity" атрибут.
Будет глобальный платный реестр CA -аля ICANN:
4.1. Не будет препятствия в добавление, кроме денежных взносов.
4.2. Каждый участник сможет выдвигать закрепляемые в реестре обвинения с градацией по серьёзности.
4.3. Организация будет отвечать за проверку
- В случае регистрации нарушений CA, пользователи браузеров так же будут получать предупреждения об этом.
Такому вектору развития будут противодействовать, из-за очевидных создаваемых проблем спецслужбам.
dmitry_ch
09.07.2017 13:09… можно еще отказаться от слова «вангую», очень уж оно не русское.
Первые два пункта уже и сегодня есть. Заходите на сайт с самоподписанным сертификатом — именно это и увидите, примерно. Только тот же Chrome однажды стал думать, что вы «верите сертификату» не навсегда, а на время.
А если серьезно, то вот вопрос про «отвечать» очень скользкий. Перед кем отвечать, чем и как? Вот, китайские товарищи «ответили», так?
В жизни же ничего такого не будет, уверен. Тут до сих пор часть браузеров верят старым, необновленным спискам корневых сертов, а вы такую революцию…andvgal
09.07.2017 13:32Нет такого. Принятие сертификата для самоподписанного сайта != разрешение использовать конкретный заранее известный сертификат CA.
Если организация, заведующая реестром не будет справляться, то тот же Google и Mozilla смогут создать альтернативу, как например был создан Yarn вместо npm, а потом npm Inc. резко засуетились и добавили долгожданных фич.
Уже есть плагины к барузерам, но они сфокусированы на конечном сертификате и поэтому плохо подходят для работы с распределёнными сервисами вроде GMail, где одновременно используются десятки сертификатов для одного и того же домена.
funca
09.07.2017 22:36Такому вектору развития будут противодействовать, из-за очевидных создаваемых проблем спецслужбам.
Не уверен, скорее тенденция прямо противоположна. Подконтрольный MITM, сейчас является штатно поддерживаемым сценарием в системе (не-)предупреждения об атаках браузеров.
В крайних версиях google chrome, возможность посмотреть глазками на сертификат сайта хорошо запрятали. В пределах видимости остался только зеленый замочек со словом «Надежный» и сообщение, что соединение и информация надежно защищены.
Больше всего такая надежная защищенность внушает оптимизм, при серфинге через Fiddler прокси, чей self-signed сетрификат добавлен в «trusted root certificate authority» девайсов для тестирования. Этот прокси, для удобства разработки, дешифрует весь проходящий через него https и подменяет в нужных местах ответы сайтов. Заметить подвох (фактически MITM атаку) на стороне браузера можно по характеристикам сертификата, только специально покопавшись где-то во вкладках chrome dev-tools.
vitamin
09.07.2017 16:41У меня на маке Chrome 58 не даёт заходить на сайты с сертификатами WoSign. Firefox заходит.
dmitry_ch
09.07.2017 16:46Вроде как от «мачности» вашего ПК это не должно зависеть: это же поведение Chrome и Firefox, и я сомневаюсь, чтобы производители не сделали эту политику одинаковой для всех платформ.
А Chrome и FF каких версии у вас?
P.S. Хотя я тут задумался — а на каком сайте проверить, кроме wosign.com? Их-то сайт как раз могут оставить в белом списке, мало ли…vitamin
09.07.2017 17:00А вот не знаю, зависит или нет — в виндах-то всё вроде как через родной центр сертификатов сделано… и только FF юзал свой. Может и здесь всё через keychain.
Проверить можно на, например, https://xinit.ru/bs/
gaf
09.07.2017 19:09+1Я тут недавно «споткнулся» о следующую мысль. Блокчейн — это технология доверия, когда нет доверия никому конкретно. И тут я понял — этож лучше, чем грядущая проверка сертификатов через CAA-запись. CAA-запись частично решает вопрос доверия CA, но тот же CA может выпустить второй сертификат. А ведь еще есть и DNS-спуфинг.
Хранение всех выданных сертификатов в блокчейне тоже имеет свои минусы, но идея, на мой взгляд, интересная.dmitry_ch
09.07.2017 19:09Мысль интересная. Только вопрос, какой размер база сертификатов примет, и как эту технологию встроить в существующий техпроцесс работы с сертификатами?
gaf
09.07.2017 19:20Размер базы — это проблема, особенно для мобильных устройств. Впрочем, как и процедура отзыва сертификата.
Возможно, необязательно хранить всю базу локально. Ведь и сейчас при создания SSL-тунеля, в частности для проверки сертификата на отзыв, требуется обращение ко внешним ресурсам. Что если для проверки сертификатов обращаться к случайным узлам, в стиле p2p, может даже к узлам в сети onion/tor?
А для вопросов непосредственной реализации, достаточно чтобы этим заинтересовались Google и Mozilla =)funca
09.07.2017 20:08Распределенная схема с персональными сетями доверия, в целом, реализована для верификации подписей PGP, но на практике не сильно популярна из-за сложностей в использовании.
А у Google и Mozilla уже есть Let's Encrypt, который теоретически способен продуцировать аналитику — кто, когда и на какие сайты. Зачем еще какие-то заморочки?)gaf
09.07.2017 20:17+1Let's Encrypt лишь следует существующей формальной логике — цепочка до CA и пр. Для клиента нет никаких различий между выпуском сертификата от Let's Encrypt и другого CA или же двумя разлиными выпусками сертификатов от Let's Encrypt для одного и того же домена.
Вобщем все проблемы существующей инфраструктуры CA присутствуют и здесь. Идеально было бы избавиться от CA вообще.funca
09.07.2017 20:52Теоретически вы правы. Просто когда вендоры отдельного CA, которые по совместительству владеют подавляющей долей рынка браузеров и двигают технологии, так же являются его платиновыми спонсорами, это создает интересную ситуацию. Возможно, в целом, такая централизация не так уж плоха — браузеру ведь в любом случае приходится доверять. Но сам рост уровня консолидации ключевых технологий в руках отдельных корпораций впечатляет.
Странно, что более мелкие игроки на рынке браузеров, типа Яндекса, до сих пор не сделали свой домашний CA, по аналогии с LE.dmitry_ch
09.07.2017 21:17+1Яндекс как-то писал, что для своих целей они сами себе CA (искать пост не буду), так что не исключено, что они скоро появятся на рынке с идеей «нового, никому в голову не приходившего сервиса» DavayShifruy. Я был бы рад хоть одному CA в Росии, но вот как они с товарищами майорами и господами депутатами договорятся…
gaf
10.07.2017 12:01+1Не знаю, но я в своем 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)
mxms
09.07.2017 21:30+2CAA не решает вопрос доверия вообще ни разу, однако существенно ограничивает возможность выпуска сертификата неавторизованным через неё CA.
Решение на сегодня это DANE. Однако, производители прикладного софта её внедрять не спешат.
По поводу блокчейн. Я вижу, что большинство вообще не понимает что это, для чего её целесообразно использовать и, тем более, как он работает. В большинстве случаев, в частности и этом, блокчейн не нужен, поскольку вполне достаточно куда менее сложных и затратных способов реализации. Это, к примеру, цифровые подписи которые с успехов функционируют в рамках даже такой не слишком складно спроектированной системы, как DNSSEC.andvgal
09.07.2017 23:45Любой кейс с наличием вменённой доверенной части не решает проблему.
Единственное решение — это когда для каждого конкретного сервиса пользователь сам сможет выбирать/подтверждать "корни доверия", от которых уже далее выстраивается и проверка имён, и установка защищённого соединения, и проверка содержимого, и т.д.
Для обывателя это мало чего даст, но в режиме параноика другого пути нет.
В условиях противодействия разработчиков сложного клиентского ПО, дельным решением может быть собственный локальный системный MITM-proxy, который будет выполнять требуемые проверки независимо с удобством для пользователя. Пример выше.
Такой путь уже реализуется в коммерческих продуктах, но с известными нареканиями, ибо защищает не конечного пользователя, а внутреннюю сеть компании.
mxms
10.07.2017 17:23Любой кейс с наличием вменённой доверенной части не решает проблему.
Ну я бы не был так категоричен. Например, DNSSEС имеет таковую, однако используя DANE вопрос с доверием к сертификату вполне себе решается.
TaHKucT
10.07.2017 10:00Блокчейн в его классическом (биткоиновском) понимании тут не нужен, я не хочу что бы «завтра» «плохие люди», купив за 100$ (1000-10,000-не важно сколько) немного мощностей на амазоне(azure, google cloud, etc), построили альтернативную ветку этого блокчейна, выкинув «мой» сертификат в утиль и подставив туда свой.
В остальном идея правильная, и уже реализованная, смотрите RFC 6962, оно же Certificate Transparency оно же на Хабре.
Осталось ни так много: набрать критическую массу и выкинуть из основных браузеров поддержку тех CA, которые не начали играть по этим правилам (читайте: перестать принимать сертификаты, которых нет в данном логе).
Это конечно в корне не решит проблему «приходиться доверять какому-то непонятному дяде», но как минимум даст «технический» инструмент намного быстрей выявлять недобросовестных «дядь» и применять к ним административные меры.
Ну а для решения проблемы «хранения данного лога на устройстве» уже придумали OCSP, только к сожалению он не работает как надо.gaf
10.07.2017 11:56Безопасность проще переводить в деньги, чтобы было понятно что является эффективным, что — нет. Это как гаечный ключ за 10$. Всегда можно дать админу на лапу или шантажировать его, чтобы получить сертификат. Сертификаты «ломают» и будут «ломать» всегда. В конечном счете, можно взломать вебсервер и вытащить ключ от туда (у мнгоих ли он запаролен?).
Я говорю не об этом. Мне приятней думать, что есть какая-то надежда на децентрализацию в вопросе доверия сертификатов. Что мы доверяем архитектуре/алгоритму/модели, нежели чем вот этим вот 3-5 организациям.
С новыми расширениями сертификатов тоже есть сложности. Есть (и всегда будет) старое ПО. Хотим мы или не хотим, но вопрос внедрения не может не занять множество лет. Я до сих пор в работе сталкиваюсь с Cisco PIX, редко, но сталкиваюсь. Так вот настройка этого «чуда» через браузер требует совсем старую JAVA и IE. Или вот, пример поближе VSphere 5.5 — вышел чуть меньше 4 лет назад, но требует Flash, который как мы знаем «выпиливается» из браузеров. С предлагаемыми расширениями, получится все тоже что и со всеми предыдущими — кто-то реализует, кто-то нет, кто-то реализует по своему. Это как внедрить очередной, 15-ый стандарт, который наконец объеденит все предыдущие (да, снова отсылка к Ренделу =) ). На мой взгляд, тут может сработать только принципиально новая идея (необязательно про блокчейн).
Marwin
пользовался раньше… но теперь это уже не важно. С тех пор как LE обещал сделать wildcard со след года — всё стало не важно
dmitry_ch
Да, раньше многие пользовались. Более того, многие оплачивали у StartCom платные аккаунты (точнее, проходили платную проверку), тем самым формирую и себе лучшие условия, и проект подпитывая. Как так они умудрились удавить
коровукурицу, приносившую золотые яйца?vorphalack
китайцы. насколько я слышал, они не работают на репутацию и долгосрочные перспективы. схватить и бежать, короче. и желательно ночью.
artyums
Вот действительно :) Благодарю этот случай за то, что наконец-то нашел желание и силы разобраться с Let's Encrypt. Теперь только захожу иногда, проверяю как сертификаты обновляются сами собой. И главное, что не забудешь через год это сделать вручную, как в случае с WoSign было у меня раньше пару раз…
dmitry_ch
Насчет обновления согласен полностью. Знаю людей, которые покупали платные сертификаты на несколько лет сразу не из-за цены (она уменьшалась при оплате, скажем, на 3 года вперед), а чтобы просто менять их в системе раз в 3 года, а не каждый год.
CA то выписывал такие сертификаты. Но то, что серт истечет через большее время, заодно влияет на шанс его быть скомпроментированным за это время — собственно, потому LE и сделали 3 месяца. Причем, коммерческие CA по поводу автообновления вроде не очень согласны, или я плохо искал? Но, даже если оно и есть, многие просто ленятся его настроить, и руками (да-да, желательно пореже) обновляются.
А с LE, хочешь или нет, а отладишь раз автообновление (раз в 3 месяца бегать и ручками заниматься — это уже перебор), и дальше уже живешь отлично!
0xd34df00d
Только непонятно, как с xmpp их подружить.
dmitry_ch
C xmpp либо самоподписанный, либо скриптом (я делал, но там возникает проблема — надо бы, чтобы еще и клиенты верили LE-ному серту; старые версии PSi не верят), либо, да, купить domain-validated сертификат за чуть меньше чем $13 на три года (опять надо смотреть, чтобы клиенты такое приняли), и ну его нафиг со скриптом бороться, проще раз в 3 года руками обновить.
VGusev2007
На три года, получил бесплатный серт от StartSSL. Pidgin доверяет. С новых версий он и LE должен доверять, но мне лень рестартовать ejabberd так часто.
artyums
Интересно, можете мне предложить какое-нибудь применение xmpp, которое требовало бы сертификат, полученный от доверенного публичного СА? То есть такое, для которого не подходит самоподписанный сертификат? Не могу придумать, любой же Jabber сейчас — это такая сеть, внутреннего характера.
dmitry_ch
Признаться, кроме того момента, что xmpp-клиент сообщит юзеру при первом подключении, что сертификат ему неизвестен и проверить он его не может — нет. Да и то, в настойках многих клиентов ест галочка «принимать самоподписанные сертификаты»
Но — если так, то и MITM можно пропустить. Т.е. по уму все же даже сертификат своего самопального CA неплохо на машинах клиентов заранее принять, а упомянутую галочку не ставить.
Но это все от того, зачем вам серт. Шифрование есть — этого многих хватает, чтобы не передавать общение с сервером открытым текстом даже по локалки, а MITM не всех актуально бояться.