Udostępnij za pośrednictwem

Omówienie zakończenia sesji TLS i kompleksowego szyfrowania TLS za pomocą usługi Application Gateway

Transport Layer Security (TLS), wcześniej znany jako Secure Sockets Layer (SSL), to standardowa technologia zabezpieczeń do ustanawiania szyfrowanego połączenia między serwerem internetowym a przeglądarką. Ten link gwarantuje, że wszystkie dane przekazywane między serwerem internetowym a przeglądarkami pozostaną prywatne i zaszyfrowane. Usługa Application Gateway obsługuje zarówno zakończenie protokołu TLS w bramie, jak i kompleksowe szyfrowanie TLS.

Zakończenie szyfrowania TLS

Usługa Application Gateway obsługuje kończenie żądań TLS w bramie, po czym ruch zwykle przepływa niezaszyfrowany do serwerów zaplecza. Istnieje wiele zalet kończenia żądań protokołu TLS w bramie aplikacji:

  • Improved performance – The biggest performance hit when doing TLS decryption is the initial handshake. Aby zwiększyć wydajność, serwer buforuje identyfikatory sesji TLS i zarządza biletami sesji TLS. W przypadku wykonania tej czynności w bramie aplikacji wszystkie żądania z tego samego klienta mogą używać wartości buforowanych. Jeśli odbywa się to na serwerach zaplecza, za każdym razem, gdy żądania klienta przechodzą do innego serwera, klient musi ponownie uwierzytelnić. Użycie biletów TLS może pomóc rozwiązać ten problem, ale nie są one obsługiwane przez wszystkich klientów i mogą być trudne do skonfigurowania i zarządzania.
  • Lepsze wykorzystanie serwerów zaplecza — przetwarzanie protokołu SSL/TLS jest bardzo intensywnie obciążane procesorem CPU i staje się coraz bardziej intensywne w miarę zwiększania rozmiarów kluczy. Usunięcie tej pracy z serwerów zaplecza pozwala im skupić się na tym, w czym są najbardziej wydajne, czyli na dostarczaniu treści.
  • Inteligentne trasowanie — poprzez odszyfrowanie ruchu, brama aplikacji ma dostęp do zawartości żądania, takiej jak nagłówki, URI itd., i może używać tych danych do kierowania żądań.
  • Zarządzanie certyfikatami — certyfikaty muszą być kupowane i instalowane tylko w bramie aplikacji, a nie na wszystkich serwerach zaplecza. Pozwala to zaoszczędzić czas i pieniądze.

Aby skonfigurować kończenie żądań protokołu TLS, należy dodać certyfikat TLS/SSL do odbiornika. Dzięki temu usługa Application Gateway może odszyfrować ruch przychodzący i szyfrować ruch odpowiedzi do klienta. Certyfikat dostarczony do usługi Application Gateway musi być w formacie Wymiany informacji osobistych (PFX), który zawiera zarówno klucze prywatne, jak i publiczne. Obsługiwane algorytmy PFX są wyświetlane w funkcji PFXImportCertStore.

Ważne

The certificate on the listener requires the entire certificate chain to be uploaded (the root certificate from the CA, the intermediates and the leaf certificate) to establish the chain of trust.

Uwaga

Usługa Application Gateway nie zapewnia możliwości tworzenia nowego certyfikatu ani wysyłania żądania certyfikatu do urzędu certyfikacji.

Aby połączenie TLS działało, należy upewnić się, że certyfikat TLS/SSL spełnia następujące warunki:

  • That the current date and time is within the "Valid from" and "Valid to" date range on the certificate.
  • That the certificate's "Common Name" (CN) matches the host header in the request. Jeśli na przykład klient wysyła żądanie do https://www.contoso.com/, to nazwa wspólna (CN) musi być www.contoso.com.

Jeśli występują błędy dotyczące nazwy pospolitej certyfikatu zaplecza (CN), zobacz nasz przewodnik rozwiązywania problemów.

Certificates supported for TLS termination

