Пользователь
0,0
рейтинг
24 ноября 2014 в 15:13

Разработка → SSL-сертификаты: всем, каждому, и пусть никто не уйдёт обиженным из песочницы

Как ранее сообщалось на 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).

http://letsencrypt.org_challenge

Процесс доказательства принадлежности домена выглядит следующим образом[4]:
  1. Агент на сервере отправляет запрос в Let's Encrypt CA с указанием домена, который необходимо подтвердить (example.com)
  2. CA оценивает домен и генерирует один или более наборов задач (challenge set), решение которых агентом доказывает принадлежность домена. Такие задачи подразделяются на два типа:
    • создание DNS-записи поддомена example.com
    • создание ресурса, доступного по HTTP на известном URI в example.com

  3. Дополнительно к задачам валидации домена, генерируется временный атрибут (объект данных), который агент на сервере подпишет своим закрытым ключом, чтобы доказать владение таковым.
  4. Агент выполняет один из наборов задач и подписание атрибута и уведомляет CA о готовности к проверке.
  5. CA начинает проверку, проверяя электронную цифровую подпись (ЭЦП) и доступность файлов/поддоменов
  6. Если ЭЦП верна и задача решена верно, CA считает что агент, идентифицированный по некоторому публичному ключу авторизован для управления сертификатами для домена example.com. Ключевая пара, использованная агентом становится «авторизованной парой ключей» для example.com.

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

letsencrypt_authorization

Для получения сертификата для домена, агент формирует Certificate Signing Request (CSR) PKCS#10 с запросом к Let's Encrypt CA на выпуск сертификата для example.com с указанным открытым ключом. Как обычно, CSR подписывается закрытым ключом соответствующим отрытому ключу в запросе. Дополнительно, CSR подписывается авторизованным ключом домена, чтобы подтвердить CA легитимность запроса.

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

http://letsencrypt.org_certificate

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

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


Проблема


Протокол 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!


Disclaimer
(Здесь нужно, на всякий случай, заметить, что код не мой, я просто сочувствующий)


Клиентская часть написана на Python, есть в превью на GitHub: https://github.com/letsencrypt/lets-encrypt-preview и он уже умеет настроить Apache (под nginx есть заглушка)

Серверная часть написана на JS, GitHub: https://github.com/letsencrypt/node-acme

В вики проекта можно найти информацию о том, как всё это попробовать на своём сервере.

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


  1. https://letsencrypt.org/
  2. https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
  3. https://letsencrypt.org/howitworks/
  4. letsencrypt.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

Иллюстрации с letsencrypt.org.
Денис Борчев @askbow
карма
25,0
рейтинг 0,0

