Назад | Перейти на главную страницу

Риски, связанные с предоставлением ZNC моего закрытого SSL-ключа

У меня есть один VPS, на котором работает несколько веб-сайтов, а также мой IRC-вышибала ZNC. Я купил подстановочный SSL-сертификат для всех своих поддоменов (это было глупо; было бы намного дешевле просто купить несколько однодоменных сертификатов, но что угодно).

У меня есть nginx, обрабатывающий все TLS, кроме фактических соединений IRC. Насколько я понимаю, нет способа поставить nginx перед ZNC для соединений, отличных от http / s. Итак, у меня есть копия моего закрытого ключа и сертификата в .pem это читается znc пользователь, который запускает ZNC.

Я верю, что у nginx нет недостатков, раскрывающих ключи, намного больше, чем я доверяю ZNC. Дело не в том, что я считаю ZNC гнусным, я просто предполагаю, что разработчики nginx больше думают об этом.

Я слишком беспокоюсь об этом? Каким рискам я подвергаю себя, предоставляя непривилегированной учетной записи доступ на чтение к моему закрытому ключу с подстановочными знаками? Стоит ли покупать отдельный сертификат для использования IRC? Я ошибаюсь, и nginx может проксировать соединения, отличные от http, для восходящего потока?

Возможно, вы могли бы использовать что-то вроде шпилька, станнель чтобы развернуть TLS на уровне TCP перед передачей трафика на ваш ZNC в восходящем направлении. Я предлагаю вам сначала попытаться заставить его работать с веб-трафиком ZNC (множество примеров развертывания HTTPS), но развертывание должно в равной степени применяться к другим протоколам с поддержкой SSL / TLS, таким как irc.

Тем не менее, вы параноик. Если вы столкнетесь со злоумышленником, который скомпрометирует ваш сертификат с помощью эксплойта znc, что они могут с этим сделать? Сервисы MITM с одним и тем же сертификатом? Это трехбуквенная территория агентства, которую можно в значительной степени смягчить с помощью 10 долларов за сертификат с одним хостом.