Pull to refresh

Comments 94

Астрологи объявили неделю поддельных сертификатов на Хабре.
Количество сертификатов для google.com удвоилось
При таком раскладе их бизнес как CA может легко вылететь в трубу.
Бизнес CA планируется к вылету в трубу после запуска Let's Encrypt. После которого какого-либо смысла в платных сертификатах не станет.
Скорее часть бизнеса. Let's Encrypt же документы не проверяет, только доступ к серверу (который можно увести на время). Соответственно, везде, где сертификат должен быть верифицирован (где есть финансовые операции, например), а не просто быть, CA всё ещё будут нужны.
Ну да. Я просто всегда офигевал с того, как домены и сертификаты «приватизировали» внезапным образом. Причём, если домены ещё более-менее терпимо (делегация и делай что хочешь), то сертификаты оказались покрыты таким слоем «дайбабла», что просто жуть.
«приватизировали» внезапным образом
Вы о чём? Вас смущает, что вендоры OS не спешат включать в свой встроенный список доверенных CA корневые сертификаты выпущенные какой-нибудь безымянной обезьяной не имеющей представления о том, что такое «соответствие стандартам безопасности» и которая завтра спалит ключ от своего CA или навыпускает фейковых сертификатов и скомпрометирует всю идею удостоверяющих центров?
«уважаемые» СА периодически компрометируют всю идею удостоверяющих центров, однако ни к каким результатам это пока не приводит.
Пруфы? В любом случае это говорит лишь о том, что требования к CA и их ответственность должны лишь повышаться, что автоматически означает лишь удорожание услуги, а не наоборот
Пруфы:
www.opennet.ru/opennews/art.shtml?num=38613
www.opennet.ru/opennews/art.shtml?num=31635
www.opennet.ru/opennews/art.shtml?num=35754
www.opennet.ru/opennews/art.shtml?num=41902

Еще пруф: кнопочку 'Home' на клавиатуре нажмите

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

Это говорит о том, что текущая система постоянно фэйлит возложенные на нее задачи в силу неправильной архитектуры, и тут скорей нужно менять весь механизм «доверия к сайту», чем повышать требования к СА
www.opennet.ru/opennews/art.shtml?num=38613
Это скорее антипруф. Их SubCA спалили и на сколько я понял выкинули как минимум из браузеров. Система работает. Или вы ждали что там всех арестуют? Да и вообще, приводить SubCA французских чекистов как пример «уважаемого CA» не корректно

Это говорит о том, что текущая система постоянно фэйлит возложенные на нее задачи в силу неправильной архитектуры
Система развивается постоянно
Это скорее антипруф. Их SubCA спалили и на сколько я понял выкинули как минимум из браузеров. Система работает. Или вы ждали что там всех арестуют? Да и вообще, приводить французских чекистов как пример «уважаемого CA» не корректно

Мы видимо по разному смотрим на это. Я считаю что это показание несостоятельности работы системы сертификатов и борьба с последствиями. А поскольку мы тут о технических средствах говорим, то они должны предотвращать возможность неправомерного выпуска сертификата (в текущей терминалогии). Для «борьбы с последствиями» есть законы.
Если честно, лучше бы вендоры ОС вообще никакие сертификаты не включали. Пусть эти «дайбабла» занимаются внедрением своих сертификатов конечным пользователям самостоятельно. Либо хотя бы пусть как-то делятся баблом с вендорами ОС.

Я не готов доверять условному тхавте лишь на том основании, что ему доверяет условный мокросовт или условный каноникал.
И как вы видите себе алгоритм выбора CA каждым отдельно взятым юзером? На основание чего они должны делать выбор?
Не понял, с какой стати пользователь будет выбирать? Наоборот, это CA будут просто носиться ещё хлеще, чем сейчас предвыборные кандидаты со своими подписями. Домой приходить будут, «установите себе наш корневой сертификат, нупожааааааулйста, мы вам конфеток дадим».
Все CA сейчас подписывают свои корневые сертификаты другими корневыми. Достаточно установить один общепризнанно доверенный, а он уже подпишет все остальные. Этот общепризнанно доверенный назовут CA/B Forum Root Certificate и ничего не изменится.
Приведите пример, чем подписан C=US/O=Equifax/OU=Equifax Secure Certificate Authority, серийный номер 35:DE:F4:CF? Каким «другим корневым» он подписан?

