Přehled ukončení protokolu TLS a koncového šifrování TLS se službou Application Gateway

Protokol TLS (Transport Layer Security), dříve označovaný jako SSL (Secure Sockets Layer), je standardní technologie zabezpečení pro vytvoření šifrovaného propojení mezi webovým serverem a prohlížečem. Tento odkaz zajišťuje, že všechna data předaná mezi webovým serverem a prohlížeči zůstanou soukromá a šifrovaná. Application Gateway podporuje ukončení protokolu TLS na bráně i koncové šifrování TLS.

Ukončení šifrování TLS

Application Gateway podporuje ukončení protokolu TLS na bráně, po kterém provoz obvykle proudí nešifrovaný na back-endové servery. V aplikační bráně existuje řada výhod ukončení protokolu TLS:

• Vylepšený výkon – největší výkon při dešifrování protokolu TLS je počáteční metodou handshake. Aby se zlepšil výkon, server, který dešifruje, ukládá ID relací TLS do mezipaměti a spravuje lístky relací TLS. Pokud se to provádí ve službě Application Gateway, můžou všechny požadavky ze stejného klienta používat hodnoty uložené v mezipaměti. Pokud je to hotové na back-endových serverech, musí se klient pokaždé, když požadavky klienta přejdou na jiný server, znovu provést ověření. Použití lístků TLS může pomoct tento problém zmírnit, ale nejsou podporovány všemi klienty a můžou být obtížné nakonfigurovat a spravovat.
• Lepší využití back-endových serverů – zpracování SSL/TLS je velmi náročné na procesor a s rostoucí velikostí klíčů se stává náročnějším. Odebráním této práce z back-endových serverů se můžou soustředit na to, co jsou nejúčinnější a co nejefektivněji doručují obsah.
• Inteligentní směrování – Dešifrováním provozu má aplikační brána přístup k obsahu požadavku, jako jsou hlavičky, identifikátor URI atd., a může tato data použít ke směrování požadavků.
• Správa certifikátů – Certifikáty je potřeba zakoupit a nainstalovat jenom na aplikační bránu a ne všechny back-endové servery. To šetří čas i peníze.

Pokud chcete nakonfigurovat ukončení protokolu TLS, musí se do naslouchacího procesu přidat certifikát TLS/SSL. To umožňuje službě Application Gateway dešifrovat příchozí provoz a šifrovat provoz odpovědí klientovi. Certifikát poskytnutý službě Application Gateway musí být ve formátu PFX (Personal Information Exchange), který obsahuje privátní i veřejné klíče. Podporované algoritmy PFX jsou uvedeny ve funkci PFXImportCertStore.

Důležité

Certifikát naslouchacího procesu vyžaduje, aby se nahrál celý řetěz certifikátů (kořenový certifikát z certifikační autority, zprostředkující certifikát a listový certifikát), aby se vytvořil řetěz důvěryhodnosti.

Poznámka:

Application Gateway neposkytuje žádnou možnost vytvořit nový certifikát ani odeslat žádost o certifikát certifikační autoritě.

Aby připojení TLS fungovalo, musíte zajistit, aby certifikát TLS/SSL splňoval následující podmínky:

• Aktuální datum a čas jsou v rozsahu kalendářních dat "Platné od" a "Platné do" v certifikátu.
• Běžný název certifikátu (CN) odpovídá hlavičce hostitele v požadavku. Například pokud klient posílá požadavek na https://www.contoso.com/, musí být CN www.contoso.com.

Pokud máte chyby s běžným názvem back-endového certifikátu (CN), prohlédněte si našeho průvodce odstraňováním potíží.

Certifikáty podporované pro ukončení protokolu TLS

Application Gateway podporuje následující typy certifikátů:

