Необходимость перевыпустить SSL-сертификаты | html

В связи с багом OpenSSL (критическая уязвимость CVE-2014-0160 в популярной криптографической библиотеке OpenSSL, так называемая Heartbleed) от службы поддержки FastVPS пришло письмо вот такого содержания:

Письмо от службы техподдержки FastVPS

Данная рассылка касается Вас, если для своих сайтов или иных сервисов Вы используете SSL-сертификаты (как платные, так и самоподписанные).

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

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

- Обязательно сгенерировать новый приватный ключ т.к. нет причин полагать, что текущий не был украден. Это можно сделать командой:
# openssl genrsa -des3 -out /root/private.key 2048

- Сгенерировать новый запрос на получение сертификата, CSR, на основании нового ключа. Это можно сделать командой:
# openssl req -new -key /root/private.key -out /root/request.csr

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

После этого Ваш сертификат можно будет считать надежным и безопасным.

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

Обращаем Ваше внимание на тот факт, что вопросы по данной тематике следует адресовать Вашему ЦА, но не к нашей службе поддержки, мы никаким образом не сможем перевыпустить сертификаты для Вас.

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

1. Зачем этот новый сертификат, где он у меня используется?
2. Какой он у меня раньше был Центр Аттестации (ЦА)? Как его выбрать?
3. Можно ли сгенерировать новый самоподписанный сертификат?
4. Где находится мой старый сертификат? Как заменить старый сертификат на новый?
5. Может ли уязвимость OpenSSL как-то повлиять на доступ к серверу по SSH?

Нужно ли мне вообще производить обновление сертификата? Другими словами, где это у меня на сервере может быть задействовано? Насколько мне известно, HTTPS у меня на сервере не используется. Доступ по SSH это как-то затрагивает? У меня сейчас доступ к консоли команд сервера через SSH происходит по логину и паролю.

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

А как быть с доступом по SSH? Как текущая уязвимость CVE-2014-0160 может повлиять на безопасность протокола SSH, нужно ли менять приватные ключи сервера SSH?

Несмотря на то, что OpenSSH использует библиотеки OpenSSL для нужд криптографии (команда ldd покажет наличие библиотеки libcrypto.so), но это применяется только для генерации и обработки асимметричных ключей. Уязвимость CVE-2014-0160 касается расширения heartbeat протокола TLS, и поскольку протокол SSH не использует SSL/TLS, то о компрометации ключей и протокола можно не беспокоиться. Главное правило, касающееся этой уязвимости OpenSSL: двоичные бинарные сервисы, которые динамически линкуют библиотеку libssl.so можно считать скомпрометированными.

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

Большую проблему Heartbleed создаст сервисам типа IMAP, и веб-приложениям, которые обрабатывают данные аутентификации, где эта аутентификационная информация будет представлена в памяти процесса веб-сервера. Вот почему это плохо, но это вовсе не означает, что логин на основе SSH также скомпрометирован (за исключением того, что что-то секретное, касающееся SSH, загрузил в память скомпрометированный процесс.

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

1. Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta site:habrahabr.ru.
2. Practical Notes about Heartbleed (CVE-2014-0160) site:lonesysadmin.net.