web-dev-qa-db-fra.com

Un proxy inversé peut-il utiliser SNI avec SSL passer?

J'ai besoin de servir plusieurs applications sur HTTPS à l'aide d'une adresse IP externe.

Les certificats SSL ne doivent pas être gérés sur le proxy inverse. Ils sont installés sur les serveurs d'applications.

Un proxy inverse peut-il être configuré pour utiliser SNI et passer SSL à l'aide de la terminaison au point final?

Est-ce que cela utilise quelque chose comme Nginx ou Apache? À quoi ressemble la configuration?

reverse-proxyhttpssni
18
user319862

Ceci IS possible avec haproxy. Vous pouvez configurer un proxy TCP et extraire le SNI et effectuer un routage en fonction de la SNI. Voici un exemple:

backend be.app1
    mode tcp
    no option checkcache
    no option httpclose
    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }
    tcp-request content reject
    use-server server1 if { req.ssl_sni -m beg app1. }
    server server1 server1:8443 check id 1 weight 0

Il est essentiel de retarder la demande jusqu'à ce que vous obteniez le SSL Hello, sinon Haprexy essaiera de créer une connexion avant de recevoir l'en-tête SNI.

J'utilise des serveurs avec poids 0 car, dans ma configuration actuelle, je n'ai qu'un serveur fonctionnant pour chaque SNI et je ne souhaite pas qu'ils reçoivent des demandes aléatoires. Vous pouvez probablement trouver de meilleures façons de jouer avec cela.

J'espère que ça aide.

14
Florin Asăvoaie

Vous pouvez utiliser Sniproxy: https://github.com/dlundquist/sniproxy

Un exemple de configuration:

listener 0.0.0.0:443 {
    protocol tls
    table TableHTTPS
    fallback 127.0.0.1:8443
}

listener 0.0.0.0:80 {
    protocol http
    table TableHTTP
    fallback 127.0.0.1:8080
}

table TableHTTPS {
    domain1.com backend1:443
    domain2.org backend2:443
}

table TableHTTP {
    domain1.com backend1:80
    domain2.org backend2:80
}
5
mick

Ceci est certainement possible, même maintenant en 2019 avec le prochain TLS 1.3! De nombreux serveurs Web ou proxy inverse spécialisés fournissent cette fonctionnalité hors de la boîte:

  • Nginx ≥ 1.11.5 (Debian ≥ Buster ou Stretch-Backports)
  • Haproxy ≥ 1.5 (Debian ≥ Jessie)
  • Sniproxy (Debian ≥ Buster)
  • etc.

Ceci est un exemple de configuration pour NGinx, qui est un choix très populaire pour les configurations nécessitant un proxy inverse:

stream {
  map $ssl_preread_server_name $selected_upstream {
    example.org upstream_1;
    example.net upstream_2;
    example.com upstream_3;
    default upstream_4;
  }
  upstream upstream_1 { server 10.0.0.1:443; }
  upstream upstream_2 { server 10.0.0.2:443; }
  upstream upstream_3 { server 10.0.0.3:443; }
  upstream upstream_4 { server 10.0.0.4:443; }
  server {
    listen 10.0.0.5:443;
    proxy_pass $selected_upstream;
    ssl_preread on;
  }
}

Les modules Nginx pertinents sont stream_core et stream_ssl_preread. Manuels:

2
vog

Sachez que si les serveurs cibles utilisent le même certificat (ce qui n'est pas très improbable lorsque des certificats génériques sont utilisés), http/2 ne peut pas être utilisé. Il acheminera votre trafic sur le mauvais serveur.

Échantillon:

  • a.Example.com avec certificat * .example.com.com
  • b.example.com avec certificat * .example.com.com

Si A.Example.com et B.Example.com sont traités par le même proxy inverse, une seule connexion sera ouverte - et diffusée sur le serveur appelée pour la première fois. Donc, si vous appelez A.Example.com, les demandes futures à B.Example.com peuvent atteindre le mauvais serveur Web.

Pour référence, voir

0
turbophi