Ssl-Сертификаты: Всем-Всем, И Пусть Никто Не Уйдет Обиженным

Как ранее сообщалось на GeekTimes EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust и исследователей из Мичиганского университета создали новый некоммерческий центр сертификации Давайте зашифруем [1] .

Цель проекта — ускорить переход Всемирной паутины с HTTP на HTTPS.

В чем смысл?

Всякий раз, когда пользователь подключается к сайту через HTTP, он подвергается ряду потенциальных проблем, таких как захват учетной записи, перехват трафика, отслеживание со стороны государственных и коммерческих организаций, встраивание вредоносного кода (скриптов) в код страницы и цензура.

Исследователи отмечают, что HTTPS, хотя и не является панацеей, решает эти проблемы, поэтому переход к широкому внедрению является важной целью.

Запуск проекта запланирован на лето (июнь?) 2015 года.

Let's Encrypt будет автоматически выдавать бесплатные сертификаты любому сайту, который их запросит. Планируется.

что переключение с HTTP на HTTPS при использовании этого сервиса будет осуществляться путем подачи всего одной команды или нажатия кнопки (облачные технологии – автоматизация в массы).

Здесь следует отметить, что наиболее существенными проблемами при развертывании HTTPS исследователи считают сложность, бюрократию и стоимость сертификатов, необходимых для работы HTTPS. Многие пользователи неоднократно сталкивались с предупреждениями и ошибками, возникающими из-за проблем с сертификатами.

Процедура получения сертификата бюрократична, сложна и является основной причиной того, что сайты продолжают использовать HTTP вместо HTTPS. Одна из целей проекта Let's Encrypt — исключить ненужные ссылки и автоматизировать процесс, что, по неофициальным замерам разработчиков, позволит сократить время настройки шифрования с 1-3 часов до 20-30 секунд. Проект основан на ряде инновационных подходов и технологий для управления безопасной автоматической проверкой домена и выдачей сертификатов.

Для этого планируется использовать разработанный для этих целей протокол ACME между веб-сервером и CA. Для проверки, среди прочего, будут использоваться сервисы SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google).

Для управления новым ЦС создается новая некоммерческая организация Internet Security Research Group (ISRG).

Как это будет работать?

Создатели проекта предлагают [3] что как только проект запустится, достаточно будет выполнить пару команд:

$ sudo apt-get install lets-encrypt



$ lets-encrypt example.com

Затем example.com становится доступным.

Скрипт Let’s Encrypt (набор скриптов) будет делать следующее:

• Автоматически «доказывать» серверу CA Let's Encrypt, что вы контролируете сайт (домен)
• Получите сертификат, которому будут доверять браузеры, и установите его на свой сервер, внеся необходимые изменения в конфигурацию.

• Отследит срок действия сертификата и запросит его продление
• Помощь с отзывом сертификата при необходимости

Что под капотом?

Процесс подтверждения владения доменом выглядит следующим образом.

[4] :

1. Агент на сервере отправляет запрос в центр сертификации Let's Encrypt с указанием домена, который необходимо проверить (example.com).

2. Центр сертификации оценивает домен и генерирует один или несколько наборов задач, решение которых агентом доказывает право собственности на домен.

   Такие задачи делятся на два типа:

   • создание DNS-записи для поддомена example.com
   • создание ресурса, доступного через HTTP по известному URI в example.com
3. В дополнение к задачам проверки домена генерируется временный атрибут (объект данных), который агент на сервере подпишет своим закрытым ключом, чтобы доказать право собственности на него.

4. Агент выполняет один из наборов задач и подписывает атрибуты и уведомляет ЦС о том, что он готов к проверке.

5. Центр сертификации начинает проверку с проверки электронной цифровой подписи (ЭЦП) и наличия файлов/поддоменов.

