Ukončení TLS nebo průchod? Volba správné hranice reverzního proxy Webship

Volba mezi ukončením TLS a přenosem TLS přes proxy není kosmetické nastavení proxy. Rozhoduje o tom, kde končí šifrování, který systém drží klíče relace, zda Webship může kontrolovat HTTP a která vrstva musí vynucovat bezpečnost aplikace.

Webship má výchozí nastavení na průchozí režim. To udržuje aplikaci v prostém textu a aktivní klíče relace na zdroji. Ukončení povolte pouze tehdy, když hrana musí HTTP požadavek porozumět a na něj reagovat.

Rozhodnutí jednou větou

Použijte TLS pass-through, když musí původce vlastnit hranici TLS. Použijte TLS termination, když Webship musí směrovat, chránit, transformovat, ukládat do mezipaměti nebo sledovat HTTP provoz.

Žádný režim není univerzálně bezpečnější. Režim průchodu snižuje množství citlivého materiálu zpracovávaného okrajem, ale odstraňuje bezpečnostní kontroly HTTP na okraji. Ukončení přidává bod vynucování, který lze kontrolovat, ale činí Webship součástí důvěryhodné hranice TLS.

| Obava | Ukončení TLS | Průchod TLS | | --- | --- | --- | | Koncový bod TLS | Webship | Původ | | Aplikační prostý text na Webship | Ano | Ne | | Aktivní klíče relace downstream na Webship | Ano | Ne | | Směrovat podle HTTP cesty nebo metody | Ano | Ne | | WAF, API Shield a limity těla na Webship | Ano | Ne | | Proxy cache, přepisování a přeposílání hlaviček | Ano | Ne | | Vstup TCP směrování | Oprávnění HTTP a směrnicová politika | ClientHello SNI | | HTTP/3 směrování | Data HTTP požadavku | Jeden sdílený zdroj UDP | | Odpovědnost původu | HTTP nebo samostatně nakonfigurovaný upstream TLS | Plný TLS, ALPN a HTTP stack |

Důležitá otázka tedy není „Který přepínač je rychlejší?“ Je to „Která součást musí mít možnost vidět a řídit požadavek?“

Jaké ukončení dává Webship

S tls_termination = true dokončuje Webship dolní tok TLS a předává dešifrovanou žádost do svého HTTP reverzního proxy pipeline. To umožňuje následující funkce:

• směrování s ohledem na cestu, hostitele a metodu;
• Kontrola WAF a ochrany API;
• limity těla požadavku a časové limity politiky;
• cacheování proxy a generaci-bezpečná neplatnost;
• správa hlaviček přeposílání a pole protokolů přístupu HTTP;
• řízení dotazů s ohledem na tělo, opakování tam, kde je bezpečné, a politika jističe;
• překlad protokolu mezi připojeními orientovanými na klienta a upstream připojeními.

Tento režim také mění odpovědnost za bezpečnost. Hostitel Webship musí chránit soukromý klíč certifikátu, klíče relace, dešifrovaná data požadavku a odpovědi, výstup pro sledovatelnost a jakoukoli uloženou reprezentaci. Pokud musí zůstat další uzel šifrovaný, nakonfigurujte typizovaný TLS upstream samostatně; jinak je HTTP upstream v prostém textu.

Ukončení je pravá hranice, když se očekává, že Webship bude fungovat jako okraj citlivý na aplikace, nikoli pouze jako šifrovaný přenosový relé.

Co průchod zachovává

S tls_termination = false—výchozí možností—Webship přenáší šifrovaný provoz TLS nebo QUIC, aniž by dešifroval HTTP požadavek nebo odpověď. Aplikace v prostém textu a aktivní klíče relace zůstávají na původním serveru.

Tato menší hranice důvěry je cenná, když certifikáty musí zůstat na aplikační vrstvě, zásady souladu zakazují dekódování na okraji nebo když identita TLS specifická pro původ musí dorazit ke klientovi beze změny. Odstraňuje také analýzu HTTP a práci s politikou z přenosové cesty.