И второе, значит появится один настоящий корнень доверия, а не куча, как сейчас. Это большой прогресс, особенно, если его использование тоже будет жёстко регламентировано.
Equifax — ничем, потому что он гарантированно есть на всех старых машинах. Зато им, как минимум, подписаны GeoTrust'овые корневые сертификаты.
Не понял, с какой стати пользователь будет выбирать? Наоборот, это CA будут просто носиться ещё хлеще, чем сейчас предвыборные кандидаты со своими подписями. Домой приходить будут, «установите себе наш корневой сертификат, нупожааааааулйста, мы вам конфеток дадим».
Ну вот я и спрашиваю, чем кроме маркетингового булшита прикажете руководствоваться юзеру? Вендор OS хотя бы рискует своей репутацией если поместит в список доверенных CA всякий ахтунг, так как в этом случае юзеры данной OS будут подвергаться SSL MITM атакам. Поэтому он заинтересован контролировать соответствие CA профильным нормам компьютерной безопасности, предъявляемых к CA. Вы не предложили альтернативы.
А чем сейчас он руководствуется, вендор лок-ином? Чем это лучше маркетингового буллшита?

О какой угрозе репутации речь? Вон, винда 10 следит за пользователями даже если попытаться повыключать все фишки слежения, и что, это как-то сказалось на репутации мокросовт? Вижу пару выкриков и тишину. Даже люди, которые «в курсе» — повозмущались, «как так», и забыли, смело пользуются десяткой дальше.

Выше был список примеров, нелегально выпущенные различными ЦС сертификаты для Google. Например, там был TurkTrust. При этом, этот сертификат центр сертификации был установлен в ванильном файерфоксе (был валиден до марта 2015). Его вроде как исключили после того инцидента, но временно и потом вернули. Да и потому, ну исключили, И ЧТО? Как это повлияло на пользователей, которые уже установили его и не обновляются, но пользуются интернетом здесь и сейчас?

Альтернатива, в общем-то, одна: доверять только тем ЦС, чьи корневые сертификаты я установил в браузер сам и получил надёжным путём (ну или мой сисадмин, если я на работе, и здесь речь не о моём личном доверии к ЦС, а доверии моей организации). В противном случае я вижу корневой сертификат и «а хрен его знает, откуда он здесь взялся, поставился с браузером, браузер качали по http, может, по дороге подсунули».

Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?
ну исключили, И ЧТО?
другим урок, «потеряете деньги»

не обновляются, но пользуются интернетом здесь и сейчас?
ССЗБ

и получил надёжным путём
вот тут возникает много вопросов, как определить надежность

ну или мой сисадмин, если я на работе

Наши «сисадмины» через AD распространяют корпоративные корневые сертификаты и включают на проксе (вообще не стесняясь) опцию SSL Inspection (политкорректное название MITM)

Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?
Вы так говорите, как будто это я вам предлагаю откуда попало корневые сертификаты качать. Я как раз таки против.
доверять только тем ЦС, чьи корневые сертификаты я установил в браузер сам

Но вы же все равно установите себе корневые Thawte, GeoTrust и прочие. Без них многие сайты у вас будут ругаться на ошибку сертификата.
И никто не даст вам гарантий, что УЦ, которые в вашей системе будут доверенными не накосячут так же или даже хуже.
Производители ОС и браузеров руководствуются CP/CPS, авторитетом УЦ и аудиторских компаний, которые принимают участие в создании и контроле УЦ.

Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?

