Сертификат был выпущен 14 сентября примерно в 19:20 (GMT) удостоверяющим центром Thawte (принадлежит компании Symantec) без разрешения или запроса со стороны Google. Причем не простой сертификат, а Extended Validation (EV). Таким образом, это первый зафиксированный случай нелегального выпуска EV сертификата.
Выпуск сертификата, по заверению Symantec, произошел в результате внутреннего тестирования. Срок действия выпущенного сертификата 1 день. Тем не менее, Google уже включил его в список отозванных для своего браузера Chrome. К тому же Google не видит причин полагать, что пользователи подверглись риску в результате этого инцидента.
Примечательно также, что сертификат был обнаружен при помощи относительно нового механизма — Certificate Transparency. Эта технология была специально разработана для того, чтобы любой владелец домена мог узнать, какие сертификаты выпущены для его домена и, соответственно, обнаружить мошеннические. Благодаря Certificate Transparency информация обо всех выпущенных удостоверяющим центром сертификатах попадает в открытый лог. Производя мониторинг этого лога, можно обнаружить выпущенные для вашего домена сертификаты.
Описанный случай — первое обнаружение неавторизованного выпуска сертификата при помощи Certificate Transparency.
UPD1. Комментарий Symantec (отсюда).
Мы узнали в среду, что небольшое количество тестовых сертификатов было некорректно выпущено для внутреннего пользования во время тестирования.
Все из этих тестовых сертификатов и ключей были все время под нашим контролем и были незамедлительно отозваны, когда мы узнали о проблеме. Не было никакого воздействия на какие-либо домены и никакой опасности для сети Интернет.
UPD2. В том же комментарии Symantec указано, что сотрудники, нарушившие политики и допустившие данный инцидент были уволены.
Комментарии (92)
Deamhan
23.09.2015 20:31+1При таком раскладе их бизнес как CA может легко вылететь в трубу.
amarao
23.09.2015 20:33+3Бизнес CA планируется к вылету в трубу после запуска Let's Encrypt. После которого какого-либо смысла в платных сертификатах не станет.
xaizek
23.09.2015 20:53+6Скорее часть бизнеса. Let's Encrypt же документы не проверяет, только доступ к серверу (который можно увести на время). Соответственно, везде, где сертификат должен быть верифицирован (где есть финансовые операции, например), а не просто быть, CA всё ещё будут нужны.
amarao
23.09.2015 21:33+13Ну да. Я просто всегда офигевал с того, как домены и сертификаты «приватизировали» внезапным образом. Причём, если домены ещё более-менее терпимо (делегация и делай что хочешь), то сертификаты оказались покрыты таким слоем «дайбабла», что просто жуть.
ls1
24.09.2015 05:35-1«приватизировали» внезапным образом
Вы о чём? Вас смущает, что вендоры OS не спешат включать в свой встроенный список доверенных CA корневые сертификаты выпущенные какой-нибудь безымянной обезьяной не имеющей представления о том, что такое «соответствие стандартам безопасности» и которая завтра спалит ключ от своего CA или навыпускает фейковых сертификатов и скомпрометирует всю идею удостоверяющих центров?
TaHKucT
24.09.2015 09:59+4«уважаемые» СА периодически компрометируют всю идею удостоверяющих центров, однако ни к каким результатам это пока не приводит.
ls1
24.09.2015 10:12-1Пруфы? В любом случае это говорит лишь о том, что требования к CA и их ответственность должны лишь повышаться, что автоматически означает лишь удорожание услуги, а не наоборот
TaHKucT
24.09.2015 10:24+10Пруфы:
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 и их ответственность должны лишь повышаться, что автоматически означает лишь удорожание услуги, а не наоборот
Это говорит о том, что текущая система постоянно фэйлит возложенные на нее задачи в силу неправильной архитектуры, и тут скорей нужно менять весь механизм «доверия к сайту», чем повышать требования к САls1
24.09.2015 10:48-4www.opennet.ru/opennews/art.shtml?num=38613
Это скорее антипруф. Их SubCA спалили и на сколько я понял выкинули как минимум из браузеров. Система работает. Или вы ждали что там всех арестуют? Да и вообще, приводить SubCA французских чекистов как пример «уважаемого CA» не корректно
Это говорит о том, что текущая система постоянно фэйлит возложенные на нее задачи в силу неправильной архитектуры
Система развивается постоянноTaHKucT
24.09.2015 10:59+2Это скорее антипруф. Их SubCA спалили и на сколько я понял выкинули как минимум из браузеров. Система работает. Или вы ждали что там всех арестуют? Да и вообще, приводить французских чекистов как пример «уважаемого CA» не корректно
Мы видимо по разному смотрим на это. Я считаю что это показание несостоятельности работы системы сертификатов и борьба с последствиями. А поскольку мы тут о технических средствах говорим, то они должны предотвращать возможность неправомерного выпуска сертификата (в текущей терминалогии). Для «борьбы с последствиями» есть законы.
merlin-vrn
24.09.2015 10:15-1Если честно, лучше бы вендоры ОС вообще никакие сертификаты не включали. Пусть эти «дайбабла» занимаются внедрением своих сертификатов конечным пользователям самостоятельно. Либо хотя бы пусть как-то делятся баблом с вендорами ОС.
Я не готов доверять условному тхавте лишь на том основании, что ему доверяет условный мокросовт или условный каноникал.ls1
24.09.2015 10:22+2И как вы видите себе алгоритм выбора CA каждым отдельно взятым юзером? На основание чего они должны делать выбор?
merlin-vrn
24.09.2015 10:26Не понял, с какой стати пользователь будет выбирать? Наоборот, это CA будут просто носиться ещё хлеще, чем сейчас предвыборные кандидаты со своими подписями. Домой приходить будут, «установите себе наш корневой сертификат, нупожааааааулйста, мы вам конфеток дадим».
borisko
24.09.2015 10:37-2Все CA сейчас подписывают свои корневые сертификаты другими корневыми. Достаточно установить один общепризнанно доверенный, а он уже подпишет все остальные. Этот общепризнанно доверенный назовут CA/B Forum Root Certificate и ничего не изменится.
merlin-vrn
24.09.2015 10:43+1Приведите пример, чем подписан C=US/O=Equifax/OU=Equifax Secure Certificate Authority, серийный номер 35:DE:F4:CF? Каким «другим корневым» он подписан?
И второе, значит появится один настоящий корнень доверия, а не куча, как сейчас. Это большой прогресс, особенно, если его использование тоже будет жёстко регламентировано.borisko
24.09.2015 10:51+2Equifax — ничем, потому что он гарантированно есть на всех старых машинах. Зато им, как минимум, подписаны GeoTrust'овые корневые сертификаты.
ls1
24.09.2015 10:59+2Не понял, с какой стати пользователь будет выбирать? Наоборот, это CA будут просто носиться ещё хлеще, чем сейчас предвыборные кандидаты со своими подписями. Домой приходить будут, «установите себе наш корневой сертификат, нупожааааааулйста, мы вам конфеток дадим».
Ну вот я и спрашиваю, чем кроме маркетингового булшита прикажете руководствоваться юзеру? Вендор OS хотя бы рискует своей репутацией если поместит в список доверенных CA всякий ахтунг, так как в этом случае юзеры данной OS будут подвергаться SSL MITM атакам. Поэтому он заинтересован контролировать соответствие CA профильным нормам компьютерной безопасности, предъявляемых к CA. Вы не предложили альтернативы.merlin-vrn
24.09.2015 11:20А чем сейчас он руководствуется, вендор лок-ином? Чем это лучше маркетингового буллшита?
О какой угрозе репутации речь? Вон, винда 10 следит за пользователями даже если попытаться повыключать все фишки слежения, и что, это как-то сказалось на репутации мокросовт? Вижу пару выкриков и тишину. Даже люди, которые «в курсе» — повозмущались, «как так», и забыли, смело пользуются десяткой дальше.
Выше был список примеров, нелегально выпущенные различными ЦС сертификаты для Google. Например, там был TurkTrust. При этом, этот сертификат центр сертификации был установлен в ванильном файерфоксе (был валиден до марта 2015). Его вроде как исключили после того инцидента, но временно и потом вернули. Да и потому, ну исключили, И ЧТО? Как это повлияло на пользователей, которые уже установили его и не обновляются, но пользуются интернетом здесь и сейчас?
Альтернатива, в общем-то, одна: доверять только тем ЦС, чьи корневые сертификаты я установил в браузер сам и получил надёжным путём (ну или мой сисадмин, если я на работе, и здесь речь не о моём личном доверии к ЦС, а доверии моей организации). В противном случае я вижу корневой сертификат и «а хрен его знает, откуда он здесь взялся, поставился с браузером, браузер качали по http, может, по дороге подсунули».
Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?ls1
24.09.2015 11:32+1ну исключили, И ЧТО?
другим урок, «потеряете деньги»
не обновляются, но пользуются интернетом здесь и сейчас?
ССЗБ
и получил надёжным путём
вот тут возникает много вопросов, как определить надежность
ну или мой сисадмин, если я на работе
Наши «сисадмины» через AD распространяют корпоративные корневые сертификаты и включают на проксе (вообще не стесняясь) опцию SSL Inspection (политкорректное название MITM)
Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?
Вы так говорите, как будто это я вам предлагаю откуда попало корневые сертификаты качать. Я как раз таки против.
nmk2002
24.09.2015 11:34+3доверять только тем ЦС, чьи корневые сертификаты я установил в браузер сам
Но вы же все равно установите себе корневые Thawte, GeoTrust и прочие. Без них многие сайты у вас будут ругаться на ошибку сертификата.
И никто не даст вам гарантий, что УЦ, которые в вашей системе будут доверенными не накосячут так же или даже хуже.
Производители ОС и браузеров руководствуются CP/CPS, авторитетом УЦ и аудиторских компаний, которые принимают участие в создании и контроле УЦ.
Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка). Вот какой смысл в этой всей петрушке с шифрованием, если корневой качается по http?
Я года 4 назад настраивал клиент-банк Казахского Сбербанка. Там аналогичная ситуация: скачайте сертификат по ссылке … Звонил и объяснял им, что так нельзя. Пропадает весь смысл доверия. Кое как уговорил продиктовать мне отпечаток сертификата, который они считают правильным.
В итоге, через несколько месяцев у сертификата истек срок действия. Техпод на голубом глазу говорили мне, что надо просто игнорировать ошибку в браузере.
Все мои заверения, что это вообще ни в какие ворота остались неуслышанными.merlin-vrn
24.09.2015 11:40Но вы же все равно установите себе корневые Thawte, GeoTrust и прочие. Без них многие сайты у вас будут ругаться на ошибку сертификата.
Хе-хе. А сейчас не ругаются и дают мне и семи миллиардам человек в мире ощущение ложной безопасности. Разъясните мне чем отличается: я нажал в ошибке кнопку «игнорировать» и я доверяю сертификату, образовавшемуся у меня в браузере самопроизвольно после скачивания его по http.
Вообще идеальный вариант c учётом вот этого кошмарного зоопарка легаси ЦС — аналог EV средствами браузера. Если я установил сертификат, отображать его как особо доверенный. Если не я установил — не отображать.nmk2002
24.09.2015 12:59+2Что вам мешает на себе проверить предложенную модель? Удалите все доверенные УЦ из настроек браузера или ОС. Затем добавляйте те, которые считаете надежными.
merlin-vrn
24.09.2015 15:27Конечно. Смысла только мало — я не доверяю по умолчанию тому, что у меня подлинный сертификат GeoTrust, а средств сверки отпечатка сертификата GeoTrust не предлагает. В общем, все сайты станут недоверенными и всё. Ничего нового я не увижу, для себя я и сам знаю, что система порочна.
Чтобы это имело смысл, это должно стать массовым движением. Если треть пользователей интернета откажутся доверять дефолтным CA, они зашевелятся и будут что-то делать. А для этого нужно, чтобы сертификаты не включались в браузер по умолчанию.
navion
24.09.2015 12:27-1Вдогонку: недавно кто-то поблизости разбирался, кажется, с «Cбербанк-АСТ». Меня удивил тот факт, что в инструкции было предложено скачать корневой сертификат по http (была ссылка).
CRL и CDP размещают по HTTP для избежания зацикливаний, а вы можете позвонить в Сбербанк и спросить серийный номер.
Подписи организаций так и подтверждают — бумажкой с серийником, подписью ответственного и печатью.merlin-vrn
24.09.2015 12:31+3CRL сам по себе — подписанная штука. Его можно размещать как угодно, при условии, что он доступен и у клиента уже есть корневой сертификат. Доверие к CRL возникает на основании доверия к корневому сертификату, которым он подписан. Там внутри и время есть для ограничения срока валидности, так что просто старый CRL подсунуть не покатит.
Про позвонить — оно конечно можно, но ни намёка в инструкции на это не было. Но в данном случае это ещё и нерационально — сотрудник ХОДИЛ В БАНК НОГАМИ С ФЛЕШКОЙ для выпуска своего сертификата; что мешало ему сразу же передать и корневой из рук в руки?navion
24.09.2015 16:42Нашли где искать хороший сервис. АБ требовал (!) директору идти в отделение для замены ключа, которые они зами забыли подписать при замене. Ситуация разрешилась после звонка разъяренного главбуха нашему аккаунту (или как это называется в банке).
navion
24.09.2015 12:15Там где надо, составляют свои списки.
Я сталкивался с блокировкой корневого CA StartCom в банках — у местных идиотов припекло из-за бесплатных сертификатов, но заблокировать только Class 1 они не догадались.
amarao
24.09.2015 11:31+2Я о том, что я не могу поднять свой собственный ssl-сервер, который у пользователей будет нормально работать, не забашляв денег.
Если бы я эту штуку делал, то сертификаты были бы намертво завязаны на владельца домена. Кого домен, того итапкисертификаты.ls1
24.09.2015 11:38Вы сейчас описали обычный самоподписанный сертификат, но не предложили безопасного механизма получения своего корневого сертификата на компы клиентов. Вся проблема то в том, что такого механизма нет.
merlin-vrn
24.09.2015 11:41+1Неправда, есть DANE
ls1
24.09.2015 11:48+1Так оно само от DNSSEC зависит
merlin-vrn
24.09.2015 11:55Да, он в данном случае выступает в роли ЦС. DNSSEC в свою очередь связан непосредствнно с администратором домена. В общем, случай именно тот, как описал amarao — раз я владею доменом, то могу настроить и DNSSEC-записи для него без дополнительных костылей и левых ЦС. Я доказываю свою личность тому же, у кого регистрировал домен, а не кому-то ещё, делаю это один раз и после этого могу делать с доменом что угодно. В том числе совершенно самостоятельно накручивать DNSSEC для любых поддоменов любого уровня, и получать для них работающий SSL, что сейчас с ЦС невозможно — wildcard действует в пределах одного уровня поддомена.
(Разумеется, условие «DNSSEC поддерживается клиентами, серверами, и зоной» остаётся, куда без этого.)
mayorovp
24.09.2015 12:03DNSSEC «покупается» вместе с доменом. Вся разница в том, что вместо 3х записей регистратор добавляет 4.
amarao
24.09.2015 12:47Не «само» подписанный, а подписанный ключом, опубликованным в DNS, за достоверность которого отвечает регистратор.
ls1
24.09.2015 13:03+2Таким образом, если я решу вам устроить SSL MITM мне надо будет расковырять не УЦ верисайна, а всего лишь какого-то криворукого «регистратора». Вы считаете, что при таком подходе мир станет лучше?
amarao
24.09.2015 13:14Верисайн прекрасно может быть регистратором.
Фактически, у нас две иерархии: одна отвечает за соответствие домена и IP, а вторая отвечает за соответствие «домена и владельца».
Я бы даже сказал, что «всё ок», если бы PKI (в том виде как оно используется) позволяло людям подписывать любые поддомены себе самим. Примерно как с делегацией доменов.
Но этого нет. Вместо этого есть либо звезда, либо покупной сертификат на каждый чих. Звезда небезопасно (у меня какой-нибудь lab-4.desunote.ru показывает сертификат от desunote.ru, и если его ломают, то утыривают сертификат), а на каждую лабу по сертификату не напасёшься). Именно это я и имел в виду, когда говорил про слишком много «дайбабла».
Алсо, я не видел случаев, чтобы кто-то «расковыривал криворуких регистраторов» у google или microsoft.
Хочешь дешёвый домен для мелочи — пожалуйста. Хочешь задорого и чтобы никаких «расковыренных криворуких регистраторов» — такие тоже есть, для VIP-доменов, типа brandnames.com.
Зачем тут ещё отдельная иерархия с сертфикатами? Чем расковыренный турктелеком-CA отличается от расковыренного турктелеком-REG?
merlin-vrn
24.09.2015 13:15+1Нет, чтобы устроить митм не нужно расковыривать верисайн. Достаточно расковырять абсолютно любой ЦС, доверенный у клиента, а их сотни. Какой-нибудь голимый турктраст может выпустить сертификат с любым доменным именем, и даже добавит туда флажок EV если захочет.
А вот с dnssec выбора гораздо меньше — ломать регистратора и всё, варианты кончились. А возможностей для владельца домена он предоставляет больше.
ls1
24.09.2015 14:02Целевая атака на любой доверенный УЦ обойдётся куда как дороже целевой атаки на любого регистратора, а вреда от периодических факапов с доверенными УЦ имхо меньше, т.к. они как правило не целевые а глобальные и быстро палятся в отличие от целевых. ИМХО, в общем, доверенные УЦ — наименьшее зло
nmk2002
24.09.2015 14:10-1По поводу DANE: скорее всего регистраторы будут использовать те же самые доверенные УЦ и по сути ту же самую модель доверия.
merlin-vrn
24.09.2015 14:45+2скорее всего регистраторы будут использовать те же самые доверенные УЦ и по сути ту же самую модель доверия
Вы случайно это написали?
В случае с традиционной схемой какой-то, случайно выбранный 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, проходить дополнительные проверки и так далее.
Envek
24.09.2015 18:20+4Пожалуйста, превратите ваш комментарий в статью. С сравнением моделей доверия, руководством по установке и данными по поддержке ОС, браузерами, УЦ и регистраторами. Мне очень нравится идея DNSSEC, так, как вы её сейчас описали.
merlin-vrn
24.09.2015 14:49-1Целевая атака на любой доверенный УЦ обойдётся куда как дороже целевой атаки на любого регистратора
Это с какой стати?
mickvav
24.09.2015 20:40Нет, можно ещё днс у юзера в роутере поломать. Благо прошивки SOHO роутеров почти никто не обновляет.
mayorovp
24.09.2015 21:36Если ключ корневой зоны будет известен DNS-клиенту — взлом роутера не поможет.
merlin-vrn
24.09.2015 22:30Прелесть DNSSEC в том, что если зона подписана, кривой DNS-сервер вызовет максимум DoS, но не MitM. Клиент будет видеть, что подписи невалидны или отсутствуют, хотя должны, а пользователь увидит просто «не работает».
easyman
23.09.2015 20:55+5Так ещё для подписи кода надо сертификаты.
Upd: www.symantec.com/code-signing
crea7or
23.09.2015 20:59+1www.startssl.com и сейчас даёт бесплатные.
tyderh
23.09.2015 21:03+4У startssl все очень и очень упорото сделано. И не для человеков.
Сейчас китайский wo-sign дает сертификат на произвольное количество доменов и поддоменов (относительно поста на хабре они сделали удобную английскую форму для этого дела), да и Let's encrypt на подхоже
ivlis
23.09.2015 21:28+2Что конктерно у startssl не для человеков? Как-то я бы китайскому центру сертификации не доверял бы в прицнипе.
tyderh
23.09.2015 21:32+4Сертификаты для входа, которые истекают по дате без каких-либо предупреждений. И логин по ним, принципиально не работающий. И процедура восстановления доступа в виде «зарегистрируйтесь с другой почты, напишите нам в техподдержку и мы вам перенесем домены».
Как-то я бы китайскому центру сертификации не доверял бы в прицнипе.
Какая разница, кто подписывает собственноручно сгенерированный сертификат?ivlis
23.09.2015 21:53+2Сертификаты для входа, это как раз то что надо вводить повсеместно вместо паролей, это хорошо и правильно. Преупреждать, что он скоро истечет не в их силах, они же не делают браузер.
Какая разница, кто подписывает собственноручно сгенерированный сертификат?
Тем что они подпишут свой ключ для моего домена, если надо будет и им за это ничего не будет.nmk2002
23.09.2015 22:00+2Вот для этого и надо Certificate Transparency. Вы сможете отследить, что кто-то выпустил сертификат для вашего домена.
И вообще, для УЦ выпустить сертификат для домена без ведома владельца, да еще и злонамеренно — подписать себе смертный приговор. Весь бизнес УЦ держится на доверии к этим УЦ, поэтому они на это не пойдут.
Envek
23.09.2015 22:41Информация ваша уже не верна — в этом году меня по почте предупредили достаточно заранее (за 2-3 недели) об истечении сертификатов. В прощлом году же да — я сам пролетел и учётку профукал.
merlin-vrn
24.09.2015 10:17сертификаты для входа — это очень круто, вот бы все так делали. Например, если к браузеру добавить crypto token api, мы сразу же сможем логиниться в их сервис по токену
Aclz
23.09.2015 22:07+1Выпуск сертификата по заверению Symantec произошел в результате внутреннего тестирования.
Нифига себе тестеры там работают, не мелочатся, сразу EV на Гугле генерят. Контозы и фу-баров на них нет.nmk2002
23.09.2015 22:12А главное, что Symantec в принципе не выпускает сертификаты для Google. Сертификаты для Google выпускает в основном GeoTrust. Поэтому непонятно, как вообще они могли такое тестировать
memtew
23.09.2015 22:17+4При проверке пингом многие пишут то, что первое придёт в голову — ping google.com. Видимо, здесь такая же история :)
nochkin
23.09.2015 22:23Ведь у них есть symantec.com, который по идее более очевиден для компании с названием Symantec.
Alexeyslav
24.09.2015 08:25+2нифига, ya.ru короче вводить.
Areso
24.09.2015 17:14+1ping 8.8.8.8 — что может быть короче и лучше запоминается чем четыре восьмерки в ряд?
TaHKucT
24.09.2015 18:11+2127.0.0.1 конечно же. Он ведь ближе.
kemko
24.09.2015 18:31Зачем так длинно? В большинстве случаев подойдёт и написание 127.1
ls1
24.09.2015 18:51+1$ ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.067 ms
merlin-vrn
24.09.2015 22:34127.1 объясните, откуда взялось? И о каком «большинстве случаев» речь? Циска это поймёт как 0.0.127.1, и сами понимаете, работать не должно
вот ping 2130706433 в линуксе — работает. Но число длинное и на первый взгляд непонятно, откуда взялось. А можно ещё ping 134744072 :)TaHKucT
25.09.2015 00:11+1В 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 тоже работает
borisko
23.09.2015 22:23+3В оригинальной новости не сказано, что Symantec выпустил сертификат. Сказано, что в лог выпуска ev-сертификатов попала запись о намерении выпустить сертификат. Если это правда было тестирование какой-то функциональности, то из одного совсем не следует другое.
tzlom
23.09.2015 22:43+5А в банлист хрома гугл добавило намерение выпустить сертификат.
Aclz
23.09.2015 22:57+3Это не «намерение», а т.н. пресертификат — запись, используемая в механизме Certificate Transparency. Она в себе содержит запрос на выдачу сертификата (что-то типа .cer-файла), плюс дополнительные поля. В нём уже содержится информация о сгенерированном открытом ключе, серийнике и т.д. И если на основе данного открытого ключа когда-либо будет выпущен сертификат — он уже будет забанен в Хроме.
Lerg
24.09.2015 00:51+8И внутри Symantec потестировали сертификаты, и Certificate Transparency протестировали.
ComodoHacker
24.09.2015 11:37+1Уважаемый nmk2002, раз уж вы решились та такой ответственный шаг, как recovery mode, можно было и подготовиться. Прочитать не только желтую прессу и совершенно неинформативный блог Гугла. Можно было почитать обсуждения на Reddit, Slashdot или Hacker News и разобраться в вопросе. Можно было объяснить нам, что же на самом деле произошло, а не вводить в заблуждение заголовком «Symantec самовольно выпустил сертификат для google.com», не соответствующим действительности. Можно было рассказать всем, что такое Certificate Transparency, как оно работает и зачем оно нужно.
А так ценность вашего поста для сообщества не нулевая, а отрицательная. Я оценил вашу попытку recovery как неудачную. Но вы еще можете что-то исправить.
Andrusha
Астрологи объявили неделю поддельных сертификатов на Хабре.
vanxant
Количество сертификатов для google.com удвоилось