6. Если ЭCP верен и проблема решена правильно, центр сертификации считает, что агент, идентифицируемый некоторым открытым ключом, уполномочен управлять сертификатами для домена example.com. Пара ключей, используемая агентом, становится «авторизованной парой ключей» для сайта example.com.

Соответствующие сообщения должны быть подписаны авторизованной парой ключей.

Чтобы получить сертификат для домена, агент генерирует запрос на подпись сертификата (CSR) PKCS#10, запрашивающий центр сертификации Let's Encrypt выдать сертификат для example.com с указанным открытым ключом.

Как обычно, CSR подписывается закрытым ключом, соответствующим открытому ключу в запросе.

Кроме того, CSR подписывается авторизованным ключом домена, чтобы подтвердить ЦС легитимность запроса.

После получения запроса ЦС проверяет обе подписи.

Если они верны, он выдает сертификат для example.com с открытым ключом от CSR и возвращает его агенту.

Остальные процедуры (обновление, отзыв) работают аналогичным образом.

Узнать немного больше?

Проблема

Сертификаты в X.509 PKI (инфраструктура открытых ключей) используются для различных целей, наиболее важной из которых является аутентификация доменного имени.

Таким образом, центрам сертификации PKI (CA) «доверено» проверять, что сторона, запрашивающая сертификат (заявитель), законно представляет доменные имена, перечисленные в сертификате.

В настоящее время проверка осуществляется посредством набора частных косвенных механизмов.

Создатели ACME описывают метод прямого взаимодействия и автоматической проверки и выдачи сертификатов.

В сложившейся практике [5] Получение сертификата состоит из ряда преимущественно ручных операций:

• Создать запрос PKCS#10. [6] — КСО
• Копирование и вставка CSR на странице CA
• Подтвердите право собственности на домен одним из следующих способов:
  • Поместите объект, выданный центром сертификации (вызов URI), в указанное место на сервере.

  • Поместите строку, выданную центром сертификации (запрос DNS), на указанный узел DNS, соответствующий подтверждаемому домену.

  • Получите сообщение от центра сертификации (вызов по электронной почте) на (теоретически) адрес электронной почты, контролируемый администратором домена, и введите полученный код на странице центра сертификации.

• Загрузите выданный сертификат и установите его на сервер.

[7] ).

В этом случае каждый сервер отвечает за один или несколько доменов, а процесс (описанный выше) предназначен для проверки этого соответствия.

Различные типы сертификатов могут использоваться для разных целей.

[8] :

• Расширенная проверка (EV) – ЦС проверяет легальность использования заявителем доменного имени и характеристики организации (существует, документы в порядке, домен принадлежит организации, организация запросила выдачу сертификата; подробнее в [9] )
• Проверка организации (OV).

  CA проверяет законность использования заявителем доменного имени и право собственности на доменное имя организации.

• Проверка домена (DV) — CA проверяет законность использования домена заявителем.

Важно, что для подтверждения на уровне DV все проверки могут выполняться УЦ автоматически, без вмешательства оператора.

В этом ключевая особенность решения ACME — выдача DV-сертификатов, сравнимая по сложности с выдачей самозаверяющего сертификата.

Как подтверждается право собственности на домен?

com к узлу, «контролируемому» агентом, должно осуществляться через запись A или AAAA):

• создание записи TXT в домене DNS вида _acme-challenge.example.com. содержащий определенный крутой случайный цифровой токен, выданный сервером
• поместите файл так, чтобы он был доступен по URI example.com/magnificientalfanumerictoken , ПОЛУЧИТЕ чек от CA
• поместите файл так, чтобы он был доступен по URI example.com/yetanothertoken , для которого агент «быстро» поднимает HTTPS; проверка методом GET от CA
• поднимите HTTPS (с использованием самозаверяющего сертификата) и примите TLS-соединение от центра сертификации.

  Сертификат создается таким образом.

  содержать (в subjectAltName) проверяемый домен и домен вида .

  acme.invalid", где Z = SHA-256(R || S), (R — случайное значение, сообщаемое сервером во время обмена; S — случайное значение, сообщаемое клиентом)