• Certifikát certifikační autority (certifikační autorita): Certifikát certifikační autority je digitální certifikát vydaný certifikační autoritou (CA).
• Certifikát EV (Rozšířené ověřování): Certifikát EV je certifikát, který odpovídá standardním pokynům pro oborové certifikáty. Tím se změní panel lokátoru prohlížeče na zelenou a publikuje také název společnosti.
• Certifikát se zástupnými čísly: Tento certifikát podporuje libovolný počet subdomén na základě *.site.com, kde by vaše subdoména nahradila *. Nepodporuje ale site.com, takže v případě, že uživatelé přistupují k vašemu webu, aniž by museli zadávat úvodní "www", certifikát se zástupným znakem to nepokryje.
• Certifikáty podepsané svým držitelem: Klientské prohlížeče tyto certifikáty nedůvěřují a upozorní uživatele, že certifikát virtuální služby není součástí řetězu důvěryhodnosti. Certifikáty podepsané svým držitelem jsou vhodné pro testování nebo prostředí, kde správci řídí klienty a můžou bezpečně obejít výstrahy zabezpečení prohlížeče. Produkční úlohy by nikdy neměly používat certifikáty podepsané svým držitelem.

Další informace najdete v tématu Konfigurace ukončení protokolu TLS se službou Application Gateway.

Velikost certifikátu

V části Omezení služby Application Gateway zjistěte, jaká maximální podporovaná velikost certifikátu TLS/SSL je podporovaná.

Kompletní šifrování TLS

Možná nebudete chtít nešifrovanou komunikaci s back-end servery. Možná máte požadavky na zabezpečení, požadavky na dodržování předpisů nebo aplikace může přijímat pouze zabezpečené připojení. Aplikace Azure lication Gateway má kompletní šifrování TLS, které podporuje tyto požadavky.

Kompletní protokol TLS umožňuje šifrovat a bezpečně přenášet citlivá data do back-endu při používání funkcí vyrovnávání zatížení vrstvy 7 služby Application Gateway. Mezi tyto funkce patří spřažení relace založené na souborech cookie, směrování na základě adresy URL, podpora směrování na základě webů, možnost přepisovat nebo vkládat hlavičky X-Forwarded-* atd.

Když je služba Application Gateway nakonfigurovaná s kompletním komunikačním režimem TLS, ukončí relace PROTOKOLU TLS na bráně a dešifruje uživatelský provoz. Následně použije nakonfigurovaná pravidla k výběru příslušné instance back-endového fondu, na kterou provoz přesměruje. Služba Application Gateway pak zahájí nové připojení TLS k back-endovému serveru a před přenosem požadavku do back-endu znovu zašifruje data pomocí certifikátu veřejného klíče back-endového serveru. Každá odpověď webového serveru prochází ke koncovému uživateli stejným procesem. Koncový protokol TLS je povolený nastavením nastavení protokolu v nastavení HTTP back-endu na HTTPS, který se pak použije v back-endovém fondu.

V branách skladových položek služby Application Gateway v1 zásada protokolu TLS aplikuje verzi protokolu TLS pouze na front-endový provoz a definované šifry pro front-endové i back-endové cíle. V branách skladových položek služby Application Gateway v2 se zásady TLS vztahují pouze na front-endový provoz, připojení back-endu TLS se vždy vyjednávají přes protokol TLS 1.0 na verze TLS 1.2.

Application Gateway komunikuje jenom s těmi back-endovými servery, které mají buď seznam povolených certifikátů se službou Application Gateway, nebo s certifikáty podepsanými dobře známými certifikačními autoritami a cn certifikátu odpovídá názvu hostitele v nastavení back-endu HTTP. Patří mezi ně důvěryhodné služby Azure, jako je služba Aplikace Azure nebo Služba Web Apps a Azure API Management.

Pokud certifikáty členů v back-endovém fondu nejsou podepsané dobře známými certifikačními autoritami, musí být každá instance v back-endovém fondu s povoleným koncovým protokolem TLS nakonfigurovaná s certifikátem, který umožňuje zabezpečenou komunikaci. Přidáním certifikátu zajistíte, že aplikační brána komunikuje pouze se známými back-endovými instancemi. Tím se dále zabezpečuje kompletní komunikace.

Poznámka:

