Overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway

Transport Layer Security (TLS), voorheen bekend als Secure Sockets Layer (SSL), is de standaardbeveiligingstechnologie voor het tot stand brengen van een versleutelde koppeling tussen een webserver en een browser. Deze koppeling zorgt ervoor dat alle gegevens die worden doorgegeven tussen de webserver en browsers privé en versleuteld blijven. Application Gateway ondersteunt zowel TLS-beëindiging op de gateway als end-to-end TLS-versleuteling.

TLS-beëindiging

Application Gateway ondersteunt TLS-beëindiging bij de gateway, waarna verkeer doorgaans niet-versleuteld naar de back-endservers stroomt. Er zijn een aantal voordelen van het uitvoeren van TLS-beëindiging op de toepassingsgateway:

  • Verbeterde prestaties : de grootste prestatietreffer bij het uitvoeren van TLS-ontsleuteling is de eerste handshake. Om de prestaties te verbeteren, slaat de server die de ontsleuteling uitvoert TLS-sessie-id's op en beheert TLS-sessietickets. Als dit gebeurt bij de toepassingsgateway, kunnen alle aanvragen van dezelfde client de waarden in de cache gebruiken. Als dit gebeurt op de back-endservers, moet telkens wanneer de aanvragen van de client naar een andere server worden verzonden, de client opnieuw verifiëren. Het gebruik van TLS-tickets kan helpen dit probleem op te lossen, maar ze worden niet ondersteund door alle clients en kunnen moeilijk te configureren en beheren zijn.
  • Beter gebruik van de back-endservers : SSL/TLS-verwerking is zeer CPU-intensief en wordt steeds intensiever naarmate de sleutelgrootten toenemen. Door dit werk van de back-endservers te verwijderen, kunnen ze zich richten op wat ze het efficiëntst zijn bij het leveren van inhoud.
  • Intelligente routering : door het verkeer te ontsleutelen, heeft de toepassingsgateway toegang tot de aanvraaginhoud, zoals headers, URI, enzovoort, en kan deze gegevens gebruiken om aanvragen te routeren.
  • Certificaatbeheer : certificaten hoeven alleen te worden aangeschaft en geïnstalleerd op de toepassingsgateway en niet op alle back-endservers. Dit bespaart zowel tijd als geld.

Voor het configureren van TLS-beëindiging moet een TLS/SSL-certificaat worden toegevoegd aan de listener. Hierdoor kan de Application Gateway binnenkomend verkeer ontsleutelen en antwoordverkeer naar de client versleutelen. Het certificaat dat aan de Application Gateway is verstrekt, moet de PFX-indeling (Personal Information Exchange) hebben, die zowel de persoonlijke als de openbare sleutels bevat.

Belangrijk

Voor het certificaat op de listener moet de volledige certificaatketen worden geüpload (het basiscertificaat van de CA, de tussenliggende en het leaf-certificaat) om de vertrouwensketen vast te stellen.

Notitie

Application Gateway biedt geen mogelijkheid om een nieuw certificaat te maken of een certificaataanvraag naar een certificeringsinstantie te verzenden.

Voor een goed functionerende TLS-verbinding moet u ervoor zorgen dat het TLS/SSL-certificaat voldoet aan de volgende voorwaarden:

  • Dat de huidige datum en tijd binnen het datumbereik Geldig van en Geldig tot op het certificaat valt.
  • De algemene naam (CN) van het certificaat komt overeen met de host-header in de aanvraag. Als de client bijvoorbeeld een aanvraag indient bij https://www.contoso.com/, moet de algemene naam www.contoso.com zijn.

Certificaten die worden ondersteund voor TLS-beëindiging

Application Gateway ondersteunt de volgende typen certificaten:

  • CA-certificaat (certificeringsinstantie): een CA-certificaat is een digitaal certificaat dat is uitgegeven door een certificeringsinstantie (CA)
  • EV-certificaat (Extended Validation): een EV-certificaat is een certificaat dat voldoet aan de richtlijnen voor industriestandaardcertificaten. Hiermee wordt de browserzoekerbalk groen en wordt ook de bedrijfsnaam gepubliceerd.
  • Wildcard-certificaat: dit certificaat ondersteunt een willekeurig aantal subdomeinen op basis van *.site.com, waarbij het subdomein de *zou vervangen. Het biedt echter geen ondersteuning voor site.com, dus als de gebruikers toegang hebben tot uw website zonder het toonaangevende www te typen, wordt dat niet behandeld door het jokertekencertificaat.
  • Self-Signed certificaten: clientbrowsers vertrouwen deze certificaten niet en waarschuwen de gebruiker dat het certificaat van de virtuele service geen deel uitmaakt van een vertrouwensketen. Zelfondertekende certificaten zijn geschikt voor testen of omgevingen waarin beheerders de clients beheren en de beveiligingswaarschuwingen van de browser veilig kunnen omzeilen. Productieworkloads mogen nooit zelfondertekende certificaten gebruiken.