Похожие публикации

Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (81)

  • +5
    А центр сертификации-то доверенный? Если нет, то все потуги могут оказаться бесполезными.
    • +2
      На странице на гитхабе, разработчики честно предупреждают, что в настоящее время СА тестовый и к использованию не готов.

      Думаю, с ресурсами всех собравшихся спонсоров у этого проекта есть хорошие шансы на старт. По крайней мере, продукты Mozilla должны будут доверять)
    • +4
      Сначала кросс-подписывание с уже доверенным IdenTrust, позже планируют сами стать доверенными. Отсюда: twitter.com/letsencrypt/status/535473089929154560
      • +4
        Тогда стоит им пожелать успехов, и понадеяться, что проект взлетит, т. к. выглядит очень интересно.
  • +6
    Интересней выглядит технология DANE ( en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ). При этом сайт использует самоподписанный сертификат и хранит в DNS запись с информацией об этом сертификате, а сам DNS защищается с помощью DNSSEC.

    Бесплатные сертификаты достаточно давно можно было получать через StartSSL и эта инициатива в корне ничего не изменяет, разве что немножко упрощает этот процесс.
    • 0
      С той разницей лишь, что бесплатно wildcard они не дают, и что выданный серт могут отозвать, если решат, что он начал использоваться в коммерческих целях.
      • 0
        А lets-encrypt что, будет давать wildcard'ы? Судя по статье, его цель — быстро поднять сносный SSL га конкретном сервере.
    • 0
      DANE требует настройки DNSSEC и соответствующей поддержки клиентским софтом, которая пока слабенькая, в особенности по браузерам (в режиме «из коробки»).
  • +4
    Весьма спорное решение — просить пользователя запускать нечто, что будет менять конфиг его веб-сервера. А если я использую нетиповой конфиг, и оно уронит мой сервер?
    • 0
      проще было бы им тупо временно поднимать https-сервер на 443 порту… правда, это работало бы только для первого раза (пока не запущен основной сервер на нем же).
    • –8
      Если вы используете нетиповой сервер и оно уронит ваш сервер — это научит вас аккуратней обращаться с production-серверами. Что тоже хорошо!
      • +2
        Давайте еще раз с начала: есть некая тулза, которая написана неизвестно кем и протестирована на неизвестно каких конфигурациях. Например я использую nginx, и в конфиге у меня есть какая-то непротестированная ситуация, ну например location вложенный в другой location. вложенный в другой location. Что произойдет после запуска этого приложения?
        В чем моя неаккуратность использования? Или вы не допускаете возможность того, что в агенте могут быть ошибки?
        • 0
          Думаю, никто пока не знает, как это будет работать.
          И думаю, мало для кого она подойдёт в таком формате, как это описано в статье.

          Безотностительно этой спорной утилиты, начинание отличное же.
        • 0
          Вам и многим другим эта тулза не подойдет. Ее цель проста — сделать настройку SSL простой для 80% случаев. 20% остальных никто не отменял. И как и все остальное в этом мире, она основана на доверии. Не доверяете — не запускайте.
  • +3
    Изящно. Я потратил немало времени на то, чтобы разобраться со StartSSL. Впрочем, это скорее из-за нехватки опыта.
    • 0
      У меня после регистрации в первый раз в браузере не установился личный сертификат. Подозреваю, что в этом виноват Касперский, после выключения которого всё получилось. Во второй раз, кстати, StartCom даже не стали менять изначальное написание моего адреса, так что получилось даже лучше, чем ожидал.

      Забавный случай произошёл позже, когда в списке возможных TLD был.москва, но не было .moscow. Отписал на certmaster, отправили в FAQ, где написано про требование наличия WHOIS. Ответил, что у этих двух TLD один общий WHOIS-сервер (кто бы мог подумать?), так пообещали через несколько дней всё-таки добавить .moscow. Вот уже с первых дней занимаюсь усовершенствованием сервиса :).

      P.S. Парсер лох, удаляет пробел между «был» и ".москва".
      • 0
        Ловил такое при использовании chrome/chromium. С тех пор для cacert и startssl использую firefox.
        • 0
          Это я ещё не написал, в каком браузере у меня такое произошло ;). Ну, вы поняли.
    • 0
      Я, кстати, запорол сертификат свой, то ли ввел не то, то ли еще что-то. Восстановить, как я понимаю только за деньги?
      • 0
        У них решение простое: потерял, прозевал, запорол — регистрируйся снова и не парься по поводу старых учёток.
        • 0
          А у них разве привязка не к домену идет? Я пробовал создавать заново, а мне в ответ, мол домен уже использовался.
          • 0
            Нашел причину, нужно было предыдущий сертификат из браузера удалить.
    • 0
      У StartSSL есть геморрой с сертификатами для аутентификации в личном кабинете. Через два года сертификат истекает и стандартной процедурой описанной в FAQ является новая регистрация и письмо в саппорт с данными старой и новой учётки. Это как-то ненормально.
      Я после этого ушёл на gogetssl, где годовой Comodo PositiveSSL стоит в районе $6. По-моему, разница с $0 в годичном периоде довольно незначительна, чтобы устраивать себе геморрой. К тому же, комодовский можно сразу на 5 лет выпустить.
  • 0
    Не очень понял, а полученный сертификат можно будет использовать для подписывания сертификатов для доменов следующих уровней?
    Просто бесплатный сертификат на домен можно сейчас получить и у StartSSL, но если хочешь подписать им поддомены свыше своего example.com, нужно заплатить.
    • 0
      StartSSL как минимум с сентября: «Over Capacity»
      • 0
        Давно не «общался» с ними, использую самоподписанные, так что не в курсе. Печально.
      • +1
        Я буквально вчера выписывал себе новый Class 1 Intermediate, плюс обновлял существующие — всё работает нормально у них.
      • +1
        У них это периодически бывает, ещё по выходным до 10 утра МСК профилактика, а так в принципе работает.
    • +1
      Если я правильно понимаю код, то генерируемый сертификат не предназначен для подписания других сертификатов:
       cert.setExtensions([
      { name: "basicConstraints", cA: false },
      { name: "keyUsage", digitalSignature: true, keyEncipherment: true },
      { name: "extKeyUsage", serverAuth: true },
      { name: "subjectAltName", altNames: [{ type: 2, value: commonName }] }
      ]);
      

      The cA boolean indicates whether the certified public key may be used to verify certificate signatures.

      tools.ietf.org/html/rfc5280#page-39

      я на всякий случай задал вопрос по поводу поддоменов в Твиттере (хотя, думаю, таких вопросов там уже вагон)
      • 0
        Просто это всегда вносило тонну неудобства у таких сервисов как StartSSL.
    • 0
      Можно чуть подробнее с этого места? Допустим, я купил у СА сертификат для основного домена, у меня есть закрытый ключ и сертификат, подписанный вышестоящим центром, могу ли я им подписывать дальше поддомены своего домена?
      • 0
        В зависимости от того какой сертификат Вам выдан. askbow наглядно продимонстрировал опцию, которая отвечает за это в одном из генераторов. StartSSL например за денежку выдавал сертификат которым в дальнейшем можно было подписывать сертификаты для поддоменов.
        • 0
          хорошо, а как мне это проверить? сертификат у меня уже на руках.

          Хотелось бы определить наличие такой возможности либо по какому-то полю в стандартном окошке свойств сертификата, либо командой openssl вывести требуемый набор полей и по нему понять, что я могу подписывать сертификаты «дальше по цепочке»
          • +1
            openssl x509 -in <certfile.pem> -text
            , там смотреть basic constraints.
    • 0
      А в чём проблема у StartSSL попросить сертификаты для всех нужных поддоменов? Я вот именно так и сделал.
  • 0
    Имхо с SSL — только одна проблема — цена. Все эти челенжи муть какая-то, с ними проблем будет больше чем с обычной процедурой получения и продления сертификата. Главное что бы был бесплатный и доверенный.
    • 0
      Да вообще говоря, в районе 5$ в год стоит SSL-сертификат, что ненамного дороже расходов на домен. Чем тратить время на подобные поиски халявы, можно лучше чего-нибудь полезного сделать :).
      • 0
        Если доменов 20 — это уже $100 минимум только на сертификаты. Уже есть смысл озаботиться оптимизацией расходов:)
        • –1
          20 доменов — 20 проектов, 20 проектов наверняка должны приносить существенно больше прибыли.
          К тому же, поиски халявы требуют времени, а время тоже небесплатное.
          • 0
            А если все проекты non-commercial?
      • 0
        Много раз встречал эту фразу про $5..10 за серт. Когда лез разбираться — ни wildcard за разумные деньги, ни даже честных $5 не находил. Да, если купить на 10 лет, то «удельный» ценник станет $5.95, но это если $59.5 разом заплатить. Про wildcard молчу, хотя выписывание их тратит столько же CPU — они всегда стоят дороже.

        Поделитесь, где можно задешево и хорошо разжиться сертификатом?
        • +1
          Wildcard — совсем другая тема :-)
          Можно посмотреть gogetssl, например. Ну и вообще positivessl можно найти дешевле $5 при оплате за 2-3 года, 10 лет необязательно покупать.
        • +1
          ни даже честных $5 не находил

          PositiveSSL
          Позавчера как раз брал. Честные $4.99. Можно сразу на 5 лет, чтобы не париться с продлениями.
          • 0
            О. Это ещё дешевле, чем GoGetSSL. Надо посмотреть.
  • –1
    1. Интересы барыг «воздухом» от такой идеи заметно пострадают, прямо вижу миллионные убытки.
    Почему никто из них не плачется?

    2. Читал — читал и так и не понял: закрытый ключ передаётся этому ЦС или нет.
    Потому как если да, то в топку такой ЦС.
    Если нет то…

    3. Вся эта затея ударит только по мелким жуликам, большие дядьки (типа NSA) наклепают себе сертификатов и будут MiTM делать спокойно и дальше.
    Что только усилит их позиции.
    Может потому никто и не скулит об миллионных убытках.
    • 0
      насколько я понял (не изучал информацию подробно), будут предлагаться только базовые (domain control validated) сертификаты.
      EV-сертификаты, приносящие основную прибыль, остаются за общепризнанными СА.
      • 0
        А зачем эти EV-сертификаты вообще нужны?
        • 0
          Во всех нормальных браузерах (т. е. кроме IE) нельзя воткнуть свой CA, выдающий EV.

          Если вы видели на, скажем, банковском сайте EV-сертификат, а потом там оказался обычный валидный не-EV, то это может означать поптыку MitM'а (с инъекцией фальшивого CA в доверенные).

          Правда, никто не мешает пересобрать браузер при необходимости…
    • 0
      Читал — читал и так и не понял: закрытый ключ передаётся этому ЦС или нет.
      Потому как если да, то в топку такой ЦС.
      Если нет то…
      Только CSR и подпись сообщений, приватный ключ остается на сервере.
  • 0
    Вообще не понял, как этот скрипт собирается автоматически создавать DNS-записи при использовании внешнего DNS-хостинга.
    • 0
      В оригинале сказано
      These are different ways that the agent can prove control of the domain. For example, the CA might give the agent a choice of either:

      • Provisioning a DNS record under example.com, or
      • Provisioning an HTTP resource under a well-known URI on example.com/

      Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.

      The agent software completes one of the provided sets of challenges.


      Т. е. перевод не очень корректный. Агент получает набор возможных способов подтверждения владения доменом, далее подтверждает как минимум одним способом. Может, например, создать rr в dns, а может дать доступ к специально сформированному файлу по заранее указанному пути.

      Непонятно, как оно будет бороться с dns spoofing и cache poisoning, хотя текущие механизмы domain validation (dns rr, http resource & hostmaster email) от этого не защищены.
  • +1
    По мне так CA это в первую очередь огромная ответственность для хозяев CA, которые за это имею денежку. А в случае бесплатного CA кто будет переживать чтоб не скомпрометировали его? Будут рекламу у себя на сате крутить или пожертвования от неких «спонсоров» получать? Что произойдет, когда всплывёт факт компрометации CA? Кто за него отвечать будет?
    • 0
      Вы кто создает CA прочитали? Или сразу комментировать пошли?
      «EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust»
      Что вам в списке «спонсоров» непонятно? Какое название незнакомо?
      • 0
        Прошу прощения, так долго читал «суть», что забыл, что там в первых строчках было.
        • +1
          Спонсорство спонсорством, но всё же неясно, как коммерческие предприятия буду прилагать усилия по верификации личности подателя, если последний за это не платит.

          Вспоминается, как покупался сертификат в своё время от одной известной компании в ЮАР, так они позвонили мне(!!) с просьбой указать доверенных лиц, которые бы могли подтвердить мою личность(!!) Это было бы очень смешно, если бы за эту прекрасную услугу не хотели $150. Что будет за бесплатно, можно только догадываться.
          • 0
            Как я понял, в данном случае речь не о персональных сертификатах для ЭЦП а только для сайтов/доменов
          • 0
            Если вы читали статью, то там сказано «dv-only». Нет никакого подтверждения личности, только владения доменом. Такой же результат даст cacert, startssl. И куча дешевых ca.
  • 0
    Если у них все получится — будет круто. Хостинг провайдеры включаться в работу. Проект заточен на Интернет в целом, но некоторые подходы не очень радуют.

    Пример:
    Если у тебя простенькие сайт-визитка без авторизации пользователей. Контора платит за него 180 рублей в месяц и все довольны.

    Под этим соусом популярные веб-браузеры внедрят фичу — сайт не надёжен, потому что не https… так же, как сделали с Adobe Flash Player и JRE.
    И для обычных пользователей будет геморой тыкать во что-то типа «Разрешить и сохранить» или «Продолжить» (на свой страх и риск).

    • 0
      Сейчас современный хром показывает, что сайт ненадежен, если какой-нибудь из сертификатов в цепочке использует sha1With*. Например, это относится к любимому банками thawte Extended Validation SSL CA (sha1WithRSAEncryption). Что уж говорить о том, что некоторые корневые CA используют md5WithRSAEncryption.
      • 0
        Может просто суппорты CA нужно завалить жалобами на WithRSA?
        Пока мы не реагируем — они свято уверены, что у них всё хорошо…
        • +1
          С RSA проблемы пока нет вообще. По md5/sha1 я тоже несколько перегнул.

          Практическая атака 2008 на CA, подписывающие с использованием md5WithRSAEncryption и предсказуемым serial (на примере rapidssl) стоила порядка 2 дней и 21k$ ресурсов (200 PS3 + <1k$ на покупку сертификатов). В результате исследователи получили подписанный доверенным intermediate ca фальшивый ca, который может подписывать сертификаты для любых сайтов. После публикации информации по этому исследованию в конце 2008 CA перестали использовать md5 для новых сертификатов.

          Эта атака не работает для sha1* и самоподписанных (в том числе корневых) сертификатов с md5*. При этом, ca должны быть готовы к переходу на sha2 если атака станет ощутимо ближе к практической реализации, чем сейчас. Догадываюсь, что это может быть требование регулирующих органов после примера с md5*.

          Но момент, когда подбор коллизии sha1 будет стоить относительно дешево приближается. И Google с Mozilla Foundation чешутся об этом заранее, что выглядит разумным.

          Интересные оценки есть здесь (в предположении, что закон Мура будет выполняться и дальше):
          $2.77M in 2012
          $700K by 2015
          $173K by 2018
          $43K by 2021

          Оценка по деньгам может быть занижена на порядок, но она всё равно выглядит очень сурово. И это учитывает только работу на CPU.

          Там же, в комментариях есть прекрасное:
          It's also worth noting that everyone in the Bitcoin network is currently doing about 2^44 hash operations per second total. The network could produce a SHA-1 collision at that rate in about 18 hours
  • 0
    он наступит скоро, нужно только подождать
  • 0
    Как-то тут с безопасностью не ок.
    Ну допустим, мы ломанули сайт некоего банка или там даже интернет-магазина. Ну как ломанули, просто как-то получили доступ к файловой системе сайта на запись. Подобрали пароль админа к cms или ftp, например. Дальше мы размещаем файлик, получаем сертификат, удаляем файлик. Всё, взлома сайта как бы и не было.
    Дальше поднимаем шэдоу прокси и атакуем уже клиентов этого сайта. Подменяем hosts или поднимаем фейковую точку доступа, указываем на наш прокси и спокойно собираем пароли, ключи и куки. Так как сертификат есть и он валиден, ничего нигде не ругается. После сбора возвращаем всё как было. Следов атаки ноль, а пароли-то вот они.

    С одной стороны, всеобщий https в эпоху открытых вайфаев и сормов — это благо.
    С другой, конкретно такая автоматическая реализация это зло, дискредитирующее всю суть современной PKI. Нужно как минимум проверять наличие у сайта действующего сертификата и обязательно отправлять письмо админу домена на указанный в домене емейл.
    • 0
      Не очень понимаю, что мешает сделать тоже самое с любым другим центром сертификации? В том же StartSSL авторизация происходит примерно по тому же пути только вручную. Автоматизация тут не причем, лишь сэкономит время злоумышленнику также как и владельцу.
      • 0
        Итого получается DV-only не комильфо и лучше такие магазинчики обходить стороной
        • 0
          Запрос на перевыпуск/отзыв если я все правильно понял надо подписать имеющимися ключами, само собою защищенными pass-phrase, если Вы сами себе не враг.
          • 0
            Я о том, что для магазина надо покупать более проверенный сертификат, чем DV и как-то запрещать использовать для своего домена DV-сертификаты
            • 0
              Не понял простите, да Вы правы, вероятнее всего OV, хотя лично я далек от ecommerce.
              • 0
                Кто знает подскажите как для своего домена запретить использование DV сертификатов, чтоб ушлые хакиры MITM не устроили?
                • +1
                  Хотя, пожалуй, никак
      • 0
        Тем, что в случае startssl всё-таки есть человек, который, ну, удивится запросу на сертификат для google.com или там examplebank.ru с мыла sdh34hsadfg@hotmail.com. Плюс куча следов остаётся.
        • 0
          Ну всегда остается issue date в качестве следа. И все же настаиваю на том, что последний рубеж тут pass-phrase у SSL ключа, который используется для запроса/переиздания/отзыва сертификатов. Не спорю, письмо на ящик «доменный» имеет смысл.
  • 0
    Проект интересен, но не нов (в желании обеспечить бОльшую доступность SSL сертификатов). Выше уже упоминали CAcert.org — не будучи поддержанный вендорами браузеров, он все же был включен в некоторые дистрибутивы открытых OS, однако и из большинства значимых его в концов исключили: en.wikipedia.org/wiki/CAcert.org#Inclusion_status. Причины: подозрения/обвинения в том, что упрощенная система получения сертификатов приводит к использованию для фишинга и т.п.

    Так и здесь — палка о двух концах.
  • 0
    Бесплатные ssl это замечательно!

    Куча мелких сайтов висящих на шаред хостингах правда переходить не станет, так как для https нужен выделенный ip.
    • +1
      так как для https нужен выделенный ip.
      Не обязательно
      nginx.org/ru/docs/http/configuring_https_servers.html
      Ищите SNI
      • 0
        о, полезная инфа.
        сенкс!
        • +1
          Только нужно учитывать, что SNI не поддерживается любым Internet Explorer и Safari на Windows XP, а также любым браузером на Android 2, который использует HTTPS-стек от ОС (например, кроме стандартного, ещё и Dolphin).

          Если в первом случае ещё можно сказать посетителю, чтобы он не заходил в интернет с устаревших браузеров (для Windows XP последние версии Internet Explorer и Safari вышли в 2009 и 2012 году соответственно), то во втором случае для установки другого браузера может не быть свободного места + плохой user experience в целом. 10% Android-устройств всё ещё работает на Android 2.x. Как вариант, можно запустить сайт на HTTPS без SNI и сначала накопить достаточную статистику.
          • +1
            CloudFlare когда раскатывали https решили не заморачиваться и тупо не поддерживают системы которые не умеют SNI, что вообще-то логично.
            • +1
              И совершенно правы. Если кто-то использует нечто неподдерживающее SNI, то пусть этот кто-то дальше сидит на дереве.
      • 0
        Кстати, про Chrome неправильно написано: Chrome (Windows-версия также поддерживает SNI только на Vista и выше). На самом деле поддерживает на XP с версии 6, а ведь она вышла 4 года назад.
  • 0
    Сегодня на волне информации о получении Let's Encrypt'ом кросс-подписей проверил текущую версию клиента. Все работает, однако сертификаты по прежнему выдаются с CN = happy hacker fake CA. Ждем официального старта, т.е. 16 ноября.

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