Usługa Application Gateway obsługuje następujące typy certyfikatów:

  • Certyfikat CA (Urząd Certyfikacji): certyfikat CA jest certyfikatem cyfrowym wystawionym przez Urząd Certyfikacji.
  • Certyfikat EV (rozszerzonej weryfikacji): certyfikat EV jest certyfikatem zgodnym z wytycznymi dotyczącymi certyfikatów standardowych w branży. Spowoduje to przekształcenie paska lokalizatora przeglądarki na zielony i opublikowanie nazwy firmy.
  • Certyfikat typu wildcard: ten certyfikat obsługuje dowolną liczbę poddomen bazujących na *.site.com, gdzie Twoja poddomena zastąpi *. Nie obsługuje jednak site.com, więc jeśli użytkownicy uzyskują dostęp do Twojej strony internetowej bez wpisywania wiodącego "www", certyfikat wieloznaczny tego nie obejmie.
  • Certyfikaty z podpisem własnym: przeglądarki klienckie nie ufają tym certyfikatom i ostrzegają użytkownika, że certyfikat usługi wirtualnej nie jest częścią łańcucha zaufania. Certyfikaty z podpisem własnym są dobre do testowania lub środowisk, w których administratorzy kontrolują klientów i mogą bezpiecznie pomijać alerty zabezpieczeń przeglądarki. Obciążenia produkcyjne nigdy nie powinny używać certyfikatów z podpisem własnym.

Aby uzyskać więcej informacji, zobacz konfigurowanie kończenia żądań protokołu TLS za pomocą bramy aplikacji.

Rozmiar certyfikatu

Sprawdź sekcję Limity usługi Application Gateway, aby poznać obsługiwany maksymalny rozmiar certyfikatu TLS/SSL.

Kompleksowe szyfrowanie TLS

Możesz nie chcieć, aby komunikacja z serwerami zaplecza była nieszyfrowana. Być może masz wymagania dotyczące zabezpieczeń, wymagania dotyczące zgodności lub aplikacja może akceptować tylko bezpieczne połączenie. aplikacja systemu Azure Gateway ma kompleksowe szyfrowanie TLS w celu obsługi tych wymagań.

Kompleksowe szyfrowanie TLS umożliwia szyfrowanie i bezpieczne przesyłanie poufnych danych do zaplecza podczas korzystania z funkcji równoważenia obciążenia warstwy 7 usługi Application Gateway. These features include cookie-based session affinity, URL-based routing, support for routing based on sites, the ability to rewrite or inject X-Forwarded-* headers, and so on.

Po skonfigurowaniu w trybie kompleksowej komunikacji TLS usługa Application Gateway przerywa sesje protokołu TLS w bramie i odszyfrowuje ruch użytkowników. It then applies the configured rules to select an appropriate backend pool instance to route traffic to. Następnie usługa Application Gateway inicjuje nowe połączenie TLS z serwerem zaplecza i ponownie szyfruje dane przy użyciu certyfikatu klucza publicznego serwera zaplecza przed przesłaniem żądania do zaplecza. Każda odpowiedź z serwera sieci Web przechodzi przez ten sam proces z powrotem do użytkownika końcowego. End-to-end TLS is enabled by setting protocol setting in Backend HTTP Setting to HTTPS, which is then applied to a backend pool.

In Application Gateway v1 SKU gateways, TLS policy applies the TLS version only to frontend traffic and the defined ciphers to both frontend and backend targets. In Application Gateway v2 SKU gateways, TLS policy only applies to frontend traffic, backend TLS connections will always be negotiated via TLS 1.0 to TLS 1.2 versions.

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat umieszczony na liście dozwolonych w usłudze Application Gateway, lub których certyfikaty są podpisane przez renomowane urzędy certyfikacji, a CN certyfikatu jest zgodne z nazwą hosta w ustawieniach zaplecza HTTP. Obejmują one zaufane usługi platformy Azure, takie jak Azure App Service/Web Apps i Azure API Management.

If the certificates of the members in the backend pool aren't signed by well-known CA authorities, then each instance in the backend pool with end to end TLS enabled must be configured with a certificate to allow secure communication. Dodanie certyfikatu zapewnia, że brama aplikacji komunikuje się tylko z zaufanymi instancjami zaplecza. Dodatkowo zabezpiecza to kompleksową komunikację.

Uwaga

The certificate added to Backend HTTP Setting to authenticate the backend servers can be the same as the certificate added to the listener for TLS termination at application gateway or different for enhanced security.

scenariusz TLS od końca do końca

W tym przykładzie żądania używające protokołu TLS1.2 są kierowane do serwerów zaplecza w puli Pool1 przy użyciu kompleksowego protokołu TLS.

End to end TLS and allow listing of certificates

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat umieszczony na liście dozwolonych w usłudze Application Gateway, lub których certyfikaty są podpisane przez renomowane urzędy certyfikacji, a CN certyfikatu jest zgodne z nazwą hosta w ustawieniach zaplecza HTTP. Istnieją pewne różnice w procesie kompleksowej konfiguracji protokołu TLS w odniesieniu do używanej wersji usługi Application Gateway. W poniższej sekcji opisano wersje osobno.