Zie TLS-beëindiging configureren met application gateway voor meer informatie.

Grootte van het certificaat

Controleer de sectie Application Gateway limieten om te weten welke maximale TLS/SSL-certificaatgrootte wordt ondersteund.

End-to-end TLS-versleuteling

Mogelijk wilt u geen niet-versleutelde communicatie met de back-endservers. Mogelijk hebt u beveiligingsvereisten, nalevingsvereisten of kan de toepassing alleen een beveiligde verbinding accepteren. Azure Application Gateway beschikt over end-to-end TLS-versleuteling ter ondersteuning van deze vereisten.

Met end-to-end TLS kunt u gevoelige gegevens versleutelen en veilig verzenden naar de back-end terwijl u de laag-7-taakverdelingsfuncties van Application Gateway gebruikt. Deze functies omvatten sessieaffiniteit op basis van cookies, URL-gebaseerde routering, ondersteuning voor routering op basis van sites, de mogelijkheid om X-Forwarded-*-headers te herschrijven of te injecteren, enzovoort.

Wanneer deze is geconfigureerd met de end-to-end TLS-communicatiemodus, beëindigt Application Gateway de TLS-sessies op de gateway en ontsleutelt het gebruikersverkeer. Vervolgens worden de geconfigureerde regels toegepast voor het selecteren van het juiste exemplaar van de back-endgroep waarnaar het verkeer moet worden doorgeleid. Application Gateway vervolgens een nieuwe TLS-verbinding met de back-endserver initiëren en gegevens opnieuw versleutelen met behulp van het openbare sleutelcertificaat van de back-endserver voordat de aanvraag naar de back-end wordt verzonden. Reacties van de webserver ondergaan hetzelfde proces terug naar de eindgebruiker. End-to-end TLS wordt ingeschakeld door de protocolinstelling in de back-end-HTTP-instelling in te stellen op HTTPS, die vervolgens wordt toegepast op een back-endpool.

Voor de Application Gateway- en WAF v1-SKU is het TLS-beleid van toepassing op zowel front-end- als back-endverkeer. Op de front-end fungeert Application Gateway als de server en dwingt het beleid af. Op de back-end fungeert Application Gateway als de client en verzendt de protocol-/coderingsgegevens als de voorkeur tijdens de TLS-handshake.

Voor de Application Gateway- en WAF v2-SKU is het TLS-beleid alleen van toepassing op het front-endverkeer en worden alle coderingen aangeboden aan de back-endserver, die controle heeft om specifieke coderingen en TLS-versie te selecteren tijdens de handshake.

Application Gateway communiceert alleen met de back-endservers waarvoor het certificaat is toegestaan met de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-autoriteiten en de CN van het certificaat overeenkomt met de hostnaam in de HTTP-back-endinstellingen. Dit zijn de vertrouwde Azure-services, zoals Azure App Service/Web Apps en Azure API Management.

Als de certificaten van de leden in de back-endpool niet zijn ondertekend door bekende CA-instanties, moet elk exemplaar in de back-endpool met end-to-end TLS zijn geconfigureerd met een certificaat om beveiligde communicatie mogelijk te maken. Door het certificaat toe te voegen, zorgt u ervoor dat de toepassingsgateway alleen communiceert met bekende back-endinstanties. Hierdoor wordt de end-to-end communicatie verder beveiligd.

Notitie

Het certificaat dat is toegevoegd aan de BACK-end-HTTP-instelling om de back-endservers te verifiëren, kan hetzelfde zijn als het certificaat dat is toegevoegd aan de listener voor TLS-beëindiging bij de toepassingsgateway of anders voor verbeterde beveiliging.

end to end TLS scenario

In dit voorbeeld worden aanvragen met behulp van TLS1.2 doorgestuurd naar back-endservers in Pool1 met behulp van end-to-end TLS.

End-to-end TLS en vermelding van certificaten toestaan

Application Gateway communiceert alleen met de back-endservers waarvoor het certificaat is toegestaan met de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-autoriteiten en de CN van het certificaat overeenkomt met de hostnaam in de HTTP-back-endinstellingen. Er zijn enkele verschillen in het end-to-end TLS-installatieproces met betrekking tot de versie van Application Gateway gebruikt. In de volgende sectie worden deze afzonderlijk uitgelegd.

End-to-end TLS met de v1-SKU

Als u end-to-end TLS wilt inschakelen met de back-endservers en voor Application Gateway om aanvragen naar hen te routeren, moeten de statustests slagen en een goede reactie retourneren.

