Для общения по HTTP / 2 все браузеры требуют использования HTTPS.И даже без HTTP / 2 все еще хорошо иметь HTTPS по разным причинам.
Таким образом, точка, с которой должен общаться ваш веб-браузер (часто называемый пограничным сервером ), должна быть HTTPSвключен.Часто это балансировщик нагрузки , но также может быть CDN или просто веб-сервер (например, Apache) перед сервером приложений (например,Tomcat).
Итак, вопрос в том, должно ли соединение с этим пограничным сервером с любыми нижестоящими серверами быть активированным HTTPS?Ну, в конце концов, браузер не будет знать, так что не для этого.Тогда у вас есть две причины для шифрования этого соединения:
Поскольку трафик все еще передается по небезопасному каналу (например, CDN на исходный сервер, через Интернет).
Многие считают, что это неискренне, чтобы заставить пользователя думать, что он в безопасности (с зеленым замком), тогда на самом деле они не для полного сквозного соединения.
Это для меня менеепроблема, если ваш балансировщик нагрузки находится в отдельной сетевой области (или, возможно, даже на той же машине!), что и сервер, к которому он подключается.Например, если балансировщик нагрузки и два (или более) веб-сервера, к которым подключаются, находятся в отдельной области в отдельной сети DMZ или в своем собственном VPC.
В конечном итоге трафик будет расшифрован в какой-то моменти вопрос для владельцев серверов заключается в том, где / когда в вашем сетевом стеке это происходит и насколько вам удобно с ним.
Потому что вы хотите HTTPS по какой-то другой причине (например, HTTP / 2 вседо конца).
На этом я думаю, что есть меньше хороших аргументов.HTTP / 2 в первую очередь помогает подключениям с высокой задержкой и низкой пропускной способностью (т. Е. От браузера к пограничному узлу) и менее важен для подключений с низкой задержкой и высокой пропускной способностью (как это часто бывает с балансировщиком нагрузки для веб-серверов).Мой ответ на этот вопрос обсуждает это подробнее .
В обоих вышеописанных сценариях, если вы используете HTTPS на своих нижестоящих серверах, вы можете использовать самозаверяющие сертификатыили долгоживущие самозаверяющие сертификаты.Это означает, что вы не связаны 30-дневными ограничениями LetsEncrypt, и при этом вам не требуется приобретать более длинные сертификаты в другом ЦС.Поскольку браузер никогда не видит эти сертификаты, вам нужен только балансировщик нагрузки, чтобы доверять им, что вы можете сделать для самозаверяющих сертификатов.Это также полезно, если нижестоящие веб-серверы не могут общаться с LetsEncrypt, чтобы иметь возможность получать сертификаты оттуда.
Третий вариант, если действительно важно иметь HTTPS и / или HTTP / 2 на протяжении всего пути, должен использовать балансировщик нагрузки TCP (который является вариантом 2 в вашем вопросе, поэтому извиняюсь за то, что запутал нумерацию здесь!).Это просто пересылает TCP-пакеты на нисходящие серверы.Пакеты могут все еще быть зашифрованными по протоколу HTTPS, но балансировщику нагрузки это не важно - они просто пересылают их, а если они зашифрованы по протоколу HTTPS, то последующему серверу поручается их дешифрование.Таким образом, у вас все еще могут быть HTTPS и HTTP / 2 в этом сценарии, у вас просто есть сертификаты конечного пользователя (то есть сертификаты LetsEncrypt) на последующих веб-серверах.Это может быть сложным в управлении (должны ли одни и те же сертификаты использоваться в обоих? Или они должны иметь разные? Нужны ли нам липкие сеансы, чтобы трафик HTTPS всегда попадал на сам нисходящий сервер).Это также означает, что балансировщик нагрузки не может видеть или понимать какой-либо HTTP-трафик - все они являются только пакетами TCP, насколько это касается.Поэтому не нужно фильтровать заголовки HTTP или добавлять новые заголовки HTTP (например, X-FORWARDED_FOR с оригинальным IP-адресом).
Честно говоря, совершенно нормально, и даже довольно часто, иметь HTTPS на балансировщике нагрузки и HTTP-трафик на нижестоящих серверах - если в защищенной сети между ними.Обычно его проще всего настроить (одно место для управления сертификатами и обновлениями HTTPS) и проще всего поддерживать (например, некоторые нисходящие серверы могут не всегда легко поддерживать HTTPS или HTTP / 2).Использование HTTPS в этом соединении либо с использованием самозаверяющих сертификатов, либо сертификатов, выпущенных ЦС, одинаково хорошо, хотя требует немного больше усилий, и вариант балансировки нагрузки TCP, вероятно, является наибольшим усилием.