Поддержка двухстороннего TLS/HTTPS с ELB

Ответ 1

Я не вижу, как это можно сделать, в двухстороннем режиме HTTPS, потому что ELB устанавливает второе TCP-соединение с внутренним сервером и внутренне расшифровывает/шифрует полезную нагрузку на/с клиента и сервера... поэтому сервер не будет видеть сертификат клиента напрямую, и нет никаких задокументированных заголовков X-Forwarded- *, отличных от -For, -Proto и -Port.

С ELB, работающим в режиме TCP, с другой стороны, согласование SSL выполняется непосредственно между клиентом и сервером, когда ELB слепо связывает потоки вместе. Если сервер поддерживает протокол PROXY, вы можете включить эту функциональность в ELB, чтобы вы могли идентифицировать клиент, исходящий IP и порт на сервере, а также идентифицировать сертификат клиента непосредственно, потому что клиент будет вести переговоры непосредственно с вами... хотя это означает, что вы больше не выгружаете SSL в ELB, который может быть частью что вы пытаетесь сделать.

Обновление:

Не похоже, что есть способ сделать все, что вы хотите сделать - выгрузить SSL и идентифицировать сертификат клиента - только с помощью ELB. Информация ниже представлена ​​ "для чего она стоит".

По-видимому, HAProxy поддерживает поддержку клиентских сертификатов в версии 1.5 и передает информацию сертификата в заголовках X-. Поскольку HAProxy также поддерживает протокол PROXY через конфигурацию (что-то вроде строк tcp-request connection expect-proxy)... так что кажется возможным, что вы могли бы использовать HAProxy за TCP -mode ELB, при этом HAProxy завершает соединение SSL и перенаправляет информацию о IP-адресе клиента из ELB (через протокол PROXY) и информацию сертификата клиента на сервер приложений..., тем самым позволяя вам поддерживать SSL-разгрузку.

Я упоминаю об этом, потому что это похоже на дополнительное решение, возможно, более полнофункциональное, чем любая платформа, и, по крайней мере, в 1.4, эти два продукта работают безупречно вместе - я использую HAProxy 1.4 за ELB успешно для всех запросы на моей крупнейшей веб-платформе (в моем случае ELB выгружает SSL - нет сертификатов клиентов), и, похоже, это сплошная комбинация, несмотря на очевидную избыточность каскадных балансировщиков нагрузки. Мне нравится, что ELB является единственной вещью в большом плохом Интернете, хотя у меня нет оснований думать, что непосредственно HAProxy, подвергшийся прямому воздействию, будет проблематичной сама по себе. В моем приложении ELB существуют для баланса между HAProxies в A/Z (который я изначально планировал также автомасштабировать, но загрузка процессора оставалась настолько низкой даже в течение нашего напряженного сезона, что у меня никогда не было более одного в Zone доступности, и я никогда не терял его, но...), который затем может выполнять некоторую фильтрацию, пересылку и разбиение заголовков перед доставкой трафика на фактическую платформу в дополнение к предоставлению мне некоторых протоколов, переписывания и трафика -splitting control, которого у меня нет с ELB самостоятельно.

Ответ 2

В случае, если ваш задний конец может поддерживать сами аутентифицированные HTTPS-соединения с клиентом, вы можете использовать ELB в качестве TCP на порту 443 для TCP на вашем заднем конце. Это заставит ELB просто отправить незашифрованный запрос прямо на ваш задний конец. Эта конфигурация также не требует установки SSL-сертификата в балансировщик нагрузки.

Обновление: с этим решением x-forwarded- * headers не установлены.

Ответ 3

Вы можете переключиться на один экземпляр на Elastic Beanstalk и использовать ebextensions, чтобы загрузить сертификаты и настроить nginx для взаимного TLS.

Пример

.ebextensions/setup.config

files:
  "/etc/nginx/conf.d/00_elastic_beanstalk_ssl.conf":
    mode: "000755"
    owner: root
    group: root
    content: |
      server {
        listen 443;
        server_name example.com;

        ssl on;
        ssl_certificate /etc/nginx/conf.d/server.crt;
        ssl_certificate_key /etc/nginx/conf.d/server.key;
        ssl_client_certificate /etc/nginx/conf.d/ca.crt;
        ssl_verify_client on;

        gzip on;

        send_timeout            300s;
        client_body_timeout     300s;
        client_header_timeout   300s;
        keepalive_timeout       300s;

        location / {
          proxy_pass  http://nodejs;
          proxy_http_version  1.1;
          proxy_set_header  Connection "";
          proxy_set_header  Upgrade $http_upgrade;
          proxy_set_header  Host  $host;
          proxy_set_header  X-Real-IP $remote_addr;
          proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;

          proxy_set_header X-SSL-client-serial $ssl_client_serial;
          proxy_set_header X-SSL-client-s-dn $ssl_client_s_dn;
          proxy_set_header X-SSL-client-i-dn $ssl_client_i_dn;
          proxy_set_header X-SSL-client-session-id $ssl_session_id;
          proxy_set_header X-SSL-client-verify $ssl_client_verify;

          proxy_connect_timeout   300s;
          proxy_send_timeout      300s;
          proxy_read_timeout      300s;
        }
      }
  "/etc/nginx/conf.d/server.crt":
    mode: "000400"
    owner: root
    group: root
    content: |
      -----BEGIN CERTIFICATE-----
      MIJDkzCCAvygAwIBAgIJALrlDwddAmnYMA0GCSqGSIb3DQEBBQUAMIGJMQswCQYD
      ...
      LqGyLiCzbVtg97mcvqAmVcJ9TtUoabtzsRJt3fhbZ0KKIlzqkeZr+kmn8TqtMpGn
      r6oVDizulA==
      -----END CERTIFICATE-----
  "/etc/nginx/conf.d/server.key":
    mode: "000400"
    owner: root
    group: root
    content: |
      -----BEGIN RSA PRIVATE KEY-----
      MIJCXQIBAAKBgQCvnu08hroXwnbgsBOYOt+ipinBWNDZRtJHrH1Cbzu/j5KxyTWF
      ...
      f92RjCvuqdc17CYbjo9pmanaLGNSKf0rLx77WXu+BNCZ
      -----END RSA PRIVATE KEY-----
  "/etc/nginx/conf.d/ca.crt":
    mode: "000400"
    owner: root
    group: root
    content: |
      -----BEGIN CERTIFICATE-----
      MIJCizCCAfQCCQChmTtNzd2fhDANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMC
      ...
      4nCavUiq9CxhCzLmT6o/74t4uCDHjB+2+sIxo2zbfQ==
      -----END CERTIFICATE-----