Voor HTTPS-statustests gebruikt de Application Gateway v1 SKU een exacte overeenkomst van het verificatiecertificaat (openbare sleutel van het back-endservercertificaat en niet het basiscertificaat) dat moet worden geüpload naar de HTTP-instellingen.

Alleen verbindingen met bekende en toegestane back-ends zijn vervolgens toegestaan. De resterende back-ends worden als beschadigd beschouwd door de statuscontroles. Zelfondertekende certificaten zijn uitsluitend bedoeld voor testdoeleinden en het wordt afgeraden om deze in een productieomgeving te gebruiken. Dergelijke certificaten moeten worden toegestaan met de toepassingsgateway, zoals beschreven in de voorgaande stappen voordat ze kunnen worden gebruikt.

Notitie

Verificatie en installatie van vertrouwd basiscertificaat zijn niet vereist voor vertrouwde Azure-services, zoals Azure App Service. Ze worden standaard als vertrouwd beschouwd.

End-to-end TLS met de v2-SKU

Verificatiecertificaten zijn afgeschaft en vervangen door vertrouwde basiscertificaten in de Application Gateway v2-SKU. Ze werken op dezelfde manier als verificatiecertificaten met enkele belangrijke verschillen:

  • Certificaten die zijn ondertekend door bekende CA-instanties waarvan de CN overeenkomt met de hostnaam in de INSTELLINGEN van de HTTP-back-end, vereisen geen extra stap om TLS te laten werken.

    Als de back-endcertificaten bijvoorbeeld worden uitgegeven door een bekende CA en een CN van contoso.com heeft en het hostveld van de back-end-HTTP-instelling ook is ingesteld op contoso.com, zijn er geen extra stappen vereist. U kunt het http-instellingsprotocol voor de back-end instellen op HTTPS en zowel de statustest als het gegevenspad zouden TLS zijn ingeschakeld. Als u Azure App Service of andere Azure-webservices als back-end gebruikt, worden deze ook impliciet vertrouwd en zijn er geen verdere stappen vereist voor end-to-end TLS.

Notitie

Om een TLS/SSL-certificaat te kunnen vertrouwen, moet dat certificaat van de back-endserver zijn uitgegeven door een CA die bekend is. Als het certificaat niet is uitgegeven door een vertrouwde CERTIFICERINGsinstantie, controleert de toepassingsgateway of het certificaat van de verlenende CA is uitgegeven door een vertrouwde CA, enzovoort totdat een vertrouwde CA wordt gevonden (op welk moment een vertrouwde, beveiligde verbinding tot stand wordt gebracht) of er geen vertrouwde CA kan worden gevonden (op welk moment de toepassingsgateway de back-end beschadigd markeert). Daarom wordt het aanbevolen om het back-endservercertificaat zowel de basis- als de tussenliggende CA's te bevatten.

  • Als het back-endservercertificaat zelfondertekend of ondertekend is door onbekende CA/tussenpersonen, moet een vertrouwd basiscertificaat worden geüpload om end-to-end TLS in te schakelen in Application Gateway v2. Application Gateway communiceert alleen met back-ends waarvan het basiscertificaat van het servercertificaat overeenkomt met een van de lijst met vertrouwde basiscertificaten in de back-end-HTTP-instelling die is gekoppeld aan de pool.

  • Naast de overeenkomst met het basiscertificaat wordt Application Gateway v2 ook gevalideerd of de hostinstelling die is opgegeven in de http-instelling van de back-end overeenkomt met die van de algemene naam (CN) die wordt gepresenteerd door het TLS/SSL-certificaat van de back-endserver. Wanneer u probeert een TLS-verbinding met de back-end tot stand te brengen, stelt Application Gateway v2 de SNI-extensie (Server Name Indication) in op de host die is opgegeven in de http-instelling van de back-end.

  • Als de hostnaam van het back-enddoel wordt gekozen in plaats van het hostveld in de http-instelling van de back-end, wordt de SNI-header altijd ingesteld op de FQDN van de back-endpool en moet de CN op de TLS/SSL-certificaat van de back-endserver overeenkomen met de FQDN. Leden van back-endpools met IP-adressen worden in dit scenario niet ondersteund.

  • Het basiscertificaat is een base64 gecodeerd basiscertificaat van de back-endservercertificaten.

SNI-verschillen in de V1- en v2-SKU

Zoals eerder vermeld, beëindigt Application Gateway TLS-verkeer van de client op de Application Gateway Listener (laten we het de front-endverbinding noemen), ontsleutelt het verkeer, past de benodigde regels toe om te bepalen op welke back-endserver de aanvraag moet worden doorgestuurd en wordt een nieuwe TLS-sessie met de back-endserver tot stand gebracht (laten we deze de back-endverbinding noemen).