Certifikát přidaný do nastavení HTTP back-endu pro ověření back-endových serverů může být stejný jako certifikát přidaný do naslouchacího procesu pro ukončení protokolu TLS ve službě Application Gateway nebo jiný pro lepší zabezpečení.

V tomto příkladu se požadavky používající protokol TLS1.2 směrují na back-endové servery ve fondu1 pomocí koncového šifrování TLS.

Koncové šifrování TLS a povolení výpisu certifikátů

Application Gateway komunikuje jenom s těmi back-endovými servery, které mají buď seznam povolených certifikátů se službou Application Gateway, nebo s certifikáty podepsanými dobře známými certifikačními autoritami a cn certifikátu odpovídá názvu hostitele v nastavení back-endu HTTP. V procesu kompletního nastavení protokolu TLS s ohledem na používanou verzi služby Application Gateway existují určité rozdíly. Následující část vysvětluje jednotlivé verze.

Kompletní tls s skladovou jednotkou v1

Pokud chcete povolit kompletní tls s back-endovými servery a aby služba Application Gateway mohla směrovat požadavky na ně, musí sondy stavu proběhnout úspěšně a vrátit odpověď v pořádku.

Pro sondy stavu HTTPS používá skladová položka služby Application Gateway v1 přesnou shodu ověřovacího certifikátu (veřejný klíč certifikátu back-endového serveru, nikoli kořenový certifikát) k nahrání do nastavení HTTP.

Pak jsou povolená pouze připojení ke známým a povoleným back-endům. Zbývající back-endy se považují za poškozené sondami stavu. Certifikáty podepsané svým držitelem slouží pouze k testování a nedoporučují se pro úlohy v produkčním prostředí. Tyto certifikáty musí být povolené se službou Application Gateway, jak je popsáno v předchozích krocích, než je lze použít.

Poznámka:

Pro důvěryhodné služby Azure, jako je Aplikace Azure Service, se nevyžaduje ověřování a nastavení důvěryhodného kořenového certifikátu. Ve výchozím nastavení jsou považovány za důvěryhodné.

Kompletní TLS s skladovou jednotkou v2

Ověřovací certifikáty jsou zastaralé a nahrazeny důvěryhodnými kořenovými certifikáty ve skladové posadě Application Gateway v2. Fungují podobně jako ověřovací certifikáty s několika klíčovými rozdíly:

• Certifikáty podepsané známými certifikačními autoritou, jejichž CN odpovídá názvu hostitele v nastavení back-endu HTTP, nevyžadují pro ukončení protokolu TLS žádný další krok.

  Pokud jsou například back-endové certifikáty vystaveny dobře známou certifikační autoritou a má CN contoso.com a pole hostitele nastavení HTTP back-endu je také nastaveno na contoso.com, nejsou potřeba žádné další kroky. Můžete nastavit protokol http back-endu na HTTPS a sonda stavu i cesta k datům budou povolené protokoly TLS. Pokud jako back-end používáte službu Aplikace Azure Service nebo jiné webové služby Azure, jsou implicitně důvěryhodné a pro koncové tls se nevyžadují žádné další kroky.

Poznámka:

Aby byl certifikát TLS/SSL důvěryhodný, musí certifikát back-endového serveru vydat certifikační autorita, která je dobře známá. Pokud certifikát nevystavil důvěryhodná certifikační autorita, služba Application Gateway pak zkontroluje, jestli certifikát vydávající certifikační autority vydala důvěryhodná certifikační autorita, a tak dále, dokud se nenajde důvěryhodná certifikační autorita (v tomto okamžiku se naváže důvěryhodné zabezpečené připojení), nebo se nenajde žádná důvěryhodná certifikační autorita (v tomto okamžiku služba Application Gateway označí back-end, který není v pořádku). Proto se doporučuje certifikát back-endového serveru obsahovat kořenové i zprostředkující certifikační autority.

• Pokud je certifikát back-endového serveru podepsaný svým držitelem nebo podepsaný neznámou certifikační autoritou nebo zprostředkovateli, musí být nahraný důvěryhodný kořenový certifikát. Application Gateway bude komunikovat pouze s back-endy, jejichž kořenový certifikát serveru odpovídá jednomu ze seznamu důvěryhodných kořenových certifikátů v nastavení HTTP back-endu přidruženém k fondu.

