В последние годы хостинг превратился в commodity — полноценный продукт, привлекательность которого во многом определяется сопутствующими услугами. А поскольку особое значение сегодня имеет информационная безопасность веб-сайтов, то одним из важнейших аспектов хостинга являются SSL-сертификаты. Вся электронная коммерция так или иначе проходит через хостинг, поэтому необходимо понимать, насколько безопасно, правильно и удобно выполняются все бизнес-операции. Подробнее об этом рассказал спикер компании Rusonyx на партнёрской конференции «1С-Битрикс».

Данные, обнародованные Министерством внутренних дел России, наводят на грустные размышления:



В 2013 году количество киберпреступлений — около 11 тысяч инцидентов — составило 30% от общего объёма правонарушений. В 2015 году доля киберпреступлений выросла ещё больше. Хакерским атакам регулярно подвергаются довольно серьёзные проекты, которым мы доверяем свои деньги: в первую очередь, интернет-магазины и банки.

Наверняка кому-то из вас приходилось настраивать платёжные системы в продуктах CMS «1С-Битрикс». Любая платежная система вынуждает нас использовать защищённое HTTP-соединение, SSL-сертификаты. Это прихоть или действенная мера безопасности? Чтобы в этом разобраться, давайте посмотрим, что собой представляет SSL-сертификат.

Что такое SSL-сертификат

SSL-сертификат — это криптографический протокол, обеспечивающий защиту данных, передаваемых по сети. Какие задачи призван решить этот протокол?

• Передаваемые данные должны быть конфиденциальными. Пользователи и клиенты не хотят, чтобы их логины, пароли, e-mail-адреса, банковские счета и номера кредитных карт «разбрелись» по сети.
  
  
• Даже если данные оказываются перехвачены во время онлайн-транзакции, они должны остаться неприкасаемыми. У злоумышленника не должно быть возможности воспользоваться данными в своих целях, либо изменить их.
  
  
• Любая уважающая себя организация должна позаботиться о том, чтобы клиент был уверен в достоверности данных об организации, об их юридической чистоте.
  
  
• И последний немаловажный факт — это выполнение национальных и международных предписаний о защите информации. Особенно это касается тех организаций, которые планируют вывести свой онлайн-бизнес на мировой рынок.

Как работает SSL-сертификат

Когда мы заходим на защищённую страницу, браузер посылает серверу запрос. Помимо прочего, в этом запросе передаётся ID сессии. Далее браузер передаёт набор тех шифров, с которыми он может работать, и по какому протоколу. Сервер на основании этой информации решает, по какому протоколу они будут общаться в дальнейшем, какими наборами шифров они будут шифровать информацию, и отправляет браузеру ответ со своим сертификатом и открытым ключом.

Браузер проверяет сертификат: не отозван ли, не просрочен ли, убеждается в доверенности сертификационного центра, который его выписал. Далее браузер шифрует информацию открытым ключом и передаёт серверу вместе с нужными ему данными. С помощью закрытого ключа сервер расшифровывает полученную информацию. Потом оба участника процесса параллельно генерируют симметричные ключи, с помощью которых они в дальнейшем будут шифровать данные. В результате устанавливает защищённый канал связи, по которому сервер и браузер в дальнейшем обмениваются информацией.

Какие бывают виды SSL-сертификатов

