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

Проблема с подтверждением связи HAProxy и SSL / TLS веб-сервером для разных поддоменов в одном сеансе браузера

У нас есть брандмауэр с HAProxy (pfSense) и несколько веб-серверов. Каждый веб-сервер настроен на HTTPS. Правила внешнего интерфейса HAProxy определены с помощью Server Name Indication TLS extension matches а веб-серверы определены как бэкэнды (все очень похожи).

Выдержка из конфигурации HAProxy (домен / ip заменены)

frontend HAProxy_443-merged
    bind            1.2.3.4:443 name 1.2.3.4:443   
    mode            tcp
    log         global
    option          log-separate-errors
    timeout client      45000
    tcp-request inspect-delay   5s
    acl         sub1example req.ssl_sni -m end -i sub1.example.com
    acl         sub2example req.ssl_sni -m end -i sub2.example.com
    ...
    tcp-request content accept if { req.ssl_hello_type 1 }
    use_backend sub1.example.com_ipvANY  if  sub1example
    use_backend sub2.example.com_ipvANY  if  sub2example
    ...

backend sub1.example.com_ipvANY
    mode        tcp
    id          159
    log         global
    timeout connect     30000
    timeout server      30000
    retries         3
    server          sub1.example.com 192.168.1.80:443 id 160 check inter 1000
...

Все работает нормально для всех доменов само по себе, но есть проблема с некоторыми поддоменами в том же браузере (тот же корневой домен, например, * .example.com).

Описание:

Если вы посещаете разные поддомены в одном и том же сеансе браузера в течение 30 секунд, трафик направляется на первый веб-сервер / бэкэнд. Если вы перезагружаете страницу, она обновит этот неизвестный сессия. Через прибл. 30 секунд это сессия закрыт, и вы можете перейти на правильную страницу.

Но есть некоторые поддомены без этих проблем.

BTW: это невозможно воспроизвести с помощью таких инструментов, как Postman.

Я исследовал настройки HAProxy для внешнего и внутреннего интерфейса, я проверил заголовки ответов и попытался отладить подтверждение ssl, но не смог найти сходства проблемных или различий между работающим и проблемным веб-сервером / бэкэндом.

Кто-нибудь признает эту проблему? Заранее спасибо.

Это может произойти, если несколько внутренних серверов имеют многодоменный сертификат (или групповой сертификат), где разные домены, на которые распространяется сертификат, обрабатываются разными внутренними серверами.

Рассмотрим сертификат, у которого есть альтернативные имена субъектов для A.example.com и B.example.com. Если клиент создает соединение HTTP / 2 с A.example.com через haproxy, он обнюхивает исходный TLS ClientHello и перенаправляет трафик на сервер A, который отвечает за A.example.com. Если затем клиент обращается к B.example.com, браузер, возможно, решит использовать то же TCP-соединение, поскольку согласно сертификату оно действительно для A.example.com, но также и для B.example.com. Видеть RFC 7540 раздел 9.1.1. Повторное использование подключения для соответствующей части стандарта HTTP / 2, которая позволяет это.

Теперь сервер A может не справиться с запросом B.example.com. В этом случае сервер должен выдать ответ с кодом 421 «Misdirected Request», и в этом случае клиент (браузер) может повторить запрос, используя новое соединение HTTP / 2. Если сервер не создает такой ответ, клиент не знает о проблеме и не может действовать соответствующим образом.

Решить эту проблему в haproxy невозможно, поскольку haproxy будет решать, куда пересылать данные, только на основе исходного ClientHello. Вместо этого нужно исправить это, либо отправив сервер в ответ 421, либо убедившись, что сертификаты охватывают только домены, фактически обслуживаемые сервером.