• Kromě shody kořenového certifikátu služba Application Gateway v2 také ověří, jestli nastavení hostitele zadané v nastavení HTTP back-endu odpovídá společnému názvu (CN) certifikátu TLS/SSL back-endového serveru. Při pokusu o navázání připojení TLS k back-endu nastaví Application Gateway v2 rozšíření SNI (Server Name Indication) na hostitele zadaného v nastavení HTTP back-endu.

• Pokud je místo pole Hostitel v nastavení HTTP back-endu zvolen výběr názvu hostitele z back-endového cíle , záhlaví SNI se vždy nastaví na plně kvalifikovaný název domény back-endového fondu a cn na back-endovém serveru musí odpovídat plně kvalifikovanému názvu domény. V tomto scénáři se nepodporují členy back-endových fondů s IP adresami.

• Kořenový certifikát je kořenový certifikát s kódováním base64 z certifikátů back-endového serveru.

Rozdíly SNI v SKU v1 a v2

Jak už jsme zmínili dříve, Služba Application Gateway ukončuje provoz TLS z klienta v naslouchacím procesu služby Application Gateway (pojďme ho volat front-endové připojení), dešifruje provoz, použije potřebná pravidla k určení back-endového serveru, na který se má požadavek přesměrovat, a vytvoří novou relaci TLS s back-endovým serverem (pojďme ho volat back-endové připojení).

Následující tabulky popisují rozdíly v SNI mezi skladovou položku v1 a v2 z hlediska front-endových a back-endových připojení.

Připojení TLS front-endu (klient ke službě Application Gateway)

Scénář	v1	v2
Pokud klient určuje hlavičku SNI a všechny naslouchací procesy s více lokalitami jsou povolené příznakem Vyžadovat SNI.	Vrátí příslušný certifikát a pokud lokalita neexistuje (podle server_name), připojení se resetuje.	Vrátí odpovídající certifikát, pokud je k dispozici, v opačném případě vrátí certifikát prvního naslouchacího procesu HTTPS podle pořadí určeného pravidly směrování požadavků přidruženými k naslouchacím procesům HTTPS.
Pokud klient nezadá hlavičku SNI a pokud jsou všechna záhlaví s více lokalitami povolená pomocí "Vyžadovat SNI".	Obnoví připojení.	Vrátí certifikát prvního naslouchacího procesu HTTPS podle pořadí určeného pravidly směrování požadavků přidružených k naslouchacím procesům HTTPS.
Pokud klient nezadá hlavičku SNI a pokud je nakonfigurovaný základní naslouchací proces s certifikátem	Vrátí certifikát nakonfigurovaný v základním naslouchacím procesu klientovi (výchozí nebo záložní certifikát).	Vrátí certifikát nakonfigurovaný v základním naslouchacím procesu.

Poznámka:

Pokud klient nezadá hlavičku SNI, doporučuje se, aby uživatel přidal základní naslouchací proces a pravidlo pro prezentaci výchozího certifikátu SSL/TLS.

Tip

Příznak SNI je možné nakonfigurovat pomocí PowerShellu nebo pomocí šablony ARM. Další informace najdete v tématu RequireServerNameIndication a Rychlý start: Směrování webového provozu pomocí brány Aplikace Azure lication – šablona ARM.

Připojení tls back-endu (aplikační brána k back-endovému serveru)

Pro provoz sondy

