Блог

Почему веб-серверы обычно используют обратный прокси для SSL? Я понимаю концепцию обратного прокси и его полезность для балансировки нагрузки между несколькими серверами, но не для реализации SSL. Разве веб-сервер не может просто создать прослушивающие сокеты в разных портах для HTTP и HTTPS (т.Е. HTTP с SSL)?

Я часто использую Nginx в качестве обратного прокси.

Nginx служит интерфейсом HTTPS. Он размещает сертификат и закрытый ключ, перенаправляет HTTP-> HTTPS, добавляет необходимые заголовки в ответ и инкапсулирует интрасеть.

Фактическая бизнес-логика выполняется зоопарком различных серверов в интрасети, которые обслуживают через HTTP — nodejs, go, php. Они работают на разных машинах. Некоторые из них являются устаревшими и понятия не имеют о TLS, некоторые из них немного моложе и поддерживают только TLS 1.1.

Причины использования Nginx в качестве интерфейса HTTPS:

1. Я не доверяю реализациям HTTPS от третьих сторон.
2. Я не хочу возиться со всеми прибамбасами, требуемыми различными реализациями для прикрепления сертификата.
3. Я не хочу беспокоиться о устаревшем или стороннем программном обеспечении с устаревшей версией / конфигурацией шифров TLS или полностью пропускать HTTPS.
4. Мне нравится, как Certbot автоматически обрабатывает мои сертификаты в Nginx.
5. Мне нравится удобная функция Nginx, которую не предоставляет ни один из пользовательских серверов, например, перенаправление с HTTP на HTTPS, балансировка нагрузки, быстрые статические страницы и множество других.