Риск предоставления ZNC моего личного ключа SSL
У меня есть один VPS с несколькими веб-сайтами, а также мой ZNC IRC Bouncer. Я купил сертификат SSL с подстановочными знаками для всех моих поддоменов (это было глупо; было бы намного дешевле просто купить несколько сертификатов с одним доменом, но неважно).
У меня есть nginx, обрабатывающий все TLS, кроме реальных IRC-соединений. Насколько я вижу, нет способа получить nginx перед ZNC для соединений не-http/s. Таким образом, у меня есть копия моего закрытого ключа и сертификата в .pem это читается znc пользователь, который запускает ZNC.
Я верю, что у nginx нет недостатков, которые могут выявить ключи, больше, чем у ZNC. Дело не в том, что я считаю ZNC гнусными, я просто предполагаю, что разработчики nginx думают об этом больше.
Я слишком беспокоюсь об этом? Какому риску я подвергаю себя, предоставляя непривилегированной учетной записи доступ на чтение к моему секретному ключу с подстановочными знаками? Должен ли я купить отдельный сертификат для использования IRC? Я не прав, и nginx может прокси-соединения не-http к восходящему потоку?
1 ответ
Возможно, вы могли бы использовать что-то вроде stud, stunnel, чтобы развернуть TLS на уровне TCP, прежде чем передавать трафик на ваш ZNC-канал. Я предлагаю вам сначала попытаться заставить его работать с веб-трафиком ZNC (множество примеров для развертывания HTTPS), но развертывание должно в равной степени применяться к другим протоколам с поддержкой SSL/TLS, таким как irc.
Тем не менее, вы параноик. Если вы столкнетесь с атакующим, который скомпрометирует ваш сертификат с помощью эксплойта znc, что они могут с ним сделать? Услуги MITM, которые имеют один и тот же сертификат? Это территория трехбуквенного агентства, которая может быть в значительной степени уменьшена с помощью 10 долларов за сертификат одного хоста.