1. DV SSL (Domain validation). Этот сертификат подтверждает доменное имя. У него есть подтип — WildCard. С помощью этого подтипа мы можем защитить все поддомены на одном уровне. К примеру, либо ssl.site.ru, либо ssl2.ssl.site.ru.
   
   
2. OV SSL (Organization validation). Он подтверждает домен и организацию. То есть когда вы посылаете CSR-запрос в сертификационный центр, они проверяют, действительно ли существует организация с таким ИНН, после чего выписывают вам сертификат. У него также есть подтип WildCard.
   
   
3. EV SSL (Extended validation). Этот сертификат подтверждает доменное имя и организацию. Для его получения вам придётся предоставить полный пакет документов о своей организации, то есть осуществляется расширенная проверка. На выписывание этого сертификата требуется больше времени, по сравнению с другими типами сертификатов, и стоит он гораздо дороже. У него нет подтипа WildCard, но на замену ему приходит MDC. Он позволяет нам в принудительном порядке перечислить количество доменов, которое будет защищать этот сертификат.
   
   
4. UCC SSL. Сравнительно малораспространённый вид сертификата. В основном используется для защиты почтовых служб, таких как Microsoft Exchange Server. При этом данный сертификат позволяет защищать до 100 доменов.
   
   
5. Organization ServerSign GlobalIP. Защищает все доменные имена, расположенные на одном IP-адресе.
   
   
6. Code Signing Certificate. Используется разработчиками. Данным сертификатом можно подписывать программное обеспечение, то есть он подтверждает автора ПО, а также гарантирует, что данный продукт не изменялся с тех пор, как была нанесена цифровая подпись.

Тестирование сервера

Можем ли мы быть полностью уверены в том, что данные наших пользователей и клиентов сайта находятся в безопасности из-за одного лишь факта установки SSL-сертификата? Для ответа на этот вопрос давайте рассмотрим три аспекта:

• Способы тестирования SSL.
• Тестирование стороннего сервера с помощью SSL LABS.
• Оптимизация сервера.

Для примера я выбрал сервер, на котором был предустановлен ряд приложений. Front-end —NGINX, back-end — Apache.



Ресурс SSL LABS принадлежит компании QUALYS, которая с 1999 года занимается облачной защитой, так что я считаю, что ему можно доверять. Прямо в панели можно установить SSL-сертификат, без каких-либо вмешательств в настройки сервера. Рейтинг довольно плохой — “С”. И первое, на что я хочу обратить внимание, — сервер до сих пор поддерживает старый протокол SSLv3, уязвимый к POODLE-атаке, в ходе которой можно перехватывать и расшифровывать данные. Злоумышленник может намеренно заставить нашего клиента использовать неактуальный уязвимый протокол SSLv3, и воспользоваться этим в своих целях.

Оптимизация сервера

Я приведу список оптимизаций только для NGINX, настраивать Apache нужно приблизительно так же.

В первую очередь, логично будет отключить на сервере протокол SSLv3. Это делается в виртуальных хостах, в server block: в директиве ssl_protocols просто убираем SSLv3, оставляя TLSv1, TLSv1.1 и TLSv1.2. Конечно, надёжнее будет оставить только TLSv1.1 и TLSv1.2, но можно столкнуться с некоторыми проблемами, о них я скажу ниже.

Второе, что нам попадается на глаза при тестировании — это старый набор шифров.



Дело в том, что старые браузеры могут поддерживать наборы шифров, которые также уязвимы к различным атакам. А вот список актуальных на сегодняшний день шифров:

• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSAAES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHEECDSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256
• DHEDSS-AES128-GCM-SHA256
• kEDH+AESGCM
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA
• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• ECDHE-ECDSA-AES256-SHA
• DHE-RSA-AES128-SHA256
• DHE-RSAAES128-SHA
• DHE-DSS-AES128-SHA256
• DHE-RSA-AES256-SHA256
• DHE-DSS-AES256-SHA
• DHE-RSA-AES256-SHA
• aNULL
• eNULL
• EXPORT
• DES
• RC4
• 3DES
• MD5
• PSK

После того, как мы настроили протоколы, по которым будем работать, а также установили на сервер актуальные шифры, пора позаботиться о том, чтобы клиент чётко выполнял наши указания. Для этого необходимо установить приоритетность шифров, включив директиву ssl_prefer_server-ciphers on. В этом случае при использовании протоколов SSLv3 и TLS серверные шифры более приоритетны, чем клиентские. Это позволяет защититься от многих атак типа Logjam, Beast, Freak.

Второе, за что SSL LABS поставил нам не самый высокий рейтинг, это использование слабых параметров файла ключей Diffle-Hellman.



Этот ключ генерируется с помощью команды openssl dhparam -out, где нужно указать путь к нашему будущему ключу и его длину.

openssl dhparam -out /etc/pki/tls/dh.pem 2048

