Прямо сейчас у нас есть небольшая проблема, но на мой взгляд, со временем ситуация может только ухудшиться. Всё больше и больше сайтов получают сертификаты — необходимые документы для внедрения HTTPS — но у нас нет механизма для защиты от злоупотреблений.
Мы сейчас видим настоящую золотую лихорадку вокруг сертификатов, поскольку всё больше сайтов внедряют HTTPS. Кроме очевидных преимуществ безопасности и приватности, есть и другие выгоды от внедрения защищённых соединений, которые я перечислил в статье «Вы всё ещё думаете, что вам не нужен HTTPS?». Обычно именуемые «SSL-сертификаты» или «HTTPS-сертификаты» разлетаются со скоростью, которой мы никогда не видели в истории интернета. Каждый день я исследую сайты из первого миллиона по посещаемости и анализирую различные аспекты их безопасности, а каждые 6 месяцев публикую отчёт. Вы можете изучить эти отчёты здесь, но сейчас посмотрим на темпы внедрения HTTPS.
Процент сайтов из первого миллиона самых популярных сайтов по статистике Alexa, где стоит редирект на версию HTTPS
Мы не просто продолжаем внедрять HTTPS, но скорость внедрения тоже увеличивается. Так выглядит настоящий прогресс. Процесс получения сертификата со временем становится более простым, благодаря великолепному Let's Encrypt, к тому же ещё и сертификаты стали бесплатными. Если вкратце, мы просто отправляем запрос на получение сертификата (Certificate Signing Request, CSR) в центр сертификации (CA), а тот предлагает доказать факт владения доменом. Обычно это делается с помощью изменения записи DNS TXT или размещения специального кода где-нибудь по случайному URL на нашем домене. Как только задание выполнено, CA выдаёт сертификат, и мы можем предъявлять его браузерам и наслаждаться зелёным замком и указанием HTTPS в адресной строке.
Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.
Никто и никогда не хотел бы услышать эти слова, но реальность такова, что нам приходится их слышать чаще, чем хотелось бы. Хакеры могут получить что угодно, когда у них есть доступ к нашему серверу, и часто им нужен секретный ключ. Сертификаты HTTPS — это публичные документы, которые мы отправляем каждому посетителю нашего сайта, но единственная вещь, которая не позволяет другим использовать такой же сертификат — отсутствие нашего секретного ключа. Когда браузер устанавливает защищённое соединение с сайтом, он проверяет, что у сервера есть секретный ключ для используемого сертификата. Вот почему никто не может использовать наш сертификат. Если хакер получает секретный ключ, то ситуация меняется.
Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.
В случае компрометации мы должны отозвать сертификат, чтобы исключить возможность злоупотреблений. Как только сертификат помечен как отозванный, браузер знает, что ему нельзя доверять, даже если у него не закончился срок действия. Владелец запросил отзыв, и ни один клиент больше не должен принимать этот сертификат.
Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).
CRL — действительно очень простая концепция, это просто список всех сертификатов, которые CA пометил как отозванные. Клиент может отправить запрос к серверу CRL и скачать копию списка. Имея копию этого списка, браузер сверяет с ним предъявленный сертификат. Если он там присутствует, то браузер знает, что сертификат недействителен и ему нельзя доверять, он тогда выдаст ошибку и разорвёт соединение. Если сертификата нет в списке, то всё нормально — и браузер продолжит работу.
Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остаётся той же. У списка CRL немалый размер. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить её при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Всё это выглядит не очень приятно, так что посмотрим на OCSP.
OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!
Действительно, OCSP превосходит CRL по скорости получения ответа, но за это преимущество нужно платить (вы тоже ненавидите, когда такое случается?). Цена довольно высока — это ваша приватность… Если подумать о сути запроса OCSP, это очень конкретный запрос на единственный сертификат HTTPS. По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:
Так что это не идеальный сценарий. Вы теперь выдаёте историю посещённых сайтов некоей третьей стороне, о которой даже ничего не знаете, и всё ради HTTPS, который вроде как должен повысить вашу приватность и безопасность. Но погодите, есть ещё кое-что.
Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.
После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?
Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры CA в офлайн ваши сайты тоже уходят туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергает пользователя риску. Это трудный выбор, но прямо сейчас, сегодня, ничего такого на самом деле не происходит…
На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?
Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.
Прямо сейчас в данный конкретный момент времени реальность такова, что мы не можем исправить ситуацию. Впрочем, кое-что можно предпринять и, возможно, в будущем механизм отзыва сертификатов станет по-настоящему надёжным.
Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.
В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?
Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Я не хочу здесь вдаваться в лишние подробности, вы можете получить всестороннюю информацию из моего блога по OCSP Stapling, но вот суть. OCSP Stapling избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.
На первый взгляд это кажется немного странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но всё работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Лучший вариант! Но на самом деле не лучший, извините. OCSP Stapling — отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, но действительно ли мы думаем, что её будет поддерживать злоумышленник? Нет, я так не думаю, конечно же он не будет этого делать. Что нам на самом деле нужно — так это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе нашего сертификата у CA мы просим его установить на нём флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Установить флаг легко.
После установки этого флага мы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит наш ключ, ему также придётся использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет. Тада!
Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге OCSP Expect-Staple, но здесь тоже объясню вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис report-uri.io, в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, как мне бы хотелось, я также написал спецификацию для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчётов, которые так нам нужны, ещё до активации Must-Staple. Установка заголовка будет простой, как и всех остальных заголовков безопасности:
Если мы говорим об отзыве сертификатов, то должны рассмотреть тему их подделки. Если некто пытается скомпрометировать CA или как-то ещё получить сертификат, который ему не положен, то как он будет действовать? Если я прямо сейчас взломаю CA и получу сертификат на ваш сайт, то вы не узнаете об этом до тех пор, пока об этом не сообщат в новостях. У вас в компании даже может быть инсайдер, который получит сертификат в обход внутренних процедур, и он будет делать с ним всё что захочет. Нам нужна стопроцентная прозрачность, и скоро мы её получим. Это Certificate Transparency.
CT — новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал, чтобы браузер им доверял. Вы можете почитать статью с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.
Эти журналы полностью открыты, и любой может посмотреть их, так что если кто-то получит сертификат на ваш сайт, то вы об этом узнаете. Например, здесь вы можете увидеть все сертификаты, выданные на мой домен, и поискать свой собственный. Есть также сервис CertSpotter от sslmate для той же цели, а я использую инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен. Стандарт CT — это фантастическая идея, и я не могу дождаться, когда он станет обязательным, но есть одна оговорка. Дело в том, что CT — это только первый шаг. Знать об этих сертификатах хорошо, но у нас по-прежнему остаются все упомянутые проблемы с их отзывом. Тем не менее, мы можем решать только по одной проблеме за раз, и даже самые лучшие в мире механизмы отзыва неэффективны, если мы не знаем, какие сертификаты нужно отзывать. CT по крайней мере даёт нам эту информацию.
Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:
Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.
В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let's Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.
Для демонстрации проблемы и того, насколько она реальна, попробуйте зайти на новый поддомен, который я открыл на своём сайте, revoked.scotthelme.co.uk. Как вы вероятно догадываетесь, к этому поддомену прикреплён отозванный сертификат, и вполне вероятно, что он нормально загрузится в вашем браузере. Если нет, если ваш браузер выдаст предупреждение об истёкшем сроке действия, то это значит, что ваш браузер по-прежнему отправляет запросы OCSP и вы только что сообщили в CA о том, что посетили мой сайт. Для доказательства, что такая проверка с мягким сбоем бесполезна, можете добавить в
Я бы хотел закончить статью вопросом: следует ли нам исправлять процедуру отзыва сертификатов? Впрочем, это тема для другой статьи.
Сертификаты
Мы сейчас видим настоящую золотую лихорадку вокруг сертификатов, поскольку всё больше сайтов внедряют HTTPS. Кроме очевидных преимуществ безопасности и приватности, есть и другие выгоды от внедрения защищённых соединений, которые я перечислил в статье «Вы всё ещё думаете, что вам не нужен HTTPS?». Обычно именуемые «SSL-сертификаты» или «HTTPS-сертификаты» разлетаются со скоростью, которой мы никогда не видели в истории интернета. Каждый день я исследую сайты из первого миллиона по посещаемости и анализирую различные аспекты их безопасности, а каждые 6 месяцев публикую отчёт. Вы можете изучить эти отчёты здесь, но сейчас посмотрим на темпы внедрения HTTPS.
Процент сайтов из первого миллиона самых популярных сайтов по статистике Alexa, где стоит редирект на версию HTTPS
Мы не просто продолжаем внедрять HTTPS, но скорость внедрения тоже увеличивается. Так выглядит настоящий прогресс. Процесс получения сертификата со временем становится более простым, благодаря великолепному Let's Encrypt, к тому же ещё и сертификаты стали бесплатными. Если вкратце, мы просто отправляем запрос на получение сертификата (Certificate Signing Request, CSR) в центр сертификации (CA), а тот предлагает доказать факт владения доменом. Обычно это делается с помощью изменения записи DNS TXT или размещения специального кода где-нибудь по случайному URL на нашем домене. Как только задание выполнено, CA выдаёт сертификат, и мы можем предъявлять его браузерам и наслаждаться зелёным замком и указанием HTTPS в адресной строке.
Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.
Нас хакнули
Никто и никогда не хотел бы услышать эти слова, но реальность такова, что нам приходится их слышать чаще, чем хотелось бы. Хакеры могут получить что угодно, когда у них есть доступ к нашему серверу, и часто им нужен секретный ключ. Сертификаты HTTPS — это публичные документы, которые мы отправляем каждому посетителю нашего сайта, но единственная вещь, которая не позволяет другим использовать такой же сертификат — отсутствие нашего секретного ключа. Когда браузер устанавливает защищённое соединение с сайтом, он проверяет, что у сервера есть секретный ключ для используемого сертификата. Вот почему никто не может использовать наш сертификат. Если хакер получает секретный ключ, то ситуация меняется.
Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.
Отзыв
В случае компрометации мы должны отозвать сертификат, чтобы исключить возможность злоупотреблений. Как только сертификат помечен как отозванный, браузер знает, что ему нельзя доверять, даже если у него не закончился срок действия. Владелец запросил отзыв, и ни один клиент больше не должен принимать этот сертификат.
Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).
Списки отозванных сертификатов
CRL — действительно очень простая концепция, это просто список всех сертификатов, которые CA пометил как отозванные. Клиент может отправить запрос к серверу CRL и скачать копию списка. Имея копию этого списка, браузер сверяет с ним предъявленный сертификат. Если он там присутствует, то браузер знает, что сертификат недействителен и ему нельзя доверять, он тогда выдаст ошибку и разорвёт соединение. Если сертификата нет в списке, то всё нормально — и браузер продолжит работу.
Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остаётся той же. У списка CRL немалый размер. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить её при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Всё это выглядит не очень приятно, так что посмотрим на OCSP.
Протокол проверки статуса сертификата
OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!
Действительно, OCSP превосходит CRL по скорости получения ответа, но за это преимущество нужно платить (вы тоже ненавидите, когда такое случается?). Цена довольно высока — это ваша приватность… Если подумать о сути запроса OCSP, это очень конкретный запрос на единственный сертификат HTTPS. По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:
Сертификат для pornhub.com валидный?
Так что это не идеальный сценарий. Вы теперь выдаёте историю посещённых сайтов некоей третьей стороне, о которой даже ничего не знаете, и всё ради HTTPS, который вроде как должен повысить вашу приватность и безопасность. Но погодите, есть ещё кое-что.
Полный сбой
Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.
После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?
Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры CA в офлайн ваши сайты тоже уходят туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергает пользователя риску. Это трудный выбор, но прямо сейчас, сегодня, ничего такого на самом деле не происходит…
Частичный сбой
На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?
Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.
Исправление проблемы
Прямо сейчас в данный конкретный момент времени реальность такова, что мы не можем исправить ситуацию. Впрочем, кое-что можно предпринять и, возможно, в будущем механизм отзыва сертификатов станет по-настоящему надёжным.
Проприетарные механизмы
Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.
В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?
OCSP Must-Staple
Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Я не хочу здесь вдаваться в лишние подробности, вы можете получить всестороннюю информацию из моего блога по OCSP Stapling, но вот суть. OCSP Stapling избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.
На первый взгляд это кажется немного странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но всё работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Лучший вариант! Но на самом деле не лучший, извините. OCSP Stapling — отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, но действительно ли мы думаем, что её будет поддерживать злоумышленник? Нет, я так не думаю, конечно же он не будет этого делать. Что нам на самом деле нужно — так это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе нашего сертификата у CA мы просим его установить на нём флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Установить флаг легко.
После установки этого флага мы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит наш ключ, ему также придётся использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет. Тада!
OCSP Expect-Staple
Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге OCSP Expect-Staple, но здесь тоже объясню вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис report-uri.io, в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, как мне бы хотелось, я также написал спецификацию для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчётов, которые так нам нужны, ещё до активации Must-Staple. Установка заголовка будет простой, как и всех остальных заголовков безопасности:
Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preloadПоддельные сертификаты
Если мы говорим об отзыве сертификатов, то должны рассмотреть тему их подделки. Если некто пытается скомпрометировать CA или как-то ещё получить сертификат, который ему не положен, то как он будет действовать? Если я прямо сейчас взломаю CA и получу сертификат на ваш сайт, то вы не узнаете об этом до тех пор, пока об этом не сообщат в новостях. У вас в компании даже может быть инсайдер, который получит сертификат в обход внутренних процедур, и он будет делать с ним всё что захочет. Нам нужна стопроцентная прозрачность, и скоро мы её получим. Это Certificate Transparency.
Certificate Transparency
CT — новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал, чтобы браузер им доверял. Вы можете почитать статью с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.
Эти журналы полностью открыты, и любой может посмотреть их, так что если кто-то получит сертификат на ваш сайт, то вы об этом узнаете. Например, здесь вы можете увидеть все сертификаты, выданные на мой домен, и поискать свой собственный. Есть также сервис CertSpotter от sslmate для той же цели, а я использую инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен. Стандарт CT — это фантастическая идея, и я не могу дождаться, когда он станет обязательным, но есть одна оговорка. Дело в том, что CT — это только первый шаг. Знать об этих сертификатах хорошо, но у нас по-прежнему остаются все упомянутые проблемы с их отзывом. Тем не менее, мы можем решать только по одной проблеме за раз, и даже самые лучшие в мире механизмы отзыва неэффективны, если мы не знаем, какие сертификаты нужно отзывать. CT по крайней мере даёт нам эту информацию.
Авторизация центров сертификации
Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:
scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org" Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.
Заключение
В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let's Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.
Для демонстрации проблемы и того, насколько она реальна, попробуйте зайти на новый поддомен, который я открыл на своём сайте, revoked.scotthelme.co.uk. Как вы вероятно догадываетесь, к этому поддомену прикреплён отозванный сертификат, и вполне вероятно, что он нормально загрузится в вашем браузере. Если нет, если ваш браузер выдаст предупреждение об истёкшем сроке действия, то это значит, что ваш браузер по-прежнему отправляет запросы OCSP и вы только что сообщили в CA о том, что посетили мой сайт. Для доказательства, что такая проверка с мягким сбоем бесполезна, можете добавить в
hosts домен ocsp.int-x3.letsencrypt.org с IP-адресом 127.0.0.1 или блокировать его каким-нибудь другим способом — и повторить попытку подключения. На этот раз страница нормально загрузится, потому что проверка отозванного сертификата не сработает, а браузер продолжит загружать страницу. Толку от такой проверки…Я бы хотел закончить статью вопросом: следует ли нам исправлять процедуру отзыва сертификатов? Впрочем, это тема для другой статьи.
Поделиться с друзьями
Bonio
А что если завернуть все запросы к ocsp серверам, например через Tor?
Как вообще к ним происходит запрос, по http? И откуда брать адреса серверов, ocsp.int-x3.letsencrypt.org и т.д. Для разных центров сертификации они разные?
Prototik
Собственно, адрес ocsp указан в промежуточном сертификате CA:
Armleo
Сначало вы говорите, что у вас украли сертификат затем его отозвали и тут же у клиента был MitM то проблема в отзыве сертификата? ШТА? Я чего то пропустил?
fRoStBiT
Сертификаты нужны для защиты от MitM, так?
При этом механизм отзыва не помогает против него. Получается, он не работает.
kogemrka
del
(не увидел, что уже ответили примерно то же самое)
Hardcoin
Если сертификат быстро и надёжно отозвать, то количество обманутых клиентов будет минимально. Не ноль, конечно, но ущерб минимизируется.
serg3ant
Так отзыв не работает, ведь. У меня Google Chrome открывает https://revoked.scotthelme.co.uk/ без предупреждений. Хотя, DigiCert SSL checker показывает что сертификат отозван.
ildarz
Это не отзыв не работает, а у Хрома свой, особый подход к работе с PKI, без соблюдения общепринятых стандартов. Всегда можно написать браузер так, чтобы он работал с косяками. Чем в отношении PKI Гугл успешно и занимается.
me21
Хм, Firefox показывает предупреждение об отзыве.
Добавил ocsp.int-x3.letsencrypt.org с адресом 127.0.0.1 в файл hosts, Firefox всё равно показал предупреждение об отзыве. Он статус сертификата кэширует, что ли?
DistortNeo
Аналогично работает Edge.
Сначала заблокировал OSCP-сервер строчкой в hosts, только потом зашёл на сайт — в Edge открылось без проблем. Затем стёр строчку, и после перезапуска Edge стал ругаться на сайт. Повторный возврат строчки уже ничего не менял, сертификат оставался недействительным.
darkdaskin
А ещё Firefox можно настроить так, чтобы при недоступности OCSP сайты не открывались. Раньше для этого была галка в настройках, теперь только через about:config: security.OCSP.require = true.
Bonio
Да, он запомнил статус до конца сессии. Перезагрузите его и с заблокированным адресом ocsp сайт откроется.
tundrawolf_kiba
Попробовал на своем ПО — касперский предлагает разорвать соединение с этим сайтом, но в принципе позволяет зайти на сайт(в случае, когда активна функция «Защита безопасных соединений и касперский добавляет свой сертификат). Яндекс.Браузер в принципе не пускает на сайт предупреждая о том, что сертификат отозван( кстати, первый раз такую ошибку увидел, в других случаях, с проблемами с сертификатом — позволял войти на свой страх и риск)
mayorovp
Напишу чуть подробнее. Если не учитывать MitM-атаки, то наилучшим алгоритмом для установления защищенного от прослушивания соединения будет протокол Диффи — Хеллмана, который дает возможность установить общий для двух сторон сессионный ключ без какой бы то ни было информации друг о друге. Вот просто берем и устанавливаем соединение, защищенное от прослушивания, поверх открытого канала.
Получается, единственная причина, по которой асимметричное шифрование до сих пор используется для защиты трафика — это защита от MitM. Соответственно, и сценарии атак надо всегда брать с учетом MitM.
pav5000
DH уже используется в https.
mayorovp
Он там используется как дополнительный этап для обеспечения perfect forward secrecy и его сообщения защищаются от подмены при помощи подписей RSA или DSA. Я же говорил что если бы не возможность подмены сообщений — то его можно было бы использовать как самостоятельный алгоритм.
TaHKucT
Проблема в том, что «украли сертификат» можно заменить на «злоумышленник как-то получил доступ к закрытому ключу», например скомпрометировав CA, злоумышленник выпустил себе сертификат для вашего домена, а ваш сервер тут совсем не причем. А ни вы, ни пострадавший CA в данный момент с этим ничего поделать не могут.
Так же вас могли взломать, вы предприняли все меры (изучение пути взлома, нахождение изначальной дыры, ресетап ОС, восстановление данных из бэкапа и выкатка кода без уязвимости), но сертификат условно-говоря был выпущен «только вчера и на год», и вы не можете препятствовать злоумышленнику в том, что бы использовать ваш сертификат в течении года для атаки на ваших пользователей. Да, злоумышленнику помимо сертификата еще необходим способ «вклиниться между ваши и вашими пользователями», и если «ваш сервер теперь точно не содержит уязвимостей» то сделать это не так просто, нужно иметь возможность либо контролировать ваш интернет-канал, что маловероятно, ведь вы «хоститесь в именитом ДЦ с безупречной репутацией», либо канал выхода в интернет ваших пользователей, что тоже маловероятно, ведь «пользователей миллионы и они раскиданы по всему миру и использует десятки тысяч разных аплинков».
А теперь небольшой финт: представляем что под «злоумышленник» мы имеем ввиду не скрипткидди Васю, который поломал вас через старый FTP-сервер скачав пачку эксплойтов с античата, а например какую-то «спец. службу», которой ваш датацент не может отказать в маленькой просьбе «проксировать ваш трафик через их сервер», или 99% ваших пользователей живут в очередной банановой республике, а единственный провайдер этой республики так же не может отказать в аналогичной просьбе этой самой «спец. службе».
И даже CAA на данном этапе вас никак не спасет, ибо на данный момент не обязателен, да к тому же и легко обходиться подделкой ответа DNS с DNS downgrade attack (в случае если используется DNSSEC
Alj
Значит должна быть БД, в которой хранится максимальная дата выпущенного валидного сертификата, все до нее — недействительны, причем она не должна иметь отношения к какому-то CA. И т.д. до бесконечности: как доверять информации в этой БД и не получится ли downgrade attack с этой БД, когда будет возвращаться старая дата.
Armleo
Я осознал свою ошибку. Перестаньте гадить в карму и рейтинг… -20 за два дня :(
blind_oracle
Весь этот PKI фундаментально кривой и продолжает обрастать десятками костылей… Но что-то лучшее мне с трудом видится, разве что блокчейн какой-нибудь
acmnu
Блокчейн медленный вроде, для подобных дел. Проверка должна проходить за 3-7 ms иначе у толковых сайтов (у которых быстрая стартовая страница) начнутся проблемы.
merlin-vrn
DANE
blind_oracle
DANE упирается в DNSSEC, который упирается в регистратора домена, по сути.
Т.е. вместо доверия к CA у нас доверие к регистратору, который может оказаться недобросовестным.
Получается, по сути, та же иерархия доверия (. -> .net -> vasya.net) как в случае PKI.
merlin-vrn
Да, иерархия.
Но во-первых, она с одним-единственным корневым CA — "." (ICANN?).
Во-вторых, она естественным образом сцеплена с самим доменом: чтобы подтвердить валидность сайта на домене, я обращаюсь к тому, кто мне выдал этот домен. Никто больше не может подтвердить. Если замечены какие-то проблемы, очевидно, кто виноват (и что делать).
Downgrade? Где? "." подписан, я это знаю заранее. Если в подписанном ответе от "." сказано, что ".com" имеет DNSSEC (а там сказано и он имеет), но мой ближайший ресолвер упорно утверждает, что записей DS и тому подобных для ".com" нет — я сразу знаю, что больше этим ближайшим ресолвером пользоваться нельзя. И далее, раз ".com" утверждает, что «google.com» имеет DNSSEC (а он имеет), то я либо получу от него ответ с подписью, либо — кто-то чудит in the middle.
Downgrade невозможен, потому, что "." подписан и говорит нам, где подписи должны быть.
Сейчас — валидность сайта на домене «a.b» подтверждают совершенно левые конторы, которые к этим доменным именам вообще никакого отношения не имеют и лишь по какому-то недоразумению есть в моём браузере в списке доверенных. Любой может подтвердить валидность любого домена, и для отвода глаз от этой проблемы даже придумали принципиально неработоспособный изврат под названием «certificate transparency» (это замок от честных людей, а если я плохой парень, я просто ничего в этот список заносить не буду).
blind_oracle
Да, я согласен что мест где можно устроить атаку тут гораздо меньше чем в классическом PKI.
Но тут тоже свои проблемы — тот же гугл почему не любит DANE? Потому что они хотят отказаться от ключей в 1024 бита, а они в DNSSEC вовсю используются, получается эдакий откат назад в плане безопасности.
merlin-vrn
Э… минутку,
. 10800 IN RRSIG NSEC 8 0 86400 20170722050000 20170709040000 15768. CRmIEhuvHuAJAVQQoL20sq/x4pHxnXDGyWF9hEW/UNwO8z1nTe1W7oVN EorQQ28dbwvZ2W8w2spxujZjMT4bTD3B8car2TfBftgsJb8XSUMGfMcC 26mB5usgIMXHOtXAXBxi4Ib6hX+zalFMnCgrN5t9dUCOhC3F1q+1eHrH tmXNjtx7h+azudjtB04901fcdDjg9gkS2PU1ekKdoJRJC/M2dCsHx5U4 q0YfW6duBbPDByoCrP/hfNsudbycpPum+oE9+mDDzlyudHm8Ph+tGoUR EyRwHFTbkHFXW0IwimNJjkeNz+OiuL1kdpYvbQLHooQcD9j+5oFKZDdP fz4vUg==
Это «2048» (на самом деле, [348 *4/3 -2 ] * 8=2072) бит, насколько я могу посчитать. Или я что-то не понимаю?
merlin-vrn
Э… ну да, я дурак, пробелы посчитал посередине. Ровно (344*3/4-2)*8=2048
blind_oracle
Я не говорю что там только они, для своего домена я 2048 использую, но их много. И до конца 2016 года даже корень(!) был подписан 1024-битным ключом…
Тут вступает в противоречие тот факт, что DNS в основном использует UDP (с fallback на TCP), который при использовании ключей большого размера придется фрагментировать на уровне IP, а многие сети нынче вообще запрещают фрагментированные IP-пакеты.
При MTU 1500 и 2048 ключах эта проблема, вроде бы, не особо проявляется, но MTU много где бывает и поменьше (туннели всякие и т.п.)
Интересные ссылки на тему:
https://blog.verisign.com/security/increasing-the-strength-of-the-zone-signing-key-for-the-root-zone/
http://keysizetest.verisignlabs.com/
merlin-vrn
В общем, на мой взгляд, повсеместное проталкивание HTTPS — это хорошо, да не очень. Пока его надёжность основана на кривой инфраструктуре PKI, он будет создавать только иллюзию безопасности.
Почему бы не продвигать развитие DANE вместе с внедрением HTTPS — не понимаю.
mayorovp
В теории все хорошо, но для того чтобы это заработало — нужны списки исключений от подобной проверки, и массовое осознание что неправильно настроенный DNSSEC — это так же серьезно как кривой сертификат.
Потому что сейчас достаточно одного важного сайта с кривыми записями DNS, чтобы отвадить его пользователей от попыток включения DNSSEC. Для меня, например, таким сайтом стал ЛК интернет-провайдера: включив проверку DNSSEC я не смогу заплатить за интернет. И настройки "не проверять DNSSEC в зоне такой-то" — нет...
merlin-vrn
Чем вы таким включали проверку? Я максимум дорос до плагина TLSA Validator, который мне показывает иконку в строке браузера — «ОК» или «Не ОК». Ничего никто не блокирует, просто уведомляет.
mayorovp
Прочитал что так можно сделать, написал и внезапно обнаружил, что проблемы поддержки DNSSEC в мире теперь оказались моими проблемами — половина сайтов перестала открываться :-)
blind_oracle
Ты что-то делаешь не так. У меня BIND в качестве домашнего резолвера с такими настройками и все работает без проблем много лет. Ищи проблему в другом месте.
mayorovp
Разумеется, проблема в другом месте! Я даже знаю где — в кривой подписи DNSSEC тех самых неоткрывающихся сайтов. В числе которых — ЛК провайдера.
Проблема в том, что когда я прописал те строчки — эта проблема внезапно стала моей проблемой.
avost
Вы полагаете, такая централизация — хорошая идея? Особенно, в случае ICANN — недавно была статья, как путём нехитрой манипуляции целая страна лишилась контроля над собственным географическим доменом. И, хуже того, когда всё выяснилось, ICANN ни как не исправила свою ошибку.
merlin-vrn
Так у них и так уже есть такой контроль. А мы доверяем защищённость (и доступность) нашего сайта ещё кому-то (не отбирая у ICANN).
Уж лучше пусть только ICANN, чем ICANN и кто-то ещё.
avost
Нет у них такой функции. У них есть контроль над небольшой группой доменов. И то даже эту функцию они выполняют из рук вон плохо. И если с СА есть хотя бы механизмы и отзывов и признания целых СА недобросовестными, то и ICANNом и механизмов нет и они уже недобросовестные (отказались исправлять собственную ошибку), то есть если они начнут перевыдавать ваши сертификаты мошенникам, вы с этим ничего не сможете сделать вообще.
mayorovp
Они и сейчас могут, теоретически, отобрать у вас ваш домен, после чего злоумышленник получит на свой новый домен сертификат. И вы с этим точно так же ничего не сможете сделать.
avost
И поэтому что? Пусть отбирают ещё более простым способом? Странная логика. Я думал сообщество заинтересовано в нахождении решения проблемы, а тут предлагается её усугубить. Логическим продолжением будет отказ производителей браузеров поддерживать бесполезный механизм вообще.
mayorovp
Почему вы, сравнивая два абсолютно одинаковых способа, находите второй более простым?
avost
Потому что это единая точка отказа.
Ни одной проблемы таким образом не решается, а уязвимость механизма повышается. Зачем?
mayorovp
Ну а сейчас единых точек отказа — две.
merlin-vrn
Ненависть у человека именно к ICANN, настолько, что куча авторизованных центров кажутся меньшим злом.
Ну, тут только Namecoin или другие блокчейны помогут, распределённая структура.
avost
Ну, это не совсем так. Даже корневых серверов дюжина, это с одной стороны (да и без них система будет работать, к тому же даже они не принадлежат icann). А с другой — СА тоже довольно много. Что-то может отваливаться, но бОльшая часть будет работать и работоспособность отвалившейся части можно оперативно восстанавливать. С единой точкой отказа это не так.
Ненависть здесь не при чём. Существующая структура не по-настоящему распределённая, но, да, куда меньшее зло, чем централизация всего в одном месте. К тому же, изрядно сомнительном.
mayorovp
Имелись в виду организационные точки отказа. Если все перейдут на DANA — то в ICANN кто-то вдруг может принять решение что ваш домен не домен и все перестанет работать.
Сейчас же может произойти то же самое, плюс разработчики браузеров могут принять решение что ваш корневой CA больше не CA. Таким образом, единых точек отказа сейчас две.
avost
Конечно же не! вы можете без труда поменять CA и спокойно продолжать работать. Сейчас. Таким образом это не единая точка отказа вообще. По вашей же схеме — алес леталис.
merlin-vrn
Они в корне всей этой структуры DNS. Значит, рули у них.
Movimento5Litri
Которые не работают в Chrome потому что Google наср@ть
Ага, только за одни и те-же действия CA могут признать или не признать недобросовестным в зависимости от того американский он или китайский
zuborg
Куда бы мы не перенесли зону ответственности — она остается точкой отказа.
От пассивного прослушивания мы защищаться научились хорошо, проблема в активном вмешательстве в трафик, а эта возможность есть у всех провайдеров. Можно записать отпечаток сертификата в какой-то DSN-record, чтобы подтвердить, что сертификат не поддельный, но это не поможет, если атакующий подменит DNS ответ. Он может внедрить https-прокси, поддельный DNS, заблокировать трафик проверки и т.д. и т.п.
Решение этой проблемы, тем не менее, есть — распределенная структура. Возможно, что-то на основе блокчейн — изменения в сертификатах происходят все-таки реже, чем переводы денег через bitcoin.
Сейчас каждый сертификат выдается одним CA. Его компроментация, блокирование на уровне провайдера или просто отказ вызывает проблемы. А вот если сертификат подписан десятком СА или блокчейном, то подменить его или заблокировать проверку отзыва уже не получится.
merlin-vrn
Поможет, если этот DNS-ответ подписан DNSSEC. Корневая точка доверия в этом случае — зона ".", открытые ключи которой уже есть в каждой ОС.
Безопасность DANE и конкретно TLSA с указанием сертификата, о которых речь, базируется на DNSSEC.
Mendel
Если атакующий подменит ДНС, то вообще ничего не поможет. Совсем. Я выше уже писал.
Alj
В середине статьи вы беспокоитесь о том, что центр сертификации узнает имя домена, которое вы посещаете, но при TLS SNI вы все равно выдаете всем желающим MansITM имя посещаемого домена.
Почему бы домену не иметь возможность самостоятельно отзыва сертификата, например, через DNS. Как в почте: SPF\DKIM\DMARC. Создали запись _invalidSSL IN TXT «идентификатор (слепок) утекшего сертификата;...» и в совокупности с DNSSEC — все будет хорошо. А как закончился срок действия — запись можно убрать.
acmnu
DNSSEC не так распространнен, как хотелось бы, а просто DNS концептуально ровно тем же уязвимостям подвержен.
TaHKucT
Не всем желающим, а только тем, через кого пойдет трафик. И это можно «вынужденная мера», без которой сложно обойтись. Сравнивать это с «добровольным оповещением разных CA о посещаемых сайтах» несколько некорректно. Ведь и ip-адреса мы «отдаем всем на пути трафика», но при этом передача «на сторону» этих же ip-адресов (клиента и сервера) не приветствуется всеми параноиками мира (мягко говоря).
Проблема с DNSSEC: он мало распространен и подвержен downgrade attack'ам. А избавление от этих проблем сломает обратную совместимость очень многих вещей. Уж легче браузеры (как основные потребители шифрованного трафика на основе публичных сертификатов) допилить, чем полностью перейти на DNSSEC кмк.
Alj
Именно, не всем желающим, а «всем желающим MansITM» — т.е. тем, кто, как минимум, слушает ваш трафик. И, включая паранойю, это совсем не транзитные маршрутизаторы.
Сложно, но совсем не «вынужденная мера», т.к. реализовать один сайт — один IP в IPv6 (который всё никак не взлетит, в этом и сложность) — проблем нет, тогда и SNI не нужен.
dartraiden
Alj
Все же не решить, а смягчить угрозу. Слишком сложно, тем более name of front server будет известно.
konchok
Проверку валидности надо делать через DNS — повесить там TXT запись, например, с хешем валидного сертификата. Элементарно, быстро, просто. К чему все эти конструкции из буханок?
merlin-vrn
Я писал уже выше. DANE.
Без DNSSEC я (MitM) могу подделать DNS-ответ и вписать TXT с хешем любого сертификата, который подсуну клиенту через веб. А DNSSEC переносит точку доверия в подпись корневого домена ".". Т.е. у нас как бы принципиально один корневой центр сертификации.
konchok
Ну есть ещё dnscrypt, никто не мешает его встроить в браузер, раз такие дела. И сравнивать что получено по открытому каналу и шифрованному.
merlin-vrn
Вопрос в том, как удостоверить, что шифрованный канал я устанавливаю с настоящим владельцем сайта, а не с тем же MitM?
konchok
Dnscrypt устанавливает канал со своими подписанными серверами, список имеется. Можно и свой поднять при желании. Да достаточно чтобы 8.8.8.8 начал это поддерживать.
merlin-vrn
Т.е. я опять должен доверять некоей левой конторе, которая к моему домену никакого отношения не имеет. Это, собственно, сегодняшний PKI и есть.
konchok
Доверять так или иначе все равно кому-то придётся. Просто надо сделать доверие не «да/нет» а как со спамом в виде некоего индекса, зависящего от разных проверок. Типа 0-1 зелёненький, потом жёлтенький и больше 5 считаем что доверять не стоит.
merlin-vrn
Доверие — штука такая, как бумага, раз помял — никогда идеально ровным не будет.
Доверие может быть только бинарным. Никаких промежуточных вариантов.
konchok
Абсолютно доверие в интернете? Вот самим-то не смешно? Не на существующих технологиях, однозначно.
mxms
dnscrypt как и стандартизированный DNS-over-TLS шифрует сам трафик, что не заменяет механизма цифровых подписей DNSSEC. И если последний в последнее время стал получать активное распространение, то первые два ещё крайне далеки от этого.
konchok
Он не просто шифрует трафик а ещё проверяет подлинность сервера. С TLS естественно ровно та же проблема что и с HTTPS — сертификат и его валидность. Должно быть несколько параллельных механизмов проверки, тогда сравнив полученное можно сделать оценку насколько результату можно доверять.
mxms
Разумеется.
И это верно, однако тут есть DANE, что замыкает проблему на саму же DNS.
ildarz
Это, простите, паранойя в чистом виде и по важности плетется где-то в самом-самом конце всех проблем с PKI. Потому что «некая третья сторона» сидит в списке доверенных корневых сертификатов и, теоретически, способна на несравнимо большие злоупотребления, нежели узнавание имени части хостов, которые вы посетили.
TaHKucT
Оно как бы да, но если «несравнимо большие злоупотребления» можно относительно легко отследить через тот же Certificate Transparency (или в скором времени можно будет отследить), то «отследить сливание данных о посещенных вами сайтах» можно будет только по косвенным признакам и то не 100%… еще и в зависимости от того, кому и для чего эти данные будут сливаться. А если посмотреть на историю человечества, то можно легко убедиться что если кому-то дать возможность чем-то злоупотребить, то эта возможность будет использована для злоупотребления, и вопрос только во времени (когда в руководству этими структурами придут «плохие парни», когда данную структуру получиться взломать, когда эти данные окажутся в паблике из-за технической ошибки и еще миллион возможных вариантов).
Решением может быть «дать людям возможность создавать свои сервера проверки отозванных сертификатов» (как это сейчас с DNS-серверами, когда рекурсивный DNS может поднять каждый и использовать его не боясь что он сливает данные куда-то), но в существующей системе это будет выглядеть как костыль, который с одной стороны сложно внедрить, а с другой мало кто будет использовать. Как мне видится лучшее решение: развитие в сторону OCSP Stapling.
ildarz
Вы на такси когда-нибудь ездили? А права у таксистов проверяете? А машину шмонаете на предмет наличия оружия, а по базе ГИБДД не проверяете, не в угоне ли, а самого водителя не пробиваете — а вдруг преступник? Думаю, нет. А между тем тут на кону ваша жизнь и здоровье, а не просто какой-то там список посещенных вами сайтов. Вот что за выверт в мозгах у части айтишников происходит при переходе из реальной жизни в инет, что включается подобная степень паранойи? И это несмотря на то, что риски в реальной жизни куда выше.
Ну и стоит помнить, что ваш провайдер к вам куда ближе и знает о вашем трафике куда как побольше, чем любой OCSP.
TaHKucT
Не забывайте что в текущих реалиях вы часто можете выбрать себе провайдера самостоятельно. Причем не обязательно что-бы этот провайдер «присутствовал» в вашем доме, районе или даже стране, гнать весь трафик через тот же vpn не так сложно, а единственный недостаток: слегка возросший пинг и по первости youtube неревелантные вещи в топе показывает.
ildarz
Деформация — да, профессиональная ли — большой вопрос, потому что настолько искаженная оценка рисков является скорее признаком низкого профессионализма, чем высокого. И уж в любом случае — если человек сам понимает, что это деформация, так её исправлять надо, а не аргументировать ей что-либо.
А какая разница, если у вас в любом случае нет никакого контроля за тем, что он будет делать с проходящим через него вашим трафиком? ;)
sumanai
В интернете осуществлять контроль проще, чем в реальности. Настроил и забыл. А в реальности пришлось бы повторять проверки каждый раз, тратить своё время с риском ошибиться.
ildarz
Контроль чего именно вы собираетесь "настроить и забыть" применительно к обсуждаемой ситуации?
sumanai
Тот же OCSP.
avost
Ну, как вам сказать. У нас когда-то были такие Ока-такси — маленькие жёлтые машинки. Я тогда как раз ногу сломал и был вынужден пользоваться такси. Один раз ехал на этой ока-такси. Большего страха я в жизни не испытывал :). И больше на таких не ездил. Так, что мимо. Минимально необходимая проверка есть.
Видите ли в чём дело. На том же кону жизнь и здоровье водителя этого такси. Что слегка нивелирует проблему.
А вот тут игра в одни ворота. Причём в современных российских реалиях это куда бОльшая потенциальная угроза и здоровью и жизни, которым не способствуют лагеря в которые можно легко залетесть с нашим непредсказуемым законодательством.
Именно так и ни как не иначе. Дело в том, что эта часть айтишников, судя по всему, несколько умнее другой части и способна использовать голову не только для того, чтобы писать пхп уеб сайты, но и для построения прогностических моделей и предпринятия превентивных действий для снижения потенциального ущерба. Да, модели строятся изрядно пессимистичские, но, как показывает практика, не так уж сильно — реальность госдуры уделывает иногда и самые пессимистичные прогнозы. Ну, а программист обязан думать о худших из возможных сценариях. Тем более, в этой сфере достаточно легко защитится чисто технически, чего не скажешь о такси.
ildarz
Отлично. Вы очень наглядно этим примером подтвердили мои слова — в жизни вы действуете по правилу "доверяем по умолчанию" (сели же в это такси, правда?), и только в случае возникновения проблем начинаете не доверять. И о чем спорите? :)
Какое отношение российские реалии имеют к OCSP?
Угу. О завышенной самооценке части айтишников тоже сказано немало и в самых разных местах.
avost
Нет, не так. БОльшая часть айтишников несколько умнее одноклеточных, способных действовать исключительно по единственному раз и навсегда заданному сценарию. Когда нет возможности использовать "план А", переходим к "плану Б". Что не так? Обычный условный оператор. Для кого-то слишком сложно? Ну, извините!
Есть российские CA…
Это не наши проблемы :)
Mendel
Вы сели в этот ока-мобиль. И больше в него не сядете. Молодцы?
Неа. Просто повезло. Завтра вы сядете в другой ока-мобиль от другого оператора такси. И погибнете в ДТП по причине низкого качества автомобиля и водителя.
Помогла ваша стратегия? Нет.
Если бы увидев ока-мобиль вы бы не сели, то да. Все было бы правильно.
Недавно случай был. Собирались на дачу. Двумя машинами. В одной сидели двое. Во второй все остальные. Просто бойфренд тёщи взял машину дочки, а там ремней на заднем сидении не было. Хотели кого-то с заднего сидения у нас пересадить ибо четыре человека тесно, но нет ремней и нет, ехали вчетвером (два детских кресла, один подросток и его мать) ибо ремней хватало. Да, в следующий раз в этой же машине уже были ремни. Дяденьке было неудобно что дети (т.е. мы) на него ворчали, и он их таки нашел и прикрутил).
В Украине за ремни не штрафуют от слова совсем. И никто не пристегивается. Но там где нет ремней — мы не ездим. И если кто-то садится в нашу машину, то он должен пристегнуться.
С непристегнутыми не ездим. И все знакомые начинают с ворчания и пристегивания если садятся. Уже знают…
И да, мы не излишне правильные, у нас тоже хватает косяков с безопасностью. Я просто про вот эту вот глупость с «я больше не поеду значит защищен».
merlin-vrn
Я вот не понимаю, зачем нужны все эти OCSP Staple в автоматизированной инфраструктуре типа LetsEncrypt.
Они точно так же подписаны неким доверенным центром сертификации, соответственно, принципиально не отличаются от сертификатов. Если для них использовать менее надёжные алгоритмы — мы скомпрометируем сам сертификат, другими словами, нагрузка на серверы CA от потока запросов на OCSP Staple и на получение нового сертификата (пусть даже со старым приватным ключом) не должна сильно отличаться.
Таким образом, можно было бы ограничить сроки действия самих сертификатов, скажем, неделей — и отказаться вообще от использования OCSP и CRL как таковых, полностью решив проблему, описанную в топике.
Revertis
mayorovp
Выпуск сертификата чем-то отличается по сложности от выпуска OCSP ответа?
merlin-vrn
Да я собственно о том и пишу, что не вижу, с какой бы стати увеличилась нагрузка. Какая разница, что они будут выдавать — новые сертификаты или OCSP Staple для старых, раз и там, и там — одна и та же электронная подпись одним и тем же алгоритмом, т.е. вычислительно — один к одному?
navion
Нет браузера кроме Хрома?
Yngvie
Есть, только у них пользователей меньше.
Кстати, я думал что такая проверка идет из Chromium, поэтому проверил сразу и в Хроме и в Опере (46). Так Опера проверила сертификат и не дала зайти на сайт. А у Хрома вполне себе зеленый замочек как у валидного HTTPS.
И даже Edge не позволил зайти
Error Code: ERROR_INTERNET_SEC_CERT_REVOKEDTaHKucT
Chromium 59 из ubuntu 16.04 (точнее Mint 18.2) — открылся без предупреждений.
pyrk2142
Есть ещё Safari в IOS, сайт загрузился без предупреждений.
antoo
С десктопного Safari ситуация аналогичная.
Yngvie
Не туда ответил
mr_tron
Как-то очень много безопасности завязано на DNS. А вся безопасность днс обязательно имеет критическое неподконтрольное звено — админка регистратора.
mxms
На DNS весь интернет завязан, так что это данность. Главная же проблема с ним на сегодня это то, что весь DNS-трафик передаётся в открытом виде что на общем фоне выглядит как неприемлемый анахронизм. Несмотря на наличие стандарта DNS-over-TLS и наличие его поддержки в основном серверном софте активности во внедрении шифрования DNS-трафика как-то не наблюдается.
remme
Один из альтернативных вариантов — это управление сертификатами с помощью блокчейн, например EmerSSL. Мы разрабатываем похожий вариант, но только информация в блокчейн добавляется только при отзыве сертификата. И таким образом локальная блокчейн нода может заменить OCSP.
Mendel
Давным-давно у меня был доступ к основной учетке одного регистратора которой он подписывал все запросы в реестр. Писал софт этому регистратору, и софт должен был именно главной учеткой подписывать.
Ну и собственно если представить что я тогда хотел бы атаковать кого-то из клиентов того регистратора, то я вполне мог подменить НС жертвы на свои, там заменить А запись на свой сервер где проксировал бы все запросы кроме обращений из AS какого-то CA который каким-то образом (ДНС или файл или еще чего) проверял бы мои права на домен перед выдачей мне сертификата.
В принципе ничто не мешало мне и емайл подменить таким образом, но частенько емайл и так привасипротектед так что идентифиткация по мылу тут мало поможет.
Ну а теперь всем хейтерам отзывов через DNS у меня вопрос. Если сейчас И ТАК тот кто имеет доступ к ДНС может провести МИТМ, то в чем проблема сократить количество потенциальных атакующих до списка тех кто имеет доступ к днс/хуиз? CA не защитят от регистраторов, реестров, иканн и т.п. Но тоже могут атаковать…
merlin-vrn
Вот выше там товарищ не понимает, что отнять всё у DNS-структуры ICANN не выйдет, поэтому лучше наоборот всё отдать в DNS и отнять у всех остальных, чтобы ответственных был один, а не великое множество.
Конечно, блокчейн, но и там ведь есть угроза 51%…
mr_tron
ой лол. как угроза 51% относится к блокчейну для хранения днс записей? это аффектирует только их передачу и решается на раз. там другая проблема — замена юридического владения техническим. сперли у гугла приватник и весь бизнес в трубу
merlin-vrn
конкретно в namecoin владелец 51% сможет блокировать регистрацию и продление любых имён, не включая в блоки соответствующие транзакции, и соответственно их (имена) перехватывать
Oval
А я вот лежу и думаю, что любой может выпустить сертификат на сайт мелкого пошиба, по крайней мере, через MitM и подмену ответа стандартного http запроса на 80 порту /.well-known/acme-challenge от Letsencrypt-a.
Alj
Совсем не любой. Как вы собрались вклиниваться между LetsEncrypt и атакуемым доменом?
Ес-но хостер, на чей IP указывает домен, гипотетически может; и любой, кто получит доступ к NS домена.
А вот если вы найдете дыру в сайте и сможете загружать файлы, то можно разместить подтверждение (в ручном режиме тоже есть возможность получить сертификат LetsEncrypt) в /.well-known/acme-challenge и получить сертификат. Но зачем так делать для «сайта мелкого пошиба»…
ElijahCapricorn
Однажды разрабатывал механизм для проверки отозванных сертификатов в одном коробочном продукте для управления Active Directory. Помимо проблем с доступностью и обновлением списков CRL, винда по умолчанию ещё и кэширует эти списки, как на уровне машины, так и на уровне .NET процесса. В самом худшем случае, может пройти неделя прежде чем пользователь узнает об отзыве сертификата.
BenjaminB
Очень подробная и интересная статья. Сам только в этом году перешел на использование сертификатов от comodo. Многие даже не задумываются об их пользе и эффективности.
Даже не знал, что ssl сертификат помогает продвижению сайта в гугле. но набрел на интересный пост, правда на английском Увеличение Ранка в результатах поиска. Многие вещи в безопасности сайта мы вообще не знаем и не понимаем пока случайно о них не прочтем.
Mendel
Коммент про комодо в статье начинающейся с летсенкрипт. Написан новорегом. Ссылается на городскую историю о пользе хттпс для сео. Спамеры такие спамеры…
BenjaminB
Уважаемый Mendel, я не знаю где вы увидели комментарий про комодо или его рекламу, Могу с таким же успехом написать что использую сертификаты геотраст и let's encrypt в том числе. И они НЕ менее безопасны. Их точно так же рекомендую. Я лишь поделился своим мнением о новости которую прочел о увеличении ранка сайтов.
Mendel
Улучшение позиций от хттпс — миф. Опровергается и самим гуглом и реальными кейсами сеошников.
Есть незначительный плюс за счет поведенческого ибо сейчас давление на хттп-сайты с зачеркнутыми замочками и т.п. Соответственно ПФ при переходе улучшается. Итого — миф о позициях + упоминание платного сертификата в контексте где уместен бесплатный. Смущает, да.
MrRitm
В комментариях к статье несколько раз мелькало слово «блокчейн», но почему-то было сказано, что это медленно. ИМХО если развить тему, то можно сделать так, чтобы было быстро. Например просим инфу о домене по некоторым правилам у соседей. Правила типа «Спрашивать не более чем у N узлов И не менее M должны быть не в моей подсети (рандом)». Т.е. я могу удостовериться, что работаю с правильным узлом по защищенному соединению и поручились за это 3 пользовательских машины 2 из которых в соседнем кабинете, а 1 непойми где на планете. Иными словами я получил 3 подтверждения 2 из которых менее чем за 1ms, и 1 за 3-7ms
В таком случае «злоумышленнику» придется скомпрометировать всю мою подсеть и какое-то одно рандомное устройство из нескольких миллиардов.
Опять-же что касается скорости: скорость каналов связи растет, количество каналов тоже. Объективно сейчас нет проблем со скоростью доставки информации. Скорее теперь уже компьютеры «на местах» не успевают обрабатывать полученное т.к. не все ежегодно апгрейдятся.
merlin-vrn
Вы, простите, такую ахинею написали, явно не знаете, как работает блокчейн.
Медленно в блокчейне не запрос, а добавление/обновление записей. Запросы делаются фактически локально, обновление/добавление — требует сетевого консенсуса, который набирается путём выстраивания цепочки блоков. Новый блок в среднем добавляется раз в десять минут, считается, что для уверенности нужно набрать шесть блоков; таким образом, минимальное время обновления/добавления (лаг) — час. Для HA-сервисов средствами DNS точно не подходит.
Кроме того, объём блока ограничен, кажется, 1 мб. Если средний размер транзакции 500 байт (для неймкоин), это значит, что за десять минут вся сеть может сделать максимум 2000 изменений. Представьте себе, что весь DNS в мире обновляется со скоростью 3 изменения в секунду. Медленно.
Есть у неймкойн средства несколько облегчить проблему, но суть не меняется. А именно, можно грубо говоря там только делегировать домен на традиционный DNS-сервер с DNSSEC, и все быстрые динамические изменения производить уже на нём. Таким образом, якоря доверия будут находиться в блокчейне, а далее — одно-два звена по цепочке DNSSEC.
MrRitm
Да, видимо не понял сути реализации блокчейна. Каюсь. Собственно я и комментарий написал в надежде на пояснения. Спасибо, теперь стало понятнее. Тем не менее, думается мне, что решение описанных в статье проблем надо искать в том, чтобы как-то уйти от централизации которая появляется при использовании центров сертификации. Да и DNS в том виде как он есть сейчас тоже заменить бы. А то блокируют тут всякое по чем зря…
Как объяснял «на пальцах» один уважаемый (мною) человек суть сертификатов: «В какой-то момент ушлые парни решили, что надо сделать бизнес на том, что поручаться за надежность того или иного ресурса и брать с хозяина ресурса плату». А кто сказал, что этим поручителям изначально можно верить? Историю с WoSIgn все помнят?
Mendel
откуда вот прям 10 минут? Почему мегабайт?
При чем тут шесть подтверждений?
Вы путаете блокчейн с конкретной реализацией (биткоин?).
Закладывайте ту частоту которая вам реально нужна. Используйте не подтверждение работой а другой алгоритм. Указывайте тот размер блока какой вам нужен. Это совсем не ограничение блокчейна а лишь конкретной реализации.
Далее — ожидание дести подтверждений тут вообще не в тему. Зачем нужны подтверждения? Чтобы избежать двойной траты. Если же мы говорим о транзакциях «сертификат недействителен» или «новый NS домена такой-то» или даже напрямую новое значение А-записи такое-то, то зачем нам ждать? Транзакция подписана? Подписана. Авторизованным отправителем? Авторизованным (владельцем домена, администратором CA, не суть). Всё. Опасности что он выпустит другую конкурирующую информацию тут нет, ибо в деньгах у нас двойная запись — ушло из одного места, пришло в другое. Вот это ушло работает только когда там что-то есть, поэтому мы боимся двойных трат. А тут запись одинарная, ничего нигде не уходит, так что одного подтверждения более чем достаточно. Более чем. А реально хватит и нуля.
Подтверждения нужны для передачи владения (например смены подписи владельца) и других операциях где потенциальная отмена операции в связи с непопаданием в блок или форком — может вызвать проблемы.
А операции отзыва сертификата можно брать сразу из ожидающих транзакций, что в зависимости от вашей связности может занять от секунд, до времени ожидания подтверждения (Которое можно сделать допустим в минуту).
Изменение ДНС/IP — тут уже от доверия зависит. Если протокол шифрованный, имеет доверенный сертификат (из того же блокчейн), то нет проблем и сырое брать. Если не шифрованный, то можно слегка сомневаться, но тоже сомнения очень иллюзорны.
merlin-vrn
Я же прямо написал, что указанное касается именно namecoin. От биткойна считай отличается только тем, как ведёт себя с «намайненными» средствами и требованием уникальности.
Давайте и вы напишете, какую вы конкретно реализацию имеете ввиду, в которой нет всех этих особенностей.
Mendel
Я никакую реализацию не имею ввиду, поскольку это вопрос не технического толка а организационного. Никто вот так в криптоанархическую вольницу систему ДНС Интернета не отдаст.
Я лишь озвучил что все названные вами ограничения являются не ограничением блокчейна, а именно конкретной реализации.
Существуют например блокчейны с декларативным доверием где не просто другой тип подтверждения отличный от PoW а просто нет подтверждения. Я говорю о блокчейнах внутри одной компании и ее партнеров. Например блокчейны для контроля целостности распределенной базы банковских филиалов.
В нашем случае ноды могут быть подконтрольны ИКАН и им не нужно будет конкурировать за право подписи. Что заметно уменьшит нагрузку. Но даже если система полностью децентрализованна — все константы типа размера блока, частоты его выпуска и т.п. — просто константы, а не ограничения протокола. Ничто не мешает сделать форк неймкоина с блоков в 10мб.
proea
даже тут пишет, что сертификат не отозван
https://crt.sh/?q=revoked.scotthelme.co.uk
Mendel
Я никакую реализацию не имею ввиду, поскольку это вопрос не технического толка а организационного. Никто вот так в криптоанархическую вольницу систему ДНС Интернета не отдаст.
Я лишь озвучил что все названные вами ограничения являются не ограничением блокчейна, а именно конкретной реализации.
Существуют например блокчейны с декларативным доверием где не просто другой тип подтверждения отличный от PoW а просто нет подтверждения. Я говорю о блокчейнах внутри одной компании и ее партнеров. Например блокчейны для контроля целостности распределенной базы банковских филиалов.
В нашем случае ноды могут быть подконтрольны ИКАН и им не нужно будет конкурировать за право подписи. Что заметно уменьшит нагрузку. Но даже если система полностью децентрализованна — все константы типа размера блока, частоты его выпуска и т.п. — просто константы, а не ограничения протокола. Ничто не мешает сделать форк неймкоина с блоков в 10мб.
Mendel
Скажите, я правильно понимаю что протокол Certificate Transparency позволяет любому скачать полный лог всех сертификатов, без всяких специальных доступов и т.п.? Или только вопрос-ответ, по конкретному домену?
TaHKucT
faq
То есть, судя по FAQ, любой (в том числе и вы) можете поднять свой «лог-сервер» и следить за всеми сертификатами, которые добавлены в этот лог. А если не хотите морочится, то можете воспользоваться любым сервисом, которому лично вы доверяете… когда они появятся.
Mendel
Меня интересует не поднять свой лог, а скачать чужой.
а еще конкретнее — список доменов у которых есть/был SSL.
А еще конкретнее — список доменов… у многих зон список доменов — закрытая информация, которая недоступна даже регистраторам. Такой большой список доменов (при все возрастающем покрытии доменов HTTPS) значительно улучшит любую базу доменов.
Я сторонник того чтобы списки доменов были публичные (или условно доступные как у доткома, где на публику не выкладывают но у всех кому надо они есть). Так что прям потенциальной уязвимостью я бы не назвал, а вот полезной инфой…
TaHKucT
Скачать в txt формате пожатые зипом, разложенные по зонам, списки доменов, а не их сертификатов и все такое — сильно сомневаюсь. Либо сами парсите логи, общественно доступные логи, либо покупаете у тех, кто это для вас уже сделал.
Mendel
Да распарсить логи сертификатов это дело плевое. У меня вопрос по протоколу — можно ли выкачать протокол целиком и вычленить из него список или инфа получается только для одного домена.
15 минут гуглежа внятного ответа не дали, только общие фразы.
Мне много не надо. Для начала и пары бит ответа хватит. Типа:
1) Да, можно скачать лог любому человеку. В логе читабельный формат или бинарный но имена доменов не шифрованы.
2) Нет, скачать можно, но криптографически сделано так что нужно знать домен чтобы найти соответствие ему (например везде мд5 от домена идет)
3) Нет, скачать нельзя. Только запросы.
4) Нет, скачать можно, но не всем а только избранным.
Ну как-то так.