De volgende tabellen beschrijven de verschillen in SNI tussen de v1- en v2-SKU in termen van front-end- en back-endverbindingen.

Front-end TLS-verbinding (client naar toepassingsgateway)


Scenario v1 v2
Als de client SNI-header opgeeft en alle listeners voor meerdere sites zijn ingeschakeld met de vlag 'SNI vereisen' Retourneert het juiste certificaat en als de site niet bestaat (volgens de server_name), wordt de verbinding opnieuw ingesteld. Retourneert het juiste certificaat indien beschikbaar, anders retourneert het certificaat van de eerste HTTPS-listener volgens de volgorde die is opgegeven door de aanvraagrouteringsregels die zijn gekoppeld aan de HTTPS-listeners
Als de client geen SNI-header opgeeft en als alle headers voor meerdere sites zijn ingeschakeld met 'SNI vereisen' De verbinding opnieuw instellen Retourneert het certificaat van de eerste HTTPS-listener volgens de volgorde die is opgegeven door de aanvraagrouteringsregels die zijn gekoppeld aan de HTTPS-listeners
Als de client geen SNI-header opgeeft en er een basislistener is geconfigureerd met een certificaat Retourneert het certificaat dat is geconfigureerd in de basislistener naar de client (standaard- of terugvalcertificaat) Retourneert het certificaat dat is geconfigureerd in de basislistener

Back-end-TLS-verbinding (toepassingsgateway naar de back-endserver)

Voor testverkeer


Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Stel in als FQDN uit de back-endpool. Volgens RFC 6066 zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet DNS omzetten in het IP-adres van de back-endserver (openbaar of privé)
SNI-header (server_name) wordt ingesteld als de hostnaam van de aangepaste test die is gekoppeld aan de HTTP-instellingen (indien geconfigureerd), anders van de hostnaam die wordt vermeld in de HTTP-instellingen, anders van de FQDN die in de back-endpool wordt vermeld. De volgorde van prioriteit is de back-endpool van aangepaste HTTP-instellingen > voor tests>.
Opmerking: Als de hostnamen die zijn geconfigureerd in HTTP-instellingen en aangepaste tests verschillen, wordt SNI ingesteld als de hostnaam van de aangepaste test.
Als het adres van de back-endpool een IP-adres (v1) is of als de aangepaste testhostnaam is geconfigureerd als IP-adres (v2) SNI (server_name) wordt niet ingesteld.
Opmerking: In dit geval moet de back-endserver een standaardcertificaat/terugvalcertificaat kunnen retourneren. Dit moet worden toegestaan in HTTP-instellingen onder verificatiecertificaat. Als er geen standaard-/terugvalcertificaat is geconfigureerd op de back-endserver en SNI wordt verwacht, kan de server de verbinding opnieuw instellen en leiden tot testfouten
In de volgorde van prioriteit die eerder is vermeld, als ze ip-adres hebben als hostnaam, wordt SNI niet ingesteld op basis van RFC 6066.
Opmerking: SNI wordt ook niet ingesteld in v2-tests als er geen aangepaste test is geconfigureerd en er geen hostnaam is ingesteld op HTTP-instellingen of back-endpool

Notitie

Als een aangepaste test niet is geconfigureerd, verzendt Application Gateway een standaardtest in deze indeling - <protocol>://127.0.0.1:<port>/. Voor een standaard-HTTPS-test wordt deze bijvoorbeeld verzonden als https://127.0.0.1:443/. De hier genoemde 127.0.0.1 wordt alleen gebruikt als HTTP-hostheader en volgens RFC 6066 wordt niet gebruikt als SNI-header. Raadpleeg de gids voor het oplossen van problemen met de back-endstatus voor meer informatie over statustestfouten.

Voor live verkeer


Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Stel in als FQDN uit de back-endpool. Volgens RFC 6066 zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet DNS omzetten in het IP-adres van de back-endserver (openbaar of privé)
SNI-header (server_name) is ingesteld als de hostnaam van de HTTP-instellingen, anders wordt de optie PickHostnameFromBackendAddress gekozen of als er geen hostnaam wordt vermeld, wordt deze ingesteld als de FQDN in de configuratie van de back-endpool
Als het adres van de back-endpool een IP-adres is of als hostnaam niet is ingesteld in HTTP-instellingen SNI wordt niet ingesteld volgens RFC 6066 als de vermelding van de back-endpool geen FQDN is SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam.
Hostnaam is niet opgegeven in HTTP-Instellingen, maar er wordt een FQDN opgegeven als het doel voor een lid van een back-endpool SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam. SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam.

Volgende stappen

Nadat u meer hebt geleerd over end-to-end TLS, gaat u naar End-to-End TLS configureren met behulp van Application Gateway met PowerShell om een toepassingsgateway te maken met behulp van end-to-end TLS.