Могут ли украсть SSL ключи, взломав nginx?

Могут ли украсть SSL ключи, взломав nginx?

Смогут, если смогут запустить код в контексте nginx.

Кажется от такого сценария нельзя уберечься теоретически? Или можно?

Нельзя.

Именно поэтому говно на пыхе ни в коем случае нельзя запускать внутри веб-сервера или от имени того же пользователя.

и nginx, и apache, и все остальные :)

Если процесс с одной стороны светит в сеть открытым портом, с другой стороны держит в памяти содержимое ключа или имеет доступ на чтение к файлу с ключом - то да, теоретически ключ могут упереть, если найдётся подходящая уязвимость

Конечно можно. :) Только придётся на сайте отказаться от ssl. :)

Да, я понимаю, потому и задал вопрос. Но представим следующую архитектуру. nginx запускается под root и читает сертификаты. Потом он запускает worker, понижая привилегии, и он устанавливает соединение с клиентами. Когда ему нужно что-то подписать, то он отправляет данные по pipe родителю и получает в ответ подписаные данные. Сам сертификатом не владеет, в памяти не держит, пользователь доступа не имеет.

Так вот, может в nginx что-то подобное?

Не будет ли больших накладных расходов при 10k и больше соединений?

Ну можно сделать parent и много пар secure-worker/worker наделать

nginx не умеет разделять привилегии? Как там в ssh делается, один процесс рабочий, другой с правами.

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

Ну я сказал как исправить - шифровать в отдельном процессе который понимает только очень тривиальный и однозначный протокол

Нельзя.

https://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudf...

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

Ну так что мешает передавать пакеты под шифрование в отдельный процесс? Или наоборот форкать отдельный низкопривилегированый процесс под пыхпых?

Ну если ты считаешь, что потеря производительности стоит того - вперёд, пиши.

Ну так что мешает передавать пакеты под шифрование в отдельный процесс? Или наоборот форкать отдельный низкопривилегированый процесс под пыхпых?

Дык... так и делаем! По сути, nginx и так ничего не умеет кроме обработки соединений (с клиентами, а так же с бэкэндами) и шифрования =).

бинго! ты придумал шифрующий фронтенд прокси 8)

vertexua

Да, я понимаю, потому и задал вопрос. Но представим следующую архитектуру. nginx запускается под root и читает сертификаты. Потом он запускает worker, понижая привилегии, и он устанавливает соединение с клиентами. Когда ему нужно что-то подписать, то он отправляет данные по pipe родителю и получает в ответ подписаные данные. Сам сертификатом не владеет, в памяти не держит, пользователь доступа не имеет.

Указанная возможность называется privilege separated key handling.

Она применяется в службах relayd, OpenSMTPD проекта OpenBSD:

• relayd(8) now uses privilege separation for private keys. This acts as an additional mitigation to prevent leakage of the private keys from the processes doing SSL/TLS.
• OpenSMTPD: Added RSA privilege separation support to prevent possible private key leakage.

vertexua

Так вот, может в nginx что-то подобное?

Про nginx нашел упоминание в комментариях к этому посту:

Could this method get introduced into other projects as well where crypto is used?
Of course it was easier to change OpenBSD-affilated projects but maybe other projects would be interested (nginx, dovecot, postfix) as well so maybe it's worth contacting upstream about it?

Yes, this could be used in other projects. As long as they are capable of using privilege separation, this technique will work just fine.

По всей видимости, указанная функция пока что не реализована в nginx.

Ок, понятно, это в принципе ответ на мой вопрос. Просто достаточно очевидная фича

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