Я года 4 назад настраивал клиент-банк Казахского Сбербанка. Там аналогичная ситуация: скачайте сертификат по ссылке … Звонил и объяснял им, что так нельзя. Пропадает весь смысл доверия. Кое как уговорил продиктовать мне отпечаток сертификата, который они считают правильным.
В итоге, через несколько месяцев у сертификата истек срок действия. Техпод на голубом глазу говорили мне, что надо просто игнорировать ошибку в браузере.
Все мои заверения, что это вообще ни в какие ворота остались неуслышанными.
Но вы же все равно установите себе корневые Thawte, GeoTrust и прочие. Без них многие сайты у вас будут ругаться на ошибку сертификата.

Хе-хе. А сейчас не ругаются и дают мне и семи миллиардам человек в мире ощущение ложной безопасности. Разъясните мне чем отличается: я нажал в ошибке кнопку «игнорировать» и я доверяю сертификату, образовавшемуся у меня в браузере самопроизвольно после скачивания его по http.

Вообще идеальный вариант c учётом вот этого кошмарного зоопарка легаси ЦС — аналог EV средствами браузера. Если я установил сертификат, отображать его как особо доверенный. Если не я установил — не отображать.
Что вам мешает на себе проверить предложенную модель? Удалите все доверенные УЦ из настроек браузера или ОС. Затем добавляйте те, которые считаете надежными.
Конечно. Смысла только мало — я не доверяю по умолчанию тому, что у меня подлинный сертификат GeoTrust, а средств сверки отпечатка сертификата GeoTrust не предлагает. В общем, все сайты станут недоверенными и всё. Ничего нового я не увижу, для себя я и сам знаю, что система порочна.

Чтобы это имело смысл, это должно стать массовым движением. Если треть пользователей интернета откажутся доверять дефолтным CA, они зашевелятся и будут что-то делать. А для этого нужно, чтобы сертификаты не включались в браузер по умолчанию.
Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка).

CRL и CDP размещают по HTTP для избежания зацикливаний, а вы можете позвонить в Сбербанк и спросить серийный номер.

Подписи организаций так и подтверждают — бумажкой с серийником, подписью ответственного и печатью.
CRL сам по себе — подписанная штука. Его можно размещать как угодно, при условии, что он доступен и у клиента уже есть корневой сертификат. Доверие к CRL возникает на основании доверия к корневому сертификату, которым он подписан. Там внутри и время есть для ограничения срока валидности, так что просто старый CRL подсунуть не покатит.

Про позвонить — оно конечно можно, но ни намёка в инструкции на это не было. Но в данном случае это ещё и нерационально — сотрудник ХОДИЛ В БАНК НОГАМИ С ФЛЕШКОЙ для выпуска своего сертификата; что мешало ему сразу же передать и корневой из рук в руки?
Нашли где искать хороший сервис. АБ требовал (!) директору идти в отделение для замены ключа, которые они зами забыли подписать при замене. Ситуация разрешилась после звонка разъяренного главбуха нашему аккаунту (или как это называется в банке).
Там где надо, составляют свои списки.
Я сталкивался с блокировкой корневого CA StartCom в банках — у местных идиотов припекло из-за бесплатных сертификатов, но заблокировать только Class 1 они не догадались.
Я о том, что я не могу поднять свой собственный ssl-сервер, который у пользователей будет нормально работать, не забашляв денег.

Если бы я эту штуку делал, то сертификаты были бы намертво завязаны на владельца домена. Кого домен, того и тапки сертификаты.
Вы сейчас описали обычный самоподписанный сертификат, но не предложили безопасного механизма получения своего корневого сертификата на компы клиентов. Вся проблема то в том, что такого механизма нет.
Так оно само от DNSSEC зависит
Да, он в данном случае выступает в роли ЦС. DNSSEC в свою очередь связан непосредствнно с администратором домена. В общем, случай именно тот, как описал amarao — раз я владею доменом, то могу настроить и DNSSEC-записи для него без дополнительных костылей и левых ЦС. Я доказываю свою личность тому же, у кого регистрировал домен, а не кому-то ещё, делаю это один раз и после этого могу делать с доменом что угодно. В том числе совершенно самостоятельно накручивать DNSSEC для любых поддоменов любого уровня, и получать для них работающий SSL, что сейчас с ЦС невозможно — wildcard действует в пределах одного уровня поддомена.