Многие из вас, возможно, скажут, что необходимо использовать ключ длиной 4096. Возможно, это безопаснее. Но это замедлит скорость загрузки сайта. И к тому же 2048 — это, пока что, довольно безопасная длина ключа.

Следующее, на что нужно обратить внимание, — это механизм HSTS. Чтобы установить заголовок Strict Transport Security, нам необходимо перекомпилировать NGINX вместе с модулем HTTP header.

add_header Strict-Transport-Security max-age=15768000;

После перекомпиляции мы добавляем заголовок Strict Transport Security. Тем самым мы заставляем клиента, зашедшего по HTTP-протоколу, использовать HTTPS-протокол. С одной стороны, это хорошо, но с другой — влияет на SEO-оптимизацию. Поэтому перед тем как устанавливать данный заголовок, лучше проконсультироваться с коллегами, которые занимаются SEO-оптимизацией вашего сайта.

Далее, мы видим, что у нас отключён OCSP Stapling:



Протокол OCSP (Online Certificate Status Protocol) был создан на замену старого варианта CRL. Сертификационные центры приблизительно раз в неделю генерировали список отозванных сертификатов. Когда браузер подключался к нашему защищённому серверу, он скачивал список отозванных сертификатов, проверял, нет ли в нём нашего сертификата, и если не находил, то подключался к сайту. Но это довольно длительная процедура, поэтому был разработан более быстрый протокол OCSP. Правда, у него есть другой недостаток, но об этом ниже.

Включить Stapling можно в Server block с помощью директив

ssl_stapling on;
ssl_stapling_verify on;

Также нужно указать путь к нашему корневому сертификату:

ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

И установить resolver:

resolver <IР DNS resolver>;

Обычно ставят 8888. Это Гугловский public DNS, но если у вас есть свой DNS на сервере, то я бы рекомендовал поставить localhost.

Теперь о недостатках самого OCSP.

Дело в том, что проверка сертификата на отозванность состоит из четырёх стадий:

• подключаемся к DNS, чтобы получить IP-адрес веб-сервера,
• подключаемся к веб-серверу,
• получаем сертификат,
• чтобы проверить отозван он или нет, снова подключаемся к DNS, получаем IP-адрес сертификационного центра, и тогда уже получаем статус.

Помимо того, что мы выполняем лишние действия, мы также нагружаем сам сертификационный центр. Представьте, если каждый клиент подключается к серверу и запрашивает лично. Чтобы этого не происходило, мы включаем OCSP Stapling. Это позволяет веб-серверу самому подключиться к OCSP Responder и скачивать информацию о том, не отозван ли его сертификат. Эту информацию сервер кэширует у себя. Далее мы подключаемся только к DNS, потом к веб-серверу и получаем данные вместе с SSL-переговорами (handshake).

Ускорить процесс SSL-переговоров можно с помощью протокола SPDY, разработанного в Google. Сразу предупреждаю, что данный протокол нестабилен, об этом заявил сам разработчик, но, тем не менее, если посмотреть статистику на SSL LABS, его многие проекты успешно его используют.

Обычно переговоры состоит из трёх-пяти этапов, а SPDY позволяет всё сделать за одно соединение. Для его включения нам сначала придётся перекомпилировать NGINX, включив модуль spdy. Далее потребуется обновить OpenSSL до версии не менее 1.0.1а. Включить сам протокол можно в Server block с помощью директивы Listen:

Listen 443 ssl spdy

Следующий нюанс, на который я хотел бы обратить ваше внимание, это Session Resumption, кэширование. Когда мы в первый раз подключаемся к серверу, клиент передаёт ID сессии, сохраняющийся на сервере. И когда мы повторно подключаемся к нему, то при совпадении ID сессии уже не требуется выполнять SSL-переговоры, что ускоряет загрузку. Включить Session Resumption можно следующими директивами:

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 5m;

Согласно моему тестированию, кэширование позволяет снизить среднее значение SSL Negotiation на 10 мс.

Упрощение задачи

Не каждый из нас обладает навыками системного администрирования, поэтому я предлагаю всё вышеперечисленное забыть и немного упростить задачу.

