web-dev-qa-db-fra.com

Prise en charge de TLS/HTTPS à deux voies avec ELB

Un moyen (ou côté serveur) TLS/HTTPS avec Amazon Elastic Load Balancing est bien documenté

La prise en charge de TLS/HTTPS dans les deux sens (ou côté client) n’est pas aussi claire dans la documentation.

En supposant que ELB termine une connexion TLS/HTTPS:

  1. ELB prend-il en charge les connexions client authentifié HTTPS?
  2. Si tel est le cas, un serveur desservi par ELB reçoit-il un en-tête X-Forwarded- * pour identifier le client authentifié par ELB? 

ELB prend en charge le transfert TCP afin qu'un serveur hébergé EC2 puisse établir une connexion bidirectionnelle TLS/HTTPS, mais dans ce cas, je suis intéressé par le fait que ELB termine la connexion TLS/HTTPS et identifie le client. 

sslamazon-web-servicesamazon-elbauthenticationtwo-way
25
pd40

Je ne vois pas comment cela pourrait se produire, en mode HTTPS à deux extrémités, car ELB est en train d'établir une deuxième connexion TCP au serveur d'arrière-plan et de déchiffrer/chiffrer en interne la charge utile vers/depuis le client et serveur ... afin que le serveur ne voie pas directement le certificat client, et il n'y a pas d'en-têtes X-Forwarded- * documentés autres que -Pour, -Proto et -Port.

En revanche, avec un ELB fonctionnant en mode TCP, la négociation SSL est effectuée directement entre le client et le serveur, ELB liant aveuglément les flux. Si le serveur prend en charge le protocole PROXY , vous pouvez activer cette fonctionnalité dans l'ELB afin de pouvoir identifier l'adresse IP et le port d'origine du client sur le serveur, ainsi que le certificat client. directement parce que le client négocierait directement avec vous ... bien que cela signifie que vous ne transférez plus le protocole SSL à ELB, ce qui peut faire partie de l'objectif de ce que vous essayez de faire.

Mettre à jour: 

Il ne semble pas y avoir de moyen de faire tout ce que vous voulez - décharger SSL et identifier le certificat du client - avec ELB seul. L’information ci-dessous est présentée «à sa juste valeur».

Apparemment, HAProxy possède prise en charge des certificats côté client dans la version 1.5 , et transmet les informations de certificat dans les en-têtes X-. Etant donné que HAProxy supporte également le protocole PROXY via la configuration (un peu comme tcp-request connection expect-proxy ) ... il semble donc envisageable d'utiliser HAProxy derrière un ELB en mode TCP, HAProxy terminant la connexion SSL et transférant both les informations IP/port du client provenant d'ELB (via le protocole PROXY) et les informations de certificat client vers le serveur d'applications ... vous permettant ainsi de conserver le déchargement SSL.

Je le mentionne car cela semble être une solution complémentaire, peut-être plus complète que l'une ou l'autre des plates-formes seules, et, au moins en 1.4, les deux produits fonctionnent parfaitement ensemble. J'utilise HAProxy 1.4 derrière ELB avec succès pour toutes les demandes de mon La plus grande plate-forme Web (dans mon cas, ELB décharge le protocole SSL - il n'y a pas de certificats de client) et cela semble être une combinaison solide malgré la redondance apparente des équilibreurs de charge en cascade. J'aime avoir ELB comme la seule chose disponible sur le grand méchant Internet, bien que je n’aie aucune raison de penser que HAProxy exposé directement serait problématique en soi. Dans mon application, les ELB sont là pour équilibrer les HAProxies dans les A/Z (que j'avais à l'origine l'intention de mettre également à l'échelle automatique, mais l'utilisation du processeur est restée si faible même pendant notre saison occupée que je n'en ai jamais eu plus d'un. La Zone de disponibilité, et j’ai jamais perdu un, pour le moment ...) qui peut ensuite filtrer, transférer et modifier les en-têtes avant de transférer le trafic sur la plate-forme proprement dite, en plus de me permettre de journaliser, réécriture et contrôle du trafic que je n'ai pas avec ELB seul.

14
Michael - sqlbot

Si votre back-end peut prendre en charge les connexions HTTPS authentifiées par le client, vous pouvez utiliser ELB comme TCP sur le port 443 à TCP sur le port que votre back-end écoute. Ceci fera juste à ELB de renvoyer une demande non chiffrée directement à votre ordinateur. Cette configuration ne nécessite pas non plus l'installation d'un certificat SSL sur un équilibreur de charge.

Mise à jour: avec cette solution, les en-têtes x-forwarded- * ne sont pas définis.

3
scrutari

Vous pouvez passer en instance unique sur Elastic Beanstalk et utiliser ebextensions to pour télécharger les certificats et configurer nginx pour TLS mutuel.

Exemple

.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-----
0
Miguel Mota