(Разумеется, условие «DNSSEC поддерживается клиентами, серверами, и зоной» остаётся, куда без этого.)
DNSSEC «покупается» вместе с доменом. Вся разница в том, что вместо 3х записей регистратор добавляет 4.
Не «само» подписанный, а подписанный ключом, опубликованным в DNS, за достоверность которого отвечает регистратор.
Таким образом, если я решу вам устроить SSL MITM мне надо будет расковырять не УЦ верисайна, а всего лишь какого-то криворукого «регистратора». Вы считаете, что при таком подходе мир станет лучше?
Верисайн прекрасно может быть регистратором.

Фактически, у нас две иерархии: одна отвечает за соответствие домена и IP, а вторая отвечает за соответствие «домена и владельца».

Я бы даже сказал, что «всё ок», если бы PKI (в том виде как оно используется) позволяло людям подписывать любые поддомены себе самим. Примерно как с делегацией доменов.

Но этого нет. Вместо этого есть либо звезда, либо покупной сертификат на каждый чих. Звезда небезопасно (у меня какой-нибудь lab-4.desunote.ru показывает сертификат от desunote.ru, и если его ломают, то утыривают сертификат), а на каждую лабу по сертификату не напасёшься). Именно это я и имел в виду, когда говорил про слишком много «дайбабла».

Алсо, я не видел случаев, чтобы кто-то «расковыривал криворуких регистраторов» у google или microsoft.

Хочешь дешёвый домен для мелочи — пожалуйста. Хочешь задорого и чтобы никаких «расковыренных криворуких регистраторов» — такие тоже есть, для VIP-доменов, типа brandnames.com.

Зачем тут ещё отдельная иерархия с сертфикатами? Чем расковыренный турктелеком-CA отличается от расковыренного турктелеком-REG?
Нет, чтобы устроить митм не нужно расковыривать верисайн. Достаточно расковырять абсолютно любой ЦС, доверенный у клиента, а их сотни. Какой-нибудь голимый турктраст может выпустить сертификат с любым доменным именем, и даже добавит туда флажок EV если захочет.

А вот с dnssec выбора гораздо меньше — ломать регистратора и всё, варианты кончились. А возможностей для владельца домена он предоставляет больше.

Целевая атака на любой доверенный УЦ обойдётся куда как дороже целевой атаки на любого регистратора, а вреда от периодических факапов с доверенными УЦ имхо меньше, т.к. они как правило не целевые а глобальные и быстро палятся в отличие от целевых. ИМХО, в общем, доверенные УЦ — наименьшее зло
По поводу DANE: скорее всего регистраторы будут использовать те же самые доверенные УЦ и по сути ту же самую модель доверия.
скорее всего регистраторы будут использовать те же самые доверенные УЦ и по сути ту же самую модель доверия

Вы случайно это написали?

В случае с традиционной схемой какой-то, случайно выбранный CA подписывает мне сертификат для моего домена my-home.ru и какого-то ограниченного количества поддоменов — например, конкретного списка или все в пределах одного уровня *.my-home.ru. Заметьте, что здесь * не может содержать точек, и sub.sub.sub я так просто сделать не могу. Также я не могу в этом случае делегировать управление серверами субдоменов подразделениям — у меня всё-таки один сертификат и один ключ, который я не могу им отдать. Мало этого, по ошибке или по злому умыслу любой другой CA может подписать кому-то другому сертификат для этого же домена my-home.ru. Сейчас появляется расширение, благодаря которому, если это была ошибка, я хотя бы смогу узнать о выпуске такого сертификата — Certificate Transaprency. Тем не менее, это костыль и он ничего не гарантирует — если это был злой умысел, тот второй CA может вообще никого о выпуске не уведомлять и соответственно я об этом ничего не узнаю.
И более того, это случается, примеры приведены выше. И нет, ls1, это как раз были целевые атаки. Вряд ли кто-то случайно выпускал левые сертификаты для google.