End-to-end TLS with the v1 SKU

To enable end-to-end TLS with the backend servers and for Application Gateway to route requests to them, the health probes must succeed and return healthy response.

For HTTPS health probes, the Application Gateway v1 SKU uses an exact match of the authentication certificate (public key of the backend server certificate and not the root certificate) to be uploaded to the HTTP settings.

Następnie zezwala się tylko na połączenia ze znanymi i dozwolonymi backendami. The remaining backends are considered unhealthy by the health probes. Certyfikaty z podpisem własnym są przeznaczone tylko do celów testowych i nie są zalecane dla obciążeń w środowisku produkcyjnym. Takie certyfikaty muszą być dodane do listy dozwolonych w bramie aplikacji, zgodnie z opisem w poprzednich krokach, zanim będą mogły być używane.

Uwaga

Uwierzytelnianie i konfiguracja zaufanego certyfikatu głównego nie są wymagane dla zaufanych usług Azure, takich jak Azure App Service. Są one domyślnie uznawane za zaufane.

End-to-end TLS with the v2 SKU

Certyfikaty uwierzytelniania zostały wycofane i zastąpione przez zaufane certyfikaty główne w jednostce SKU usługi Application Gateway w wersji 2. Działają podobnie do certyfikatów uwierzytelniania z kilkoma kluczowymi różnicami:

  • Certyfikaty podpisane przez dobrze znane urzędy certyfikacji, których CN pasuje do nazwy hosta w ustawieniach zaplecza HTTP, nie wymagają żadnych dodatkowych kroków, aby end-to-end TLS działał poprawnie.

    For example, if the backend certificates are issued by a well known CA and has a CN of contoso.com, and the backend http setting’s host field is also set to contoso.com, then no additional steps are required. Protokół ustawień zaplecza HTTP można ustawić na HTTPS, a zarówno sonda kondycji, jak i ścieżka danych będą obsługiwane przez protokół TLS. If you're using Azure App Service or other Azure web services as your backend, then these are implicitly trusted as well and no further steps are required for end to end TLS.

Uwaga

Aby certyfikat TLS/SSL był zaufany, ten certyfikat serwera zaplecza musi zostać wystawiony przez urząd certyfikacji, który jest dobrze znany. If the certificate was not issued by a trusted CA, the application gateway will then check to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the application gateway will mark the backend unhealthy). Therefore, it is recommended the backend server certificate contain both the root and intermediate CAs.

  • If the backend server certificate is self-signed, or signed by unknown CA/intermediaries, then to enable end to end TLS in Application Gateway v2 a trusted root certificate must be uploaded. Application Gateway will only communicate with backends whose server certificate’s root certificate matches one of the list of trusted root certificates in the backend http setting associated with the pool.

  • Oprócz dopasowania certyfikatu głównego, usługa Application Gateway w wersji 2 również sprawdza, czy ustawienie hosta w ustawieniach HTTP zaplecza jest zgodne z nazwą wspólną (CN) podaną przez certyfikat TLS/SSL serwera zaplecza. Podczas próby nawiązania połączenia TLS z zapleczem, Application Gateway w wersji 2 konfiguruje rozszerzenie SNI (Server Name Indication) dla hosta określonego w ustawieniu HTTP zaplecza.

  • If pick hostname from backend target is chosen instead of the Host field in the backend http setting, then the SNI header is always set to the backend pool FQDN and the CN on the backend server TLS/SSL certificate must match its FQDN. Backend pool members with IPs aren't supported in this scenario.

  • Certyfikat główny jest certyfikatem głównym zakodowanym w formacie base64 z certyfikatów serwera zaplecza.

SNI differences in the v1 and v2 SKU

Jak wspomniano wcześniej, usługa Application Gateway przerywa ruch TLS z klienta na odbiorniku usługi Application Gateway (nazwijmy go połączeniem frontonu), odszyfrowuje ruch, stosuje reguły niezbędne do określenia serwera zaplecza, do którego ma zostać przekazane żądanie, i ustanawia nową sesję protokołu TLS z serwerem zaplecza (nazwijmy go połączeniem zaplecza).

W poniższych tabelach opisano różnice w SNI między jednostkami SKU w wersjach v1 i v2 pod względem połączeń warstwy frontowej i warstwy zaplecza.

Frontend TLS connection (client to application gateway)