Есть такой ресурс, как Mozilla SSL Configuration Generator. На нём можно в несколько кликов сформировать уже готовый виртуальный хост с нужными настройками, которые позволят вам получить в SSL LABS рейтинг «А». К примеру, мы выбираем веб-сервер NGINX, уровень шифрования modern, то есть самый безопасный, и указываем версию сервера. После генерирования нашего конфигурационного файла мы получаем все директивы, которые необходимы.





Недавно появился ещё один интересный проект — Let’s Encrypt. Их сертификаты защищают только доменное имя и субдомен. Также вы не получите зелёной строки, о которой я говорил — Extended validation certificate, то есть вы не подтверждаете организацию. Авторы заявляют, что их главная цель заключается в том, чтобы весь HTTP-трафик по умолчанию переводить в HTTPS. В принципе, неплохая идея. Я решил протестировать этот сервис. Скачал с их сайта Python-плагин, минут 30 его устанавливал, потому что он ещё не оптимизирован под многие версии Python. Но всё же мне действительно удалось довольно быстро установить сертификат. Я получил DV — Domain validation certificate, который подтверждал мой домен, а также субдомен, автоматически включённый в мой веб-сервер.

Но есть более быстрый способ.

Если ваш сервер поддерживает предустановленную панель PLESK, то в разделе «Расширения» вы можете в два клика скачать и установить расширение Let’s Encrypt. После введения вашего домена e-mail адреса он будет автоматически установлен на сервер. Важно отметить, что данный сертификат выписывается только на 90 дней, и его необходимо будет обновлять. Это можно очень просто сделать в панели PLESK, просто нажав кнопку Renew.

Как же достичь рейтинга А+?

Как же, в итоге, достичь рейтинга «А+»? Нужно выполнить следующую оптимизацию:

1. Отключить уязвимые SSL-протоколы (SSL v1, v2, v3)
2. Актуализировать набор шифров.
3. Сгенерировать надёжный ключ dh_param.
4. Включить механизм HSTS.
5. Ускорить SSL-переговоры с помощью OCSP Stapling.
6. Ускорить SSL-переговоры с помощью SPDY.
7. Включить кэширование.

Вот результат проделанной нами работы:



На что следует обратить внимание?

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



Поэтому, я рекомендую выбрать в Mozilla-конфигураторе уровень шифрования intermediate, а не modern. Это будет достаточно надёжно, но при этом вы получите рейтинг «А». Это не критично, к тому же вы не потеряете потенциальных посетителей вашего сайта.

О безопасности сервера

Установка SSL-сертификата на сервер ещё не означает, что данные ваших клиентов в полной безопасности. Поэтому хотел бы дать несколько советов.

• Разграничивайте свои сервисы по разным VPS-серверам. Кстати, «1С-Битрикс» как минимум умеет разворачивать веб-кластер из коробки. Пример из технической поддержки: часто клиенты сообщают о проблемах со спамом. Либо их заспамили, либо они получили уязвимость на сайте и им загрузили скрипт, рассылающий спам. В итоге у клиента забиваются либо inode, либо дисковое пространство. Но по сути это проблема не спама, а неработоспособности самого сайта, когда элементарно не могут выполняться операции ввода-вывода. Сайт не работает, база данных не работает.
• Всегда проставляйте корректные права на файлы и директории. На директории — 755 на файлы — 644. К счастью, «1С-Битрикс» это тоже умеет делать по умолчанию. Никогда не оставляйте файлы без пользователей группы, этим тоже могут воспользоваться злоумышленники.
• Не ставьте лёгкие для понимания человека пароли, которые поддаются подбору.
• Ограничивайте доступ к 22 порту, а также к другим портам IPtables, то есть к файрволу сервера.
• Также я бы советовал отключить и не пользоваться FTP, лучше перейти на SFTP.
• Откажитесь от telnet, используйте SSH.

Безопасность вашего сервера напрямую зависит от того, кто именно им управляет, а также от вас. В противном случае вы можете проснуться однажды утром и увидеть на своем сайте приблизительно такое: