Имеется такое явление, набравшее свою популярность, как letsencrypt/certbot. Он выдает ssl-сертификаты автоматически и всем подряд. В целом, это его основная проблема. Давайте взглянем на нее со стороны получения себе "дубликата" сертификата от сайта, уже имеющего https.

Способ проверки владения доменом при его запросе через certbot совсем не взломостойкий. Давайте попробуем получить "левый" сертификат для домена perfect-inc.com. Нам потребуется:

  • Доступ на сервер с IP, на который ссылается perfect-inc.com.
  • LetsEncrypt, уже установленный на сервере до нас.
  • Пользователь, имеющий права записи в public-директорию, доступную из веба.
  • Возможность запускать ПО (удаленный шелл).

В целом, всем понятно, что критичность дырки довольно велика:

  • Злоумышленнику достаточно 1 раз оказаться на хостинге с атакуемым сайтом и запустить одну команду.
  • После этого он забирает себе ключ, сертификат и занимается фишингом со своего сервера сколько душе угодно.

Так не получится сделать с любым другим полноценным сертификатом потому, что:

  • Никто не выдаст NN-ый сертификат на один и тот же домен автоматом кроме letsencrypt.
  • Все хранят на сервере ключи под правами пользователя root с чтением только от него.
  • Проверка подлинности происходит через email, а значит для получения левого сертификата официально нужно либо иметь доступ к смене MX записи а DNS, либо иметь возможность управлять/добавить почтовый ящик на текущем сервере.

Увести сертификат с помощью LetsEncrypt может человек, не имеющий какого-то "хакерского" опыта - обычный веб-разработчик или любой человек, умеющий запустить одну команду в шелле и имеющий доступ на хостинг.

Вот PoC (proof of concept) на примере нашего сайта perfect-inc.com. Здесь используется платный сертификат, выданный нормальным центром сертификации, но вот такая нехитрая операция на сервере позволяет получить "левый" сертификат от letsencrypt:

$ mkdir ~/cb; cd ~/cb; mkdir etc lib logs
$ certbot certonly -m lala@perfect-inc.com -d perfect-inc.com --webroot -w ~/data/www/perfect-inc.com/ --agree-tos --config-dir ~/cb/etc --work-dir ~/cb/lib --logs-dir ~/cb/logs

Вот мы имеем новый сертификат и ключ, самые настоящие и доступные для скачивания, размещения где-то у себя:

$ ls -la  ~/cb/etc/live/perfect-inc.com/fullchain.pem ~/cb/etc/live/perfect-inc.com/privkey.pem

В итоге получил еще один сертификат для домена, заметьте, что настоящий сертификат, купленный и к certbot никакого отношения не имеет. Как видите, ни подтверждения по почте, ни каких-либо других проверок, кроме файлика в веб-доступе.

Забираем его к себе и устраиваем фишинг в локальной сети (я, например, поднял https-прокси в офисе и собирал весь трафик в сторону сайта от наших офисных пользователей в открытом виде - акака man-in-the-middle), но можно и по другому устраивать фишинговые атаки.

Для того, чтобы обезопаситься от таких явлений, нужно:

  1. Не выдавать доступы к серверу всем подряд (это очень относительно с точки зрения ИБ).
  2. Удалить certbot либо запретить запускать его пользователям, кроме root.
  3. Закрыть для всех сайтов URL /.well-known/acme-challenge с ответом 404 (не .htaccess, а так, чтобы только root мог это изменить).
  4. Удалить TXT-запись _acme-challenge из вашего DNS и уберечь DNS от чужих рук.
  5. Отключить sudo у всех пользователей, от имени которых работает web.
  6. Php-fpm и apache не должны иметь возможности запускать оболочки (/bin/bash, /bin/sh, ...) и python (жестко, но полезно), это можно сделать с помощью selinux.
  7. Закрыть фаерволом доступ к серверу с адресов серверов валидации (это хорошо, но скоро появится еще 55 таких контор, выдающих всё и всем подряд).

SSL устроен по принципу доверия автору подписи, примерно как устроено нотариальное заверение документов. Чтобы человек стал нотариусом, он соблюдает ряд специальных законов и поэтому нотариальная система более защищена, чем такой вот SSL.

Перестать доверять им на клиентах можно и нужно, но ... взвоют тысячи разработчиков сайтов, установивших сертификаты от letsencrypt своим клиентам. Как говорится, хотели люди сломать SSL, аж руки чесались, теперь SSL-ю доверять нужно с оглядкой.

Откуда оно появилось и зачем?

Естественно, кого-то очень не устраивал бизнес по выдаче SSL-сертификатов.

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

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

В сочетании с spdy, http 2.0, активностью компании Google в рекомендациях использовать https, изменением визуальной части браузеров, всё крупнее и крупнее демонстрирующих наличие сертификатов, это весьма двоякая ситуация. С одной стороны все за использование ssl в вебе, с другой стороны, такие сервисы, как letsencrypt (чьи корневые сертификаты попали во все ОС) делают ssl очередной бесполезной проверкой формата admin/12345.

Ждем, что будет с certbot дальше и в какую сторону всё разовьется.