Czy odwrotny serwer proxy może korzystać z SNI z SSL?

Muszę obsługiwać kilka aplikacji przez https przy użyciu jednego zewnętrznego adresu IP.

Certyfikaty ssl nie powinny być zarządzane na zwrotnym serwerze proxy. Są one instalowane na serwerach aplikacji.

Czy odwrotne proxy może być skonfigurowane do używania SNI i przekazywania ssl do zakończenia w punkcie końcowym?

Czy jest to możliwe przy użyciu czegoś takiego jak Nginx lub Apache? Jak wygląda konfiguracja?

Jest to możliwe dzięki Haproxy. Możesz skonfigurować proxy TCP i wyodrębnić SNI i wykonać routing w oparciu o SNI. Oto przykład:

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

Konieczne jest opóźnienie żądania do momentu przywitania SSL, w przeciwnym razie haproxy spróbuje nawiązać połączenie przed otrzymaniem nagłówka SNI.

Korzystam z serwerów o wadze 0, ponieważ w mojej obecnej konfiguracji mam tylko jeden serwer dla każdego SNI i nie chcę, aby otrzymywały losowe żądania. Prawdopodobnie możesz znaleźć lepsze sposoby na to.

Mam nadzieję, że to pomoże.

Możesz użyć sniproxy: https://github.com/dlundquist/sniproxy

Przykładowa konfiguracja:

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
}

Jest to z pewnością możliwe, nawet teraz w 2019 roku dzięki nadchodzącej TLS 1.3! Wiele serwerów WWW lub wyspecjalizowanych serwerów proxy zapewnia tę funkcjonalność od razu po wyjęciu z pudełka:

• Nginx ≥ 1.11.5 (Debian ≥ buster lub stretch-backports)
• HAProxy ≥ 1,5 (Debian ≥ jessie)
• Sniproxy (Debian ≥ buster)
• itp.

To jest przykładowa konfiguracja dla Nginx, która jest bardzo popularnym wyborem dla konfiguracji wymagających odwrotnego proxy:

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;
  }
}

Odpowiednimi modułami Nginx są stream_corei stream_ssl_preread. Instrukcje:

• https://nginx.org/en/docs/stream/ngx_stream_core_module.html
• https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html