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

  • Artikel
  • 12 minuten om te lezen

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 biedt ondersteuning voor TLS-beëindiging op de gateway, waarna het verkeer doorgaans niet-versleuteld naar de back-endservers stroomt. Er zijn een aantal voordelen van het gebruik van TLS-beëindiging op de toepassingsgateway:

  • Verbeterde prestaties: de grootste prestatieverbetering bij het ontsleutelen van TLS is de eerste handshake. Om de prestaties te verbeteren, cachet de server die de ontsleuteling doet TLS-sessie-ID's en beheert deze TLS-sessietickets. Als dit wordt gedaan op de toepassingsgateway, kunnen alle aanvragen van dezelfde client de waarden in de cache gebruiken. Als dit wordt gedaan op de back-endservers, moet de client elke keer dat de aanvragen naar een andere server gaan, opnieuw worden geverifieerd. Het gebruik van TLS-tickets kan dit probleem verhelpen, maar ze worden niet door alle clients ondersteund en kunnen moeilijk te configureren en te 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 waar ze het efficiëntst in zijn, het leveren van inhoud.
  • Intelligente routering: door het verkeer te ontsleutelen, heeft de toepassingsgateway toegang tot de inhoud van de aanvraag, zoals headers, URI,, en kan deze gegevens worden gebruikt 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 tijd en geld.

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

Belangrijk

Voor het certificaat op de listener moet de hele certificaatketen worden geüpload (het basiscertificaat van de CA, de tussenliggende certificaten en het leaf-certificaat) om de vertrouwensketen tot stand te kunnen laten komen.

Notitie

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

De TLS-verbinding werkt alleen als 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 (uitgebreide validatie) : Een EV-certificaat is een certificaat dat voldoet aan de industriestandaard certificaatrichtlijnen. Hierdoor wordt de browserzoekerbalk groen en wordt ook de bedrijfsnaam gepubliceerd.
  • Jokertekencertificaat: dit certificaat ondersteunt een groot aantal subdomeinen op basis van *.site.com, waarbij uw subdomein de *vervangt. Het biedt echter geen ondersteuning voor site.com, dus als de gebruikers uw website openen zonder het vooraanstaande 'www' te typen, wordt dat niet door het jokertekencertificaat ondersteund.
  • 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. Zelf-ondertekende certificaten zijn goed voor tests of omgevingen waarin beheerders de clients beheren en de beveiligingswaarschuwingen van de browser veilig kunnen omzeilen. Productieworkloads mogen nooit zelf-ondertekende certificaten gebruiken.

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

Grootte van het certificaat

Raadpleeg de Application Gateway voor de maximale TLS/SSL-certificaatgrootte die 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 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 Layer-7-taakverdelingsfuncties van Application Gateway gebruikt. Deze functies omvatten sessie-affiniteit op basis van cookies, routering op basis van URL's, ondersteuning voor routering op basis van sites, de mogelijkheid om X-Forwarded-*-headers te herschrijven of te injecteren, en meer.

Wanneer de TLS-communicatiemodus end-to-end is geconfigureerd, Application Gateway de TLS-sessies op de gateway beëindigd en wordt het gebruikersverkeer ontsleuteld. 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 initieert vervolgens een nieuwe TLS-verbinding met de back-endserver en versleutelt gegevens opnieuw 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 BACK-end-HTTP-instelling in te stellen op HTTPS, dat vervolgens wordt toegepast op een back-endpool.

Voor de Application Gateway en WAF v1 SKU is het TLS-beleid van toepassing op zowel front-en back-endverkeer. In de front-end fungeert Application Gateway als de server en wordt het beleid afgedwongen. Op de back-Application Gateway fungeert als de client en verzendt de protocol-/coderingsinformatie als voorkeursinformatie 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-versies te selecteren tijdens de handshake.

Application Gateway communiceert alleen met de back-eindservers waarvoor de lijst met hun certificaat is toegestaan met de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-instanties en de CN van het certificaat overeenkomt met de hostnaam in de HTTP-back-endinstellingen. Dit zijn onder andere 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-end-exemplaren. Hiermee wordt de end-to-end-communicatie verder beveiligd.

Notitie

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

end-to-end TLS-scenario

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

End-to-end-TLS en toestaan dat certificaten worden vermeld

Application Gateway communiceert alleen met bekende back-end-exemplaren die een lijst met hun certificaat met de toepassingsgateway hebben toegestaan. 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 Application Gateway aanvragen naar deze servers wilt door sturen, 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-upservercertificaat en niet het basiscertificaat) dat moet worden geüpload naar de HTTP-instellingen.

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