• список может быть расширен в будущем, например планируется электронная почта, DNSSEC, WHOIS

Как происходит обмен клиент-сервер?

Каждое сообщение ACME представляет собой словарь с обязательным полем типа, определяющим состав остальных полей сообщения.

Все сообщения отправляются на общий HTTPS URI, жестко запрограммированный в клиенте.

Клиент в целом ведет себя как браузер, отправляя запросы методом POST после редиректов (статусы 301, 302).

Ответы обычно приходят со статусом 200; Информация об ошибках кодируется в ответах JSON с типом «ошибка».

Создатели протокола, на мой взгляд, мудро предусмотрели тип ответа «defer», который дает возможность заставить клиента ждать заданный период времени перед выполнением второго запроса.

сервис, скорее всего, будет очень популярен, то возможность попросить клиента подождать, если сервер, например, перегружен и запрос поставлен в очередь, позволит создателям Let's Encrypt (и будущих сервисов на основе этого протокола) сократить расходы на инфраструктуру.

При обработке CSR (отправляется в кодировке Base-64; DER [10] ), сервер проверяет корректность полей перед выдачей сертификата.

Ожидается, что центр сертификации исключит из выдаваемого им сертификата альтернативные имена субъектов, для которых запрашивающий клиент (заявитель) не имеет авторизации.

Ответ JSON, содержащий сертификат заявителя, включает в себя сам сертификат (в кодировке Base64; DER) и цепочку родительских сертификатов в виде массива Base64, DER, в порядке, необходимом для подтверждения TLS [11] , т.е.

чтобы первый сертификат в массиве подтверждал сертификат заявителя, второй сертификат в массиве подтверждал первый сертификат в массиве (каждый последующий сертификат подтверждает своего непосредственного предшественника; корневой сертификат можно отбросить, поскольку предполагается, что у клиента оно уже есть).

Покажи мне свой код!

Источники и ссылки

1. https://letsencrypt.org/
2. https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
3. https://letsencrypt.org/howitworks/
4. letencrypt.org/howitworks/technology
5. https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md
6. http://www.ietf.org/rfc/rfc2314.txt
7. http://tools.ietf.org/html/rfc2818
8. https://www.globalsign.com/ssl-information-center/types-of-ssl-certificate.html
9. https://cabforum.org/ev-code-signing-certificate-guidelines/
10. https://en.wikipedia.org/wiki/X.690#DER_encoding
11. http://tools.ietf.org/html/rfc5246

Теги: #CA #HTTPS #EFF #Mozilla #cisco #cisco #akamai #IdenTrust #Мичиганский университет #tls #json #dns #информационная безопасность #криптография

• Почему Вам Следует Работать С Ближайшими К Вам Дизайнерами Приложений, Если Вашей Компании Нужно Мобильное Приложение?

  19 Oct, 24

• Онлайн-Хранение Данных Обеспечивает Лучшее Решение

  19 Oct, 24

• «У Юмора Нет Формального Описания»: Как Разработчики Делают Виртуальных Помощников Забавными

  19 Oct, 24

• 7 Советов По Улучшению Интерфейса Вашего Приложения

  19 Oct, 24

• Элементы Опыта – Мое Краткое Содержание Книги

  19 Oct, 24

• Защитим Сканы Ваших Документов В Интернете

  19 Oct, 24

• Песни Из Openbsd

  19 Oct, 24

• Как Я Построил Бюджетный Электрический Велосипед-Чоппер

  19 Oct, 24

• Бережливое Производство — Это Реальная Тема, Модное Словечко Или Естественная Возможность Заработать Деньги. Или Хотя Бы Не Потерять

  19 Oct, 24

• Эволюция Носителей Информации: О Перфокартах, Магнитных Пленках И Дискетах

  19 Oct, 24