У DNSSEC модель сходная, но другая. Здесь, в отличие от традиционных CA, корень строго один — подписанная корневая зона, сертификат которой хранятся на клиенте и единственный безусловно доверяется. Вся цепочка выстраивается параллельно цепочке DNS, т.е. ru подписано корневым доменом. и управляется РосНИИРОС, my-home.ru пописано ru и управляется мной, а кем и как управляется каждый конкретный поддомен sub.my-home.ru и sub.sub.sub.my-home.ru уже решаю я, мне делегирован полный контроль над любыми выкрутасами. Каждый поддомен получает (или не получает, если я так захочу) свою собственную подпись. Пока я владею доменом my-home.ru (то есть, пока ns указывают на меня и мои ключи подписаны в зоне ru), никто, кроме меня не сможет подписать поддомен sub.my-home.ru или сделать какие-либо другие изменения в рамках моего домена. Кажется, я даже могу указать, что все сертификаты в этом дереве могут быть выпущены только определённым CA (хотя бы своим собственным) и буду вообще контроллировать любое использование глобально распознаваеомого SSL в рамках своего домена. Никто не мешает использовать эту систему вместе с традиционной: я смогу указать что для какого-то имени CA — Thawte, получить у них EV-сертификат и у меня будет EV, а сертификаты условного TurkTrust будут заведомо признаны невалидными на основании информации в DNSSEC, даже если сам по себе сертификат валиден.

Более того, поскольку в зоне ru есть подпись моего сертификата и она сама тоже подписана корневым, который в свою очередь есть на клиенте, никто из людей посередине не сможет сделать вид, будто бы у меня не настроены DNSSEC. Сам факт того, что мой домен имеет и использует подписи, также подписан. Никакого downgrade.

А самое интересное, что мне для всего этого нужно только настроить систему DNSSEC для своего домена под своим контролем. Мне не нужно идти на поклон к каким-то CA, проходить дополнительные проверки и так далее.
Пожалуйста, превратите ваш комментарий в статью. С сравнением моделей доверия, руководством по установке и данными по поддержке ОС, браузерами, УЦ и регистраторами. Мне очень нравится идея DNSSEC, так, как вы её сейчас описали.
Целевая атака на любой доверенный УЦ обойдётся куда как дороже целевой атаки на любого регистратора

Это с какой стати?
Нет, можно ещё днс у юзера в роутере поломать. Благо прошивки SOHO роутеров почти никто не обновляет.
Если ключ корневой зоны будет известен DNS-клиенту — взлом роутера не поможет.
Прелесть DNSSEC в том, что если зона подписана, кривой DNS-сервер вызовет максимум DoS, но не MitM. Клиент будет видеть, что подписи невалидны или отсутствуют, хотя должны, а пользователь увидит просто «не работает».
У startssl все очень и очень упорото сделано. И не для человеков.

Сейчас китайский wo-sign дает сертификат на произвольное количество доменов и поддоменов (относительно поста на хабре они сделали удобную английскую форму для этого дела), да и Let's encrypt на подхоже
Что конктерно у startssl не для человеков? Как-то я бы китайскому центру сертификации не доверял бы в прицнипе.
Сертификаты для входа, которые истекают по дате без каких-либо предупреждений. И логин по ним, принципиально не работающий. И процедура восстановления доступа в виде «зарегистрируйтесь с другой почты, напишите нам в техподдержку и мы вам перенесем домены».

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

Какая разница, кто подписывает собственноручно сгенерированный сертификат?

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