Scenariusz v1 v2
If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag Zwraca odpowiedni certyfikat i jeśli witryna nie istnieje (zgodnie z nazwą_serwera), połączenie zostanie zresetowane. Zwraca odpowiedni certyfikat, jeśli jest dostępny, w przeciwnym razie zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
Jeśli klient nie określi nagłówka SNI i wszystkie nagłówki dla wielu witryn mają włączoną opcję "Wymagaj SNI" Resetuje połączenie Zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
If the client doesn't specify SNI header and if there's a basic listener configured with a certificate Returns the certificate configured in the basic listener to the client (default or fallback certificate) Zwraca certyfikat skonfigurowany w odbiorniku podstawowym

Uwaga

When the client does not specify an SNI header, it is recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.

Tip

Flagę SNI można skonfigurować przy użyciu programu PowerShell lub przy użyciu szablonu usługi ARM. Aby uzyskać więcej informacji, zobacz RequireServerNameIndication i Szybkie rozpoczęcie: kieruj ruchem internetowym za pomocą Azure Application Gateway - szablon ARM.

Backend TLS connection (application gateway to the backend server)

For probe traffic

Scenariusz v1 v2
SNI (server_name) header during the TLS handshake as FQDN Set as FQDN from the backend pool. Zgodnie z RFC 6066 literalne adresy IPv4 i IPv6 nie są dozwolone w nazwie hosta SNI.
Note: FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private)		 SNI header (server_name) is set as the hostname from the custom probe attached to the HTTP settings (if configured), otherwise from the hostname mentioned in the HTTP settings, otherwise from the FQDN mentioned in the backend pool. The order of precedence is custom probe > HTTP settings > backend pool.
Note: If the hostnames configured in HTTP settings and custom probe are different, then according to the precedence, SNI will be set as the hostname from the custom probe.
If the backend pool address is an IP address (v1) or if custom probe hostname is configured as IP address (v2) SNI (server_name) nie zostanie ustawiona.
Uwaga: W takim przypadku serwer zaplecza powinien mieć możliwość zwrócenia certyfikatu domyślnego/rezerwowego. Powinno to być wymienione na liście dozwolonych w ustawieniach protokołu HTTP w ramach certyfikatu uwierzytelniania. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures		 W kolejności pierwszeństwa wymienionej wcześniej, jeśli mają adres IP jako nazwę hosta, SNI nie zostanie ustawione zgodnie z RFC 6066.
Note: SNI also won't be set in v2 probes if no custom probe is configured and no hostname is set on HTTP settings or backend pool

Uwaga

Jeśli sonda niestandardowa nie jest skonfigurowana, usługa Application Gateway wysyła sondę domyślną w tym formacie — <protocol>://127.0.0.1:<port>/. Na przykład w przypadku domyślnej sondy HTTPS zostanie ona wysłana jako https://127.0.0.1:443/. Należy pamiętać, że wymieniona tutaj wersja 127.0.0.1 jest używana tylko jako nagłówek hosta HTTP i zgodnie z specyfikacją RFC 6066 nie będzie używana jako nagłówek SNI. For more information on health probe errors, check the backend health troubleshooting guide.

Dla bieżącego ruchu drogowego

Scenariusz v1 v2
SNI (server_name) header during the TLS handshake as FQDN Set as FQDN from the backend pool. Zgodnie z RFC 6066 literalne adresy IPv4 i IPv6 nie są dozwolone w nazwie hosta SNI.
Note: FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private)		 Nagłówek SNI (server_name) jest ustawiany jako nazwa hosta z ustawień HTTP, w przeciwnym razie, jeśli wybrano opcję PickHostnameFromBackendAddress lub jeśli nie zostanie podana nazwa hosta, zostanie on ustawiony jako FQDN w konfiguracji puli serwerów zaplecza.
If the backend pool address is an IP address or hostname isn't set in HTTP settings SNI won't be set as per RFC 6066 if the backend pool entry isn't an FQDN Nazwa SNI zostanie ustawiona jako nazwa hosta z FQDN podanego przez klienta, a CN zapleczowego certyfikatu musi być zgodny z tą nazwą hosta.
Hostname isn't provided in HTTP Settings, but an FQDN is specified as the Target for a backend pool member Nazwa SNI zostanie ustawiona jako nazwa hosta z FQDN podanego przez klienta, a CN zapleczowego certyfikatu musi być zgodny z tą nazwą hosta. Nazwa SNI zostanie ustawiona jako nazwa hosta z FQDN podanego przez klienta, a CN zapleczowego certyfikatu musi być zgodny z tą nazwą hosta.

Następne kroki

Po zapoznaniu się z end-to-end TLS przejdź do Konfigurowanie end-to-end TLS przy użyciu usługi Application Gateway i programu PowerShell, aby utworzyć bramę aplikacji przy użyciu end-to-end TLS.