Кто в теме — уже, наверное, знает. А кто не в теме — читаем занятный блог-пост: http://www.imperialviolet.org/2012/02/05/crlsets.html
Прежде, чем обсуждать суть проблемы, давайте вспомним основные моменты, связанные с PKI при подключении к веб-сайтам по HTTPS.
Как правило, при подключении к веб-серверу с использованием SSL (т.е. по протоколу HTTPS), веб-сервер посылает клиенту сертификат SSL. Клиент пропускает сертификат через сертификато-дробилку, называемой Certificate Chaining Engine (CCE). Этот самый CCE берёт сертификат, строит для него цепочку сертификатов. Если цепочка успешно построилась и закончилась каким-то корневым сертификатом, который установлен в Trusted Root CAs, CCE начинает проверять каждый сертификат в цепочке (кроме самоподписанного корневого сертификата) на отзыв. Если какой-то сертификат в цепочке оказался отозванным — приложение выкидывает ошибку на пол экрана пользователю, что сертификат отозван и не следует туда заходить. Если не отозван, веб-браузер продолжает установку подключения дальше. На этом мы и остановимся здесь.
Но Google решил, что проверять сертификаты на отзыв слишком накладно, поэтому эта функциональность будет скорее всего выпилена в более новых версиях Chrome (и это после стольких лестных комментариев в моём бложеке?). Вместо этого, они планируют всю информацию об отзыве сертификатов (очевидно, 100+ поставщиков) в виде обновлений. Т.е. десятки (а то и сотни) мегабайт трафика ежедневно вам гарантированы. Ладно бы, там было что-то полезное. Так нет — условная копия всех возможных CRL'ов коммерческих поставщиков сертификатов. И так изо дня в день. Поскольку каждый CRL подписан издающим CA, здесь появляется вопрос технической реализации. Единственное, что можно тут придумать — это просто брать все CRL'ы, паковать их как есть в один контейнер и доставлять в браузеры через обновления. Всё остальное — лютая ересь. Если гугл придумает что-то своё, сразу появится вопрос о доверии самопальному мегагитлерCRL'у от гугла. Т.е. доверия тут ноль, потому что гугл — это гугл, а поставщик сертификатов всё-таки, отвечает за информацию об отзыве.
Мотивируют они это в первую очередь вот чем:
The problem with these checks, that we call online revocation checks, is that the browser can't be sure that it can reach the CA's servers. There are lots of cases where it's not possible: captive portals are one. A captive portal frequently requires you to sign in on an HTTPS site, but blocks traffic to all other sites, including the CA's OCSP servers.
я, если честно, не очень понял причём здесь captive portals, но если любой другой трафик блокируется, откуда браузер (в нашем случае это Chrome) получит обновления? По телепатии, очевидно. Но предположим другой сценарий — клиент находится в запредельно lock-down сети с очень ограниченным доступом в интернеты или вообще без оного. А веб-сервер (и сертификат) установлены где-то внутри сети. Тогда с некоторой долей вероятности, проверить сертификат SSL на отзыв не удастся. Fail. Но это на самом деле решаемо:
- Если используется определённый набор сертификатов, можно вручную скачать CRL'ы конкретных поставщиков сертификатов и устанавливать их на клиенты.
- Скачивать CRL'ы вручную и складывать внутри сети. Далее, поднять свой локальный OCSP и направлять клиентов (после соответствующей настройки) на локальный OCSP для получения статуса отзыва сертификата с локального OCSP сервера.
Решение у этой проблемы есть. Далее:
If browsers were to insist on talking to the CA before accepting a certificate, all these cases would stop working. There's also the concern that the CA may experience downtime and it's bad engineering practice to build in single points of failure.
Нечасто услышишь, что серверы VeriSign, Thawte или GoDaddy (самые популярные поставщики сертификатов для SSL) испытывали даунтаймы.
But an attacker who can intercept HTTPS connections can also make online revocation checks appear to fail and so bypass the revocation checks! In cases where the attacker can only intercept a subset of a victim's traffic (i.e. the SSL traffic but not the revocation checks), the attacker is likely to be a backbone provider capable of DNS or BGP poisoning to block the revocation checks too.
Смахивает на диверсию. Но мы можем настроить браузер на вывод предупреждения, что информация отзыва для конкретного ресурса недоступна. Вот рецепт для Internet Explorer 7+: IE7 & SSL. Если вы увидели Certificate Warning, значит кто-то пойзонит BGP или роутит DNS не туда, куда надо.
If the attacker is close to the server then online revocation checks can be effective, but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed. In short, even revocation checks don't stop this from being a real mess.
Разве что с этим можно согласиться. Но последние случаи с Comodo и DigiNotar показали, что реально эксплуатировать «левые» сертификаты достаточно сложно, но можно. Но давайте подумаем. Скомпрометировали мы Comodo и купили сертификат на имя login.live.com, установили сертификаты на веб-сервер и ждём посетителей. Если Comodo (или любой другой. Comodo здесь только для рифмы) не заметит, что они выписали сертификат тому, кому он не полагается, значит — Fail. Гугл об этом не узнает тем более. Если заметит — звонок в ставку, сертификат отзывается, Microsoft ставится на уши. Как-то так это выглядит сейчас. Придумать что-то более лучше — в условиях настоящей реальности пока нельзя.
So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.
Здесь мы читаем примерно следующее: 99% водителей никогда не попадают в аварии, поэтому они могут не пристёгиваться. Но гарантию, что в оставшийся 1% не попадёшь именно ты — никто не даст. Поэтому, эта фраза может расцениваться как попытка очень толстого троллинга, не более того. Аргументы вида «я не пристёгиваюсь, потому что не врезаюсь» звучат не очень убедительно. Каждый разбитый насмерть водитель считал, что он никогда не пристёгивался и он в числе этих 99%. Who's next?
While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy.
Очень интересное суждение. Медленное? На сколько? Об этом чуть ниже. Прайваси. Я уважаю прайваси, но не особо уважаю прайвасидрочеров. Ок, мы при проверке сертификата обращаемся к OCSP издателя сертификата и он узнает, куда наш айпишник ходит. Но если быть честным, то быть честным до конца. Прайваси может существовать (опять же, в разумных пределах) на уровне передаваемых данных, но не мест посещения. Ваш интернет-провайдер точно знает, по каким сайтам вы шастаете и даже может подсчитать, сколько порно было скачано в прошлом месяце. Особо удачливые провайдеры могут даже примерно составить каталог скачанных диафильмов (не дай бог вам качать фильмы с собачками там или ещё всякое стрёмное кино). Учитывая, что SSL'ом обычно защищаются веб-сайты, в которые вы вводите действительно личную информацию (номера кредитных карт, персональные данные и всё такое.). А здесь, нехороший поставщик сертификатов SSL узнает, что вы каждый вторник заходите в интернет-банк. Любой человек, умеющий (и который имеет доступ) слушать трафик интернета всё равно узнает, куда вы ходите. Destination IP Address уж не спрячете никуда.
С другой стороны, ваш веб-браузер (в нашем случае, это снова Chrome) тоже знает, куда вы ходите. И какие ссылки кликаете и какие файлики качаете? Музыку? А оплатить налог за скачивание нелицензионного контента заплатить не хотите? Особенно, в свете последних нововведений в прайваси гугла, я бы больше остерегался именно гугла, чем верисайна.
С третьей стороны (я не понял, откуда у плоскости появилась третья сторона, но пусть будет. Сферическая), существует такая штука, как stapled OCSP response. А гугл о ней знает? Судя по всему — нет. Что это такое? А вот что, веб-сервер может сам для себя запросить информацию об отзыве для своего сертификата SSL. Один раз. И раздавать его каждому подключающемуся клиенту. Поскольку все запросы OCSP подписаны поставщиком сетификата SSL, риск компрометации здесь около нуля или чуть ниже. Поэтому этот stapled response можно без зазрения совести посылать клиенту вместе с самим SSL сертификатом.
The median time for a successful OCSP check is ~300ms and the mean is nearly a second.
я пробовар округлять по-разному, но nearly a second у меня не получилось. Я бы ещё кое-как притянул бы за уши nearly a half second, но целую секунду — мне совесть не позволяет.
This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.
выделенную часть явно писал умственный инвалид или кто-то, кто в этой кухне вообще ничего не понимает. Во-первых, веб-сайты не используют SSL там, где не надо вовсе не потому, что время загрузки страницы увеличивается на 0,3 секунды. Если весь мир завернуть в SSL — интернеты будут очень медленные, потому что даже при современном оборудовании нагрузка на процессор (криптография главным образом ложится именно на процессор) может вырасти очень значительно. Когда это надо — вопросов нет, надо использовать. А для чтения бложека (например, моего) никаких профитов из SSL не извлечёте, а сервер мой будет тормозить — факт. Ах, да. Сертификат SSL проверяется на отзыв только при подключении и потом не проверяется (до тех пор, пока не выйдет новый CRL). Т.е. задержку в 0,3 секунды получите при первой загрузке страницы. Вопрос прайваси мы уже разобрали выше.
Далее, написан один из вариантов реализации этой афёры — гугл договаривается с поставщиками сертификатов, чтобы те присылали им свои CRL'ы. Пока — в рамках CAB forum'а. Но и здесь есть интересные моменты:
We have to be mindful of size, but the vast majority of revocations happen for purely administrative reasons and can be excluded.
Ни один здравомыслящий CA не скажет гуглу, почему он отозвал тот или иной сертификат (т.е. административный или неадминистративный отзыв). Максимум на что может рассчитывать гугл — это revocation reason в CRL'е.
Вобщем, вы можете думать об этом что хотите, можете ненавидеть гугл и его гуглохром, можете любить их. Что я об этом думаю — вы уже знаете. Чтите privacy и EULA.