Kompromis je přísný: Webship nemůže zkontrolovat to, co nemůže dešifrovat. Nemůže uplatňovat pravidla HTTP WAF, směrovat podle cesty, přepisovat hlavičky, vynucovat zásady API citlivé na obsah těla ani zaznamenávat přístupová logy HTTP polí. Původní server musí všechny tyto kontroly zajistit sám.

Přímé propojení tedy není „ukončení s méně funkcemi.“ Je to jiná architektura s jiným vlastníkem bezpečnosti.

Omezení specifická pro protokol jsou důležitá

Pro HTTP/1.1 TLS a HTTP/2 TLS kontroluje Webship zprávu ClientHello pouze natolik, aby vybral nakonfigurovaný TCP cíl podle SNI. Každá doména pro průchod vyžaduje záchytnou path_prefix = "/" trasu, protože skutečná cesta požadavku zůstává šifrovaná. Klient bez SNI je přijat pouze tehdy, když konfigurace obsahuje jednu doménu.

Původ musí vyjednat ALPN klienta a podporovat vybraný protokol. Webship nemůže převést klienta HTTP/2 na původ HTTP/1.1, zatímco TLS relace prochází beze změny.

HTTP/3 používá QUIC přes UDP a má přísnější hranici. Pass-through nemůže bezpečně směrovat podle šifrované HTTP autority, takže každá konfigurovaná HTTP/3 trasa musí směřovat na stejný IP-socket UDP původ. Webship odmítá Unix sockety a více HTTP/3 pass-through zdrojů během ověřování konfigurace namísto tichého nejasného směrování.

Prostý text HTTP/1.1 a h2c nejsou ovlivněny reverse_proxy.tls_termination. Toto nastavení řídí pouze downstream HTTP/1.1 TLS, HTTP/2 TLS a HTTP/3 TLS.

Měřená kapacita požadavků

Webship 1.3.1 benchmark kapacity Debian měřil dva šifrované módy reverzní proxy samostatně. Každý přijatý vzorek vyžadoval nulové chyby HTTP, soketů, protokolu, proxy, hlavního chybového zásahu stránky a HTTP/3 ztráty paketů.

| Režim reverzního proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Ukončení TLS | 123 344 RPS | 124 957 RPS | 131 529 RPS | | Přenos TLS | 203 950 RPS | 266 845 RPS | 167 010 RPS |

Přenos s malou odezvou vyžaduje méně práce od aplikace: přenáší šifrovaná transportní data místo toho, aby ukončoval TLS, analyzoval HTTP, vyhodnocoval politiku a vytvářel nový downstream TLS tok. Vyšší rychlosti požadavků při přenosu odrážejí tuto úžeji definovanou úlohu.

Tyto řádky nereprezentují identické sady funkcí a neměly by být používány k tvrzení, že jedna zabezpečovací architektura je univerzálně lepší. Ukončení platí za schopnosti znalé HTTP, které průchod záměrně nemůže poskytnout.

Hromadné streamování mění výsledek

Stejný benchmark použil přesně 99 943 778 bajtů velké tělo odpovědi pro 100 MB streamovací matici. Zde ukončení TLS vedlo k vyšší střední propustnosti dat pro všechny tři protokoly:

| Režim reverzního proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Ukončení TLS | 3 585,7 MiB/s | 3 355,0 MiB/s | 1 938,6 MiB/s | | TLS průchod | 2 783,2 MiB/s | 2 135,0 MiB/s | 1 748,5 MiB/s |

Proč se směr mění? V režimu terminace posílá původce benchmarku nešifrovaný HTTP do Webship a Webship vlastní optimalizovanou cestu downstream pro hromadné přenosy. Velké odpovědi HTTP/1.1 a HTTP/2 mohou využívat adaptivní Linux kTLS a omezené transportně-specifické vyrovnávací paměti. HTTP/3 používá pacing QUIC, DPLPMTUD a dávkování podle reaktoru místo kTLS.

V režimu přenosu vlastní původní server TLS směrem dolů a Webship přeposílá výsledný šifrovaný tok nebo pakety QUIC. To zachovává hranici TLS původního serveru, ale nelze použít HTTP-povinnou cestu pro hromadné odpovědi Webship.