И вообще, для УЦ выпустить сертификат для домена без ведома владельца, да еще и злонамеренно — подписать себе смертный приговор. Весь бизнес УЦ держится на доверии к этим УЦ, поэтому они на это не пойдут.
Certificate Transparency, как я понимаю, вещь для CA добровольная. Захотят — и не напишут о том, что свой сертификат тайком выпустили.
Только браузеры со временем могут начать помечать такие сертификаты недостаточно зелёными.
Информация ваша уже не верна — в этом году меня по почте предупредили достаточно заранее (за 2-3 недели) об истечении сертификатов. В прощлом году же да — я сам пролетел и учётку профукал.
сертификаты для входа — это очень круто, вот бы все так делали. Например, если к браузеру добавить crypto token api, мы сразу же сможем логиниться в их сервис по токену
например, я не могу получить на startssl сертификат для домена .tk
UFO just landed and posted this here
А главное, что Symantec в принципе не выпускает сертификаты для Google. Сертификаты для Google выпускает в основном GeoTrust. Поэтому непонятно, как вообще они могли такое тестировать
При проверке пингом многие пишут то, что первое придёт в голову — ping google.com. Видимо, здесь такая же история :)
Ведь у них есть symantec.com, который по идее более очевиден для компании с названием Symantec.
Да ещё и руку меньше по клавиатуре двигать. Две буквы «о» подряд идут.
xxx: Как поиск так гугл, а как пинговать так яндекс.
ping 8.8.8.8 — что может быть короче и лучше запоминается чем четыре восьмерки в ряд?
127.0.0.1 конечно же. Он ведь ближе.
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.067 ms
127.1 объясните, откуда взялось? И о каком «большинстве случаев» речь? Циска это поймёт как 0.0.127.1, и сами понимаете, работать не должно

вот ping 2130706433 в линуксе — работает. Но число длинное и на первый взгляд непонятно, откуда взялось. А можно ещё ping 134744072 :)
В ipv6 вы можете опустить «первую группы идущих подряд нулей» (вместо ':0000:' поставить просто '::', в ipv4 тоже аналогично.
192.168.0.1 => 192.168.0.1
192.168.1 => 192.168.0.1
192.1 => 192.0.0.1

вот ping 2130706433 в линуксе — работает

и ping 0x8.0x8.0x8.0x8 тоже работает
Symantec, Thawte, GeoTrust и RapidSSL — одна и та же организация
UFO just landed and posted this here
О как! А где про это почитать можно?
Проще всего в википедии
А ничего, что Symantec, Thawte и GeoTrust это все одна компания?
В оригинальной новости не сказано, что Symantec выпустил сертификат. Сказано, что в лог выпуска ev-сертификатов попала запись о намерении выпустить сертификат. Если это правда было тестирование какой-то функциональности, то из одного совсем не следует другое.
А в банлист хрома гугл добавило намерение выпустить сертификат.
Добавило серийник и отпечаток ключа, полученные из намерения.
UFO just landed and posted this here
И внутри Symantec потестировали сертификаты, и Certificate Transparency протестировали.
Забыли написать что людей которые так прокололись, выкинули из Symantec.
Уважаемый nmk2002, раз уж вы решились та такой ответственный шаг, как recovery mode, можно было и подготовиться. Прочитать не только желтую прессу и совершенно неинформативный блог Гугла. Можно было почитать обсуждения на Reddit, Slashdot или Hacker News и разобраться в вопросе. Можно было объяснить нам, что же на самом деле произошло, а не вводить в заблуждение заголовком «Symantec самовольно выпустил сертификат для google.com», не соответствующим действительности. Можно было рассказать всем, что такое Certificate Transparency, как оно работает и зачем оно нужно.

А так ценность вашего поста для сообщества не нулевая, а отрицательная. Я оценил вашу попытку recovery как неудачную. Но вы еще можете что-то исправить.
Certificate Transperency — хорошая тема, заслуживающая отдельного поста. Если я решусь написать на эту тему, то определенно будет более познавательно.
Напишите — это интересно.
Sign up to leave a comment.

Articles

Change theme settings