Как ранее сообщалось на GeekTimes, EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust и исследователей из Мичиганского университета (University of Michigan) создали новый некоммерческий центр сертификации (Certificate Authority) Let's Encrypt [1]. Целью проекта является ускорение перехода всемирной паутины от HTTP к HTTPS.
В чём суть?
Как сказано в [2], несмотря на то, что HTTP получил огромное распространение (что является признаком успешного протокола), его недостатком является небезопасность (открытость передаваемых данных) by-design. Всякий раз, когда пользователь подключается к сайту по HTTP, он подвержен ряду потенциальных проблем, таких как угон аккаунтов, перехват трафика, отслеживание государственными и коммерческими организациями, встраиванию зловредного кода (скриптов) в код страниц, цензуре.
Исследователи отмечают, что HTTPS, хотя не является панацеей, решает эти проблемы, поэтому переход на повсеместное его применение является важной задачей.
Проект планируется к запуску летом (в июне?) 2015. Let's Encrypt будет автоматически выпускать бесплатные сертификаты для любого запросившего их сайта. Планируется. что переключение с HTTP на HTTPS при использовании этого сервиса будет производится подачей всего одной команды или нажатия кнопки (облачные технологии — автоматизация в массы).
Здесь необходимо отметить, что самыми значительными проблемами при развёртывании HTTPS исследователи считают сложность, бюрократию и стоимость сертификатов, необходимых для работы HTTPS. Многие пользователи не раз сталкивались с предупреждениями и ошибками получаемыми в результате проблем с сертификатами.
Процедура получения сертификата бюрократична, сложна и является ведущей причиной того, что сайты продолжают использовать HTTP вместо HTTPS.
Одной из целей проекта Let's Encrypt является исключение лишних звеньев и автоматизация процесса, что, по неформальным замерам разработчиков даст снижение времени настройки шифрования с 1-3 часов до 20-30 секунд.
В основе проекта лежит ряд новаторских подходов и технологий для управления безопасной автоматической верификацией доменов и выпуска сертификатов. Для этого планируется использовать разработанный для этих целей протокол ACME между web-сервером и CA. Верификация будет, в том числе, использовать сервисы SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google).
Для функционирования нового CA создаётся новая некоммерческая организация Internet Security Research Group (ISRG).
Как это будет работать?
Любому, кто настраивал HTTPS с нуля известно, что получение сертификата не самая простая процедура (ходя, для кого-то уже отработанная и вполне понятная). Создатели проекта предполагают[3], что с запуском проекта будет достаточно выполнить пару команд:
$ sudo apt-get install lets-encrypt
$ lets-encrypt example.com
После чего example.com становится доступен.
Скрипт (набор скриптов) Let's Encrypt сделает следующее:
- Автоматически «докажет» серверу CA Let's Encrypt что вы контроллируете сайт (домен)
- Получит сертификат, которому будут доверять браузеры и установит его на ваш сервер, внесф необходимые изменения в конфигурацию
- Будет отслеживать время истечения срока действия (expiration) сертификата и запрашивать его продление
- Поможет с отзывом (revokation) сертификата при необходимости
Всё это — без подтверждения по электронной почте, редактирования конфигурационных файлов, и бесплатно.
Что под капотом?
Для функционирования системы, на вашем сервере запускается агент, реализующий протокол ACME (Automatic Certificate Management Environment).
Процесс доказательства принадлежности домена выглядит следующим образом[4]:
- Агент на сервере отправляет запрос в Let's Encrypt CA с указанием домена, который необходимо подтвердить (example.com)
- CA оценивает домен и генерирует один или более наборов задач (challenge set), решение которых агентом доказывает принадлежность домена. Такие задачи подразделяются на два типа:
- создание DNS-записи поддомена example.com
- создание ресурса, доступного по HTTP на известном URI в example.com
- Дополнительно к задачам валидации домена, генерируется временный атрибут (объект данных), который агент на сервере подпишет своим закрытым ключом, чтобы доказать владение таковым.
- Агент выполняет один из наборов задач и подписание атрибута и уведомляет CA о готовности к проверке.
- CA начинает проверку, проверяя электронную цифровую подпись (ЭЦП) и доступность файлов/поддоменов
- Если ЭЦП верна и задача решена верно, CA считает что агент, идентифицированный по некоторому публичному ключу авторизован для управления сертификатами для домена example.com. Ключевая пара, использованная агентом становится «авторизованной парой ключей» для example.com.
После авторизации агента, он может запросить, обновить или отозвать сертификаты для своего домена (доменов). Соответствующие сообщения должны быть подписаны авторизованной парой ключей.
Для получения сертификата для домена, агент формирует Certificate Signing Request (CSR) PKCS#10 с запросом к Let's Encrypt CA на выпуск сертификата для example.com с указанным открытым ключом. Как обычно, CSR подписывается закрытым ключом соответствующим отрытому ключу в запросе. Дополнительно, CSR подписывается авторизованным ключом домена, чтобы подтвердить CA легитимность запроса.
По получении запроса, CA верифицирует обе подписи. Если они верны, он выпускает сертификат для example.com с публичным ключом из CSR и возвращает его агенту.
Другие процедуры (обновление, отзыв) работают аналогичным образом.
Узнать немного больше?
Проблема
Протокол ACME, подробно рассматривается в [5]. Сертификаты в X.509 PKI (Public Key Infrastructure, инфраструра открытых ключей) используются в различных целях, наиболее значительной из которых является аутентификация доменных имён. Таким образом, центрам сертификации (Certificate Authority, CA) PKI «доверяют» удостоверение того, что сторона запрашивающая сертификат (апликант) легитимно представляет доменные имена, перечисленные в сертификате. В настоящее время, верификация производится посредством набора частных косвенных механизмов. Создатели ACME излагают способ непосредственного взаимодействия и автоматической верификации и выпуска сертификатов.
В устоявшейся практике [5], получение сертификата состоит из ряда в основном ручных операций:
- Сгенерировать запрос PKCS#10 [6] — CSR
- Скопировать-Вставить CSR на странице CA
- Доказать владение доменом посредством одного из следующих методов:
- Разместить выданный CA объект (URI challenge) в заданное место на сервере
- Разместить выданную CA строчку (DNS challenge) в заданный узел DNS, соответствующий подтверждаемому домену
- Получить сообщение от CA (email challenge) на (теоретически) контролируемый администратором домена адрес электронной почты и ввести полученный код на странице CA
- Скачать выпущенный сертификат и установить его на сервер.
Основной идеей для ACME стало получение сертификатов для Web-сайтов (HTTPS [7]). В этом случае, каждый сервер отвечает за один или более доменов, и процесс (описанный выше) предназначен для проверки этого соответствия.
Для различных целей возможно использование различных типов сертификатов[8]:
- Extended Validation (EV) — CA проверяет правомерность использования апликантом доменного имени и характеристики организации (существует, документы в порядке, домен принадлежит организации, организация запросила выпуск сертификата; подробнее в [9])
- Organization Validation (OV) — CA проверяет правомерность использования апликантом доменного имени и принадлежности доменного имени организации
- Domain Validation (DV) — CA проверяет правомерность использования апликантом домена
Из них, DV, наверное, является наиболее популярным (здесь цена, минимальная трудоёмкость и достаточность являются главенствующими факторами). Важно, что для подтверждения на уровне DV все проверки могут быть выполнены CA автоматически, без участия оператора. Это и является ключевой особенностью решения на ACME — выпуск DV-сертификатов, сопоставимый по сложности с выпуском самоподписанного сертификата.
Как подтверждается владение доменом?
Для демонстрации того, что сервер (апликант) действительно авторизован отправлять сообщения от имени некоторого домена, CA работающий по протоколу ACME будет запрашивать решение набора задач (challenge) следующих типов (при этом подразумевается, что разрешение example.com в «подконтрольный» агенту узел должно быть через A или AAAA-запись):
- создание в DNS домена TXT-записи вида _acme-challenge.example.com. содержащую некий coolrandomealfanumerictoken, выдаваемый сервером
- разместить файл так, чтобы он был доступен по URI example.com/magnificientalfanumerictoken, проверка методом GET со стороны CA
- разместить файл так, чтобы он был доступен по URI example.com/yetanothertoken, для чего агент «на скорую руку» поднимает HTTPS; проверка методом GET со строны CA
- поднять HTTPS (используя self-signed сертификат) и принять TLS-соединение от CA. Сертификат формируется таким образом. чтобы содержать (в subjectAltName) проверяемый домен и домен вида <Z>.acme.invalid", где Z = SHA-256(R || S), (R — случайное значение, сообщаемое сервером в процессе обмена; S — случайное, сообщаемое клиентом)
- список может быть в дальнейшем расширен, например планируется электронная почта, DNSSEC, WHOIS
Как происходит обмен клиент-сервер?
Обмен клиента (агента) с сервером (CA) ACME осуществляется по протоколу HTTPS с обменом JSON-сообщениями. Каждое сообщение ACME представляет собой словарь (dictionary), с обязательным полем типа (type), определяющего состав остальных полей сообщения. Все сообщения отправляются на общий HTTPS URI, зашитый в клиент. Клиент, в целом, ведёт себя как браузер, отправляя запросы методом POST, следуя редиректам (статусы 301, 302). Ответы, обычно, приходят со статусом 200, информация об ошибках кодируется в JSON-ответах с типом «error».
Создатели протокола, на мой взгляд, благоразумно предусмотрели тип ответа «defer», позволяющий заставить клиента подождать заданный интервал времени перед повторным запросом. Т.к. сервис, вероятно, будет весьма популярен, то возможность попросить клиента подождать, если сервер, например, перегружен и запрос поставлен в очередь позволит создателям Let's encrypt (и будущим сервисам на базе этого протокола) снизить затраты на инфраструктуру.
При обработке CSR (отправляемого в виде base-64 encoded; DER[10]), сервер проверяет валидность полей перед выпуском сертификата. Предполагается, что CA будет отбрасывать из выпускаемого сертификата имена сущностей (Subject Alt Name), для которых у запрашивающего клиента (апликанта) нет авторизации. В ответ JSON, содержащий сертификат апликанта, включается собственно сертификат (base-64 encoded; DER) и цепочку родительских сертификатов в виде массива base64, DER, в порядке требуемом для TLS-рукопожатия по [11], т.е. так, что первый сертификат в массиве подтверждает сертификат апликанта, второй сертификат массива подтверждает первый сертификат массива (каждый последующий подтверждает непосредственного предшественника; корневой сертификат может быть отброшен, т.к. подразумевается, что он уже есть на клиенте).
Show me your code!
Клиентская часть написана на Python, есть в превью на GitHub: https://github.com/letsencrypt/lets-encrypt-preview и он уже умеет настроить Apache (под nginx есть заглушка)
Серверная часть написана на JS, GitHub: https://github.com/letsencrypt/node-acme
В вики проекта можно найти информацию о том, как всё это попробовать на своём сервере.
Источники и ссылки
- https://letsencrypt.org/
- https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
- https://letsencrypt.org/howitworks/
- letsencrypt.org/howitworks/technology/
- https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md
- http://www.ietf.org/rfc/rfc2314.txt
- http://tools.ietf.org/html/rfc2818
- https://www.globalsign.com/ssl-information-center/types-of-ssl-certificate.html
- https://cabforum.org/ev-code-signing-certificate-guidelines/
- https://en.wikipedia.org/wiki/X.690#DER_encoding
- http://tools.ietf.org/html/rfc5246
Иллюстрации с letsencrypt.org.
Автор: askbow