Sedmisouborová kvalifikace HTTP/3 také kontrolovala stabilitu. Ukončené streamování dosáhlo mediánu 1 938,6 MiB/s s koeficientem variability 2,12 %; průchod dosáhl 1 748,5 MiB/s s koeficientem variability 1,65 %. Oba doručily přesně tělo bez chyb klienta, protokolu ani ztráty paketů.

Konfigurujte průchod záměrně

Minimální konfigurace průchodu ponechává identitu TLS připravenou, takže operátor může později povolit ukončení, aniž by měnil cesty k certifikátům:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Fiktivní certifikát Webship je ověřen, ale není používán aktivními přenosovými relacemi. Původ na 10.0.0.20:443 musí ukončit TLS a podporovat klientem vyjednaný protokol.

Povolit ukončení, když hrana vyžaduje HTTP

Pro aplikací orientovaný edge povolte ukončení a pošlete výsledný HTTP provoz na vybraný původ:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Tato konfigurace může směrovat a kontrolovat HTTP. Přidejte upstream TLS, pokud síť mezi Webship a originálem není již důvěryhodná nebo izolovaná.

Přepínat režimy bez restartu Webship

Webship může změnit tls_termination prostřednictvím obnovení konfiguračního souboru nebo verzi kontrolovaného nástroje webship.reverse_proxy.apply_config MCP. Přečtěte si aktuální objekt a verzi pomocí webship.reverse_proxy.get_config, změňte pouze určené pole v celém vráceném objektu a odešlete jej s odpovídajícím expected_version_id.

Nová připojení TCP používají nový režim. HTTP/3 klienti se znovu připojují k nahrazenému UDP transportu. Změny cesty k certifikátu a klíči zůstávají vázány na proces a vyžadují restart, takže před živým přepnutím mějte připravenou platnou identitu ukončení.

Kontrola verzí zabraňuje jednomu operátorovi přepsat současnou změnu konfigurace. Odmítnutá aktualizace nechává aktivní běhovou a uloženou konfiguraci nezměněnou.

Praktický kontrolní seznam pro výběr

Vyberte průchod, když platí všechno toto:

1. Původ musí zachovat hranici certifikátu a klíče relace.
2. SNI-úrovňové směrování TCP — nebo jeden sdílený HTTP/3 UDP origin — je dostatečné.
3. Zdroj poskytuje potřebný WAF, autorizaci, protokolování, limity těla a kontrolu zneužití.
4. Není potřeba žádné ukládání do mezipaměti na okraji, přepisování cesty, politika přeposílání hlaviček ani překlad HTTP protokolu.

Zvolte ukončení, když je některé z těchto požadavků vyžadováno na Webship:

1. Směrovat podle hostitele, cesty nebo metody.
2. Kontrolujte požadavky pomocí WAF nebo API Shield.
3. Prosazujte limity velikosti těla, časové limity HTTP nebo ověřování na okraji.
4. Ukládat odpovědi do mezipaměti nebo přepisovat hlavičky HTTP.
5. Překládejte mezi downstream a upstream HTTP protokoly.
6. Sledujte HTTP pole na hranici proxy.

Ať už vyberete kterýkoli režim, testujte SNI, ALPN, identitu certifikátu, zrušení klientem, částečné uzavření upstream a přesnou integritu odpovědi. Měřte kapacitu požadavků a propustnost streamování samostatně: nejrychlejší režim pro malou odpověď nemusí být nutně nejrychlejší režim pro tělo o velikosti 100 MB.

Webship nastavuje pass-through jako výchozí, protože proxy by neměla tiše rozšiřovat svou důvěryhodnou hranici. Ukončení zůstává živou, explicitní operační volbou, pokud je chování okraje s podporou HTTP hodné této odpovědnosti.

Přečtěte si kompletní [dokumentaci k reverznímu proxy](/docs/1.3.1), porovnejte přijatou [benchmarkovou matici](/benchmarks) nebo si stáhněte Webship z [Ke stažení](/downloads).

Zdroje a metoda obsahu

Výkonnostní hodnoty jsou přijaté mediány z Webship 1.3.1 sjednoceného Debian kapacitního benchmarku ze dne 11. září 2026; jeho přijímací brány vyžadují nulové chyby klienta, HTTP, socketu, protokolu, proxy, hlavní stránkové chyby a HTTP/3 ztráty paketů.