Notitie

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

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 HTTP-back-endinstellingen, vereisen geen extra stap om end-to-end TLS te laten werken.

    Als de back-endcertificaten bijvoorbeeld worden uitgegeven door een bekende CERTIFICERINGsinstelling en een CN van contoso.com hebben, 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-en-back-to-site instellen op HTTPS en zowel de statustest als het gegevenspad zijn ingeschakeld. Als u Azure App Service of andere Azure-webservices als uw 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 bekende certificeringsinstantie. Als het certificaat niet is uitgegeven door een vertrouwde CERTIFICERINGsinstantie, controleert de toepassingsgateway vervolgens of het certificaat van de verlenende CA is uitgegeven door een vertrouwde CERTIFICERINGsinstantie, etc. totdat een vertrouwde CA wordt gevonden (op dat moment wordt een vertrouwde, beveiligde verbinding tot stand gebracht) of er geen vertrouwde CA kan worden gevonden (op dat moment zal de toepassingsgateway de back-end beschadigd markeren). Daarom wordt aanbevolen dat het back-endservercertificaat zowel de basis- als tussenliggende CERTIFICERINGsinstellingen bevat.

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

  • Naast de overeenkomst met het basiscertificaat controleert Application Gateway v2 ook 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-ende server. Wanneer u probeert een TLS-verbinding met de back-Application Gateway v2 tot stand te brengen, stelt Application Gateway de extensie Servernaamindicatie (SNI) in op de host die is opgegeven in de http-instelling voor de back-ende back-ende.

  • Als u hostnaam kiest uit het back-enddoel in plaats van het veld Host 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 het TLS/SSL-certificaat van de back-ende server overeenkomen met de FQDN. Back-en-poolleden met IP's worden niet ondersteund in dit scenario.

  • 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 naar welke back-endserver de aanvraag moet worden doorgestuurd en wordt er een nieuwe TLS-sessie met de back-endserver tot stand brengen (laten we deze de back-endverbinding noemen).

De volgende tabellen geven een overzicht van de verschillen in SNI tussen de v1- en v2-SKU wat betreft front-en back-en back-en-verbinding.

Front-end-TLS-verbinding (client naar toepassingsgateway)

Scenario v1 v2
Als de client SNI-header op geeft en alle listeners voor meerdere site 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 regels voor doorsturen van aanvragen die zijn gekoppeld aan de HTTPS-listeners
Als de client geen SNI-header opgeeft en alle headers voor meerdere site zijn ingeschakeld met 'SNI vereisen' Hiermee stelt u de verbinding opnieuw in Retourneert het certificaat van de eerste HTTPS-listener volgens de volgorde die is opgegeven door de regels voor doorsturen van aanvragen 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 (standaardcertificaat 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 vanuit de back-endpool. Volgens RFC 6066zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in de SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet via DNS worden opgelost naar het IP-adres van de back-ende server (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 vanaf de hostnaam die wordt vermeld in de HTTP-instellingen, anders vanuit de FQDN die wordt vermeld in de back-endpool. De volgorde van prioriteit is een aangepaste test > HTTP-instellingen > back-endpool.
Opmerking: Als de hostnamen die zijn geconfigureerd in HTTP-instellingen en de aangepaste test verschillend zijn, wordt SNI volgens de prioriteit ingesteld als de hostnaam van de aangepaste test.
Als het adres van de back-adresgroep 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 standaard-/terugvalcertificaat kunnen retourneren. Dit moet worden toegestaan in HTTP-instellingen onder verificatiecertificaat. Als er geen standaard-/terugvalcertificaat is geconfigureerd op de back-en-back-server 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 een IP-adres als hostnaam hebben, wordt SNI niet ingesteld als volgens RFC 6066.
Opmerking: SNI wordt ook niet ingesteld in v2-tests als er geen aangepaste test is geconfigureerd en er geen hostnaam is ingesteld voor 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/ . Houd er rekening mee dat 127.0.0.1 die hier wordt vermeld, alleen wordt gebruikt als HTTP-hostheader en volgens RFC 6066 niet wordt gebruikt als SNI-header. Raadpleeg de gids voor probleemoplossing van de back-end-statusvoor meer informatie over statustestfouten.

Voor live verkeer

Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Stel in als FQDN vanuit de back-endpool. Volgens RFC 6066zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in de SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet via DNS worden opgelost naar het IP-adres van de back-ende server (openbaar of privé)		 SNI-header (server_name) wordt ingesteld als de hostnaam van de HTTP-instellingen. Als anders de optie PickHostnameFromBackendAddress is 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 of hostnaam is, wordt deze niet ingesteld in DE HTTP-instellingen SNI wordt niet ingesteld volgens RFC 6066 als de vermelding van de back-ende pool geen FQDN is SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-certificaat moet overeenkomen met deze hostnaam.
Hostnaam is niet opgegeven in http-Instellingen, maar een FQDN is opgegeven als het doel voor een lid van de back-endpool SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-certificaat moet overeenkomen met deze hostnaam. SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-certificaat 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 end-to-end TLS.