Scénář	v1	v2
Hlavička SNI (server_name) během handshake protokolu TLS jako plně kvalifikovaný název domény	Nastavte jako plně kvalifikovaný název domény z back-endového fondu. Podle dokumentu RFC 6066 nejsou adresy IPv4 a IPv6 v názvu hostitele SNI povolené. Poznámka: Plně kvalifikovaný název domény v back-endovém fondu by se měl přeložit na IP adresu back-endového serveru (veřejnou nebo privátní).	Hlavička SNI (server_name) je nastavená jako název hostitele z vlastní sondy připojené k nastavení HTTP (pokud je nakonfigurované), jinak z názvu hostitele uvedeného v nastavení HTTP, jinak z plně kvalifikovaného názvu domény uvedeného v back-endovém fondu. Pořadí priorit je vlastní back-endový fond nastavení > HTTP sondy>. Poznámka: Pokud se názvy hostitelů nakonfigurované v nastavení HTTP a vlastní sondě liší, pak se podle priority nastaví SNI jako název hostitele z vlastní sondy.
Pokud je adresa back-endového fondu IP adresa (v1) nebo pokud je název hostitele vlastní sondy nakonfigurovaný jako IP adresa (v2).	SNI (server_name) se nenastaví. Poznámka: V tomto případě by back-endový server měl být schopný vrátit výchozí nebo záložní certifikát a měl by být uvedený v nastavení HTTP v rámci ověřovacího certifikátu. Pokud na back-endovém serveru není nakonfigurovaný žádný výchozí nebo záložní certifikát a očekává se SNI, server může připojení resetovat a dojít k selháním testu	Pokud mají DŘÍVE uvedenou IP adresu jako název hostitele, hlavní název služby (SNI) se v pořadí podle dokumentu RFC 6066 nenastaví. Poznámka: SNI se také nenastaví v sondách v2, pokud není nakonfigurovaná žádná vlastní sonda a v nastavení HTTP nebo back-endovém fondu není nastavený žádný název hostitele.

Poznámka:

Pokud není nakonfigurovaná vlastní sonda, služba Application Gateway odešle výchozí sondu v tomto formátu – <protokol>://127.0.0.1:<port>/. Například pro výchozí test HTTPS se odešle jako https://127.0.0.1:443/. Všimněte si, že zde uvedené 127.0.0.1 se používá pouze jako hlavička hostitele HTTP a podle dokumentu RFC 6066 se jako hlavička SNI nepoužije. Další informace o chybách sond stavu najdete v průvodci odstraňováním potíží se stavem back-endu.

Pro živý provoz

Scénář	v1	v2
Hlavička SNI (server_name) během handshake protokolu TLS jako plně kvalifikovaný název domény	Nastavte jako plně kvalifikovaný název domény z back-endového fondu. Podle dokumentu RFC 6066 nejsou adresy IPv4 a IPv6 v názvu hostitele SNI povolené. Poznámka: Plně kvalifikovaný název domény v back-endovém fondu by se měl přeložit na IP adresu back-endového serveru (veřejnou nebo privátní).	Hlavička SNI (server_name) je nastavená jako název hostitele z nastavení HTTP, jinak pokud je zvolena možnost PickHostnameFromBackendAddress nebo pokud není uvedený žádný název hostitele, pak se nastaví jako plně kvalifikovaný název domény v konfiguraci back-endového fondu.
Pokud adresa back-endového fondu je IP adresa nebo název hostitele není nastavený v nastavení HTTP.	SNI se nenastaví podle dokumentu RFC 6066, pokud položka back-endového fondu není plně kvalifikovaný název domény.	SNI se nastaví jako název hostitele ze vstupního plně kvalifikovaného názvu domény z klienta a cn back-endového certifikátu se musí s tímto názvem hostitele shodovat.
V nastavení HTTP není zadaný název hostitele, ale plně kvalifikovaný název domény je určený jako cíl pro člena back-endového fondu.	SNI se nastaví jako název hostitele ze vstupního plně kvalifikovaného názvu domény z klienta a cn back-endového certifikátu se musí s tímto názvem hostitele shodovat.	SNI se nastaví jako název hostitele ze vstupního plně kvalifikovaného názvu domény z klienta a cn back-endového certifikátu se musí s tímto názvem hostitele shodovat.

Další kroky

Jakmile se dozvíte o koncovém protokolu TLS, přejděte na Konfigurace koncového šifrování TLS pomocí služby Application Gateway s PowerShellem a vytvořte aplikační bránu pomocí koncového šifrování TLS.