TLS-terminatie of doorgifte? Het kiezen van de juiste Webship reverse-proxygrens

Kiezen tussen TLS-terminatie en TLS-pass-through is geen cosmetische proxy-instelling. Het bepaalt waar de encryptie eindigt, welk systeem sessiesleutels bewaart, ofWebship kan HTTP inspecteren, en welke laag de applicatiebeveiliging moet afdwingen.

Webship standaard ingesteld op pass-through. Dat houdt de applicatie-plaintest en actieve sessiesleutels bij de oorsprong. Schakel terminatie alleen in wanneer de edge de HTTP-aanvraag moet begrijpen en erop moet reageren.

De beslissing in één zin

Gebruik TLS pass-through wanneer de oorspronkelijke server de TLS-grens moet bezitten. Gebruik TLS-terminatie wanneerWebship moet HTTP-verkeer routeren, beschermen, transformeren, cachen of observeren.

Geen van beide modi is universeel veiliger. Pass-through vermindert het gevoelige materiaal dat door de edge wordt verwerkt, maar verwijdert de HTTP-beveiligingscontroles van de edge. Termination voegt een controleerbaar handhavingspunt toe, maar maaktWebship onderdeel van de vertrouwde TLS-grens.

| Zorg | TLS-terminatie | TLS-doorsturen | | --- | --- | --- | | TLS-eindpunt | Webship | Oorsprong | | Toepassing platte tekst bij Webship | Ja | Nee | | Actieve downstream-sessiesleutels op Webship | Ja | Nee | | Route via HTTP-pad of methode | Ja | Nee | | WAF, API Shield en limieten voor de body bij Webship | Ja | Nee | | Proxycache, herschrijvingen en doorgestuurde headers | Ja | Nee | | TCP-routering invoer | HTTP-machtiging en routebeleid | ClientHello SNI | | HTTP/3 routering | HTTP-verzoekgegevens | Eén gedeelde UDP-bron | | Oorsprong verantwoordelijkheid | HTTP of apart geconfigureerde upstream TLS | Volledige TLS, ALPN en HTTP-stack |

De belangrijke vraag is daarom niet 'Welke schakelaar is sneller?' Het is 'Welk onderdeel moet worden toegestaan om het verzoek te zien en te controleren?'

Welke beëindiging geeftWebship

Met tls_termination = true, Webship voltooit downstream TLS en voert het gedecodeerde verzoek in zijn HTTP-reverse-proxy-pijplijn. Dat maakt de volgende functies mogelijk:

• pad-, host- en methodebewuste routering;
• WAF- en API Shield-inspectie;
• limieten voor request-body en beleidstime-outs;
• proxy-caching en generatie-veilige ongeldigmaking;
• beheer van doorstuurkopteksten en velden van HTTP-toegangslogboeken;
• lichaamsbewuste QUERY-afhandeling, opnieuw proberen waar veilig, en circuit-breakerbeleid;
• protocolvertaling tussen de klantgerichte en upstream verbindingen.

Deze modus verandert ook de beveiligingsverantwoordelijkheid. De Webship de host moet de privésleutel van het certificaat, sessiesleutels, gedecodeerde verzoek- en antwoordgegevens, output van observability en eventuele gecachte representatie beschermen. Als de volgende hop versleuteld moet blijven, configureer dan afzonderlijk getypeerde upstream TLS; anders is de HTTP-upstream in platte tekst.

Beëindiging is de rechtergrens wanneerWebship wordt verwacht zich te gedragen als een applicatie-bewuste edge, niet alleen als een versleutelde transportrelais.

Wat pass-through behoudt

Met tls_termination = false—standaard—Webship verzendt versleuteld TLS- of QUIC-verkeer door zonder het HTTP-verzoek of -antwoord te ontsleutelen. Toepassingsplaintext en actieve sessiesleutels blijven bij de oorsprong.

Die kleinere vertrouwensgrens is waardevol wanneer certificaten op de applicatielaag moeten blijven, het nalevingsbeleid randdecodering verbiedt of een oorsprong-specifieke TLS-identiteit ongewijzigd de client moet bereiken. Het verwijdert ook HTTP-parsing en beleidswerk van het relaispad.

De afweging is strikt: Webship kan niet inspecteren wat het niet kan ontcijferen. Het kan geen HTTP WAF-regels toepassen, routeren op basis van pad, headers herschrijven, body-bewuste API-beleid afdwingen of HTTP-veld toegangslogboeken invullen. De oorsprong moet al die controles zelf bieden.

Pass-through is daarom geen “terminatie met minder functies.” Het is een andere architectuur met een andere beveiligingseigenaar.

Protocolspecifieke limieten zijn belangrijk

Voor HTTP/1.1 TLS en HTTP/2 TLS, Webship inspecteert de ClientHello slechts zover om de geconfigureerde TCP-bestemming te selecteren via SNI. Elke pass-through domein heeft een vangnet nodigpath_prefix = "/" route omdat het werkelijke aanvraagpad versleuteld blijft. Een client zonder SNI wordt alleen geaccepteerd wanneer de configuratie één domein heeft.

De oorsprong moet het ALPN van de klant onderhandelen en het geselecteerde protocol ondersteunen.Webship kan geen omzettenHTTP/2 klant aan eenHTTP/1.1 oorsprong terwijl de TLS-sessie onveranderd doorgaat.

HTTP/3 gebruikt QUIC over UDP en heeft een strakkere grens. Pass-through kan niet veilig routeren op basis van versleutelde HTTP-authoriteit, dus elke geconfigureerdeHTTP/3 route moet naar dezelfde IP-socket UDP-bron resolven.Webship wijst Unix-sockets en meerdere afHTTP/3 doorstuurherkomst tijdens configuratievalidatie in plaats van vaag te routeren.

Platte tekstHTTP/1.1 en h2c worden niet beïnvloed doorreverse_proxy.tls_termination. De instelling regelt downstreamHTTP/1.1 TLS, HTTP/2 TLS, en HTTP/3 Alleen TLS.

Gemeten aanvraagcapaciteit

De Webship 1.3.1 Debian-capaciteitsbenchmark heeft de twee versleutelde reverse-proxy-modi afzonderlijk gemeten. Elke geaccepteerde steekproef vereiste nul HTTP-, socket-, protocol-, proxy-, major-page-fout en HTTP/3 pakketverliesfouten.

| Reverse-proxy modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-terminatie | 123.344 RPS | 124.957 RPS | 131.529 RPS | | TLS pass-through | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Kleine-respons pass-through heeft minder werk voor de applicatie uit te voeren: het verzendt versleutelde transportgegevens door in plaats van TLS te beëindigen, HTTP te parseren, beleid te evalueren en een nieuwe downstream TLS-stroom te produceren. De hogere pass-through verzoektarieven weerspiegelen dat beperktere werk.

Deze rijen vertegenwoordigen geen identieke functiesets, en ze mogen niet worden gebruikt om te beweren dat de ene beveiligingsarchitectuur universeel beter is. Beëindiging betaalt voor HTTP-bewuste mogelijkheden die pass-through opzettelijk niet kan bieden.

Bulkstreamen verandert het resultaat

Dezelfde benchmark gebruikte een exact 99.943.778-byte antwoordbody voor de 100 MB streamingmatrix. Hier produceerde TLS-terminatie een hogere mediane payloaddoorvoer voor alle drie de protocollen:

| Reverse-proxy modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-terminatie | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS-throughput | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Waarom verandert de richting? In de beëindigingsmodus stuurt de benchmarkbron onversleutelde HTTP naarWebship, en Webship bezit het geoptimaliseerde downstream bulkpad. Groot HTTP/1.1 en HTTP/2 reacties kunnen adaptieve Linux kTLS en gebonden transportspecifieke buffering gebruiken.HTTP/3 gebruikt QUIC-pacing, DPLPMTUD en per-reactor batching in plaats van kTLS.

In de pass-through modus bezit de oorsprong de downstream TLS enWebship zend de resulterende versleutelde stroom of QUIC-pakketten door. Dat behoudt de originele TLS-grens, maar het kan niet gebruikenWebship's HTTP-bewuste bulk-responspad.

Het zevenmonsterHTTP/3 kwalificatie controleerde ook de stabiliteit. Beëindigde streaming bereikte een mediaan van 1.938,6 MiB/s met 2,12% variatiecoëfficiënt; pass-through bereikte 1.748,5 MiB/s met 1,65% variatiecoëfficiënt. Beide leverden exact hetzelfde lichaam zonder fouten bij de client, het protocol en verlies van pakketten.

Configureer pass-through opzettelijk

Een minimale doorvoerconfiguratie houdt de TLS-identiteit klaargezet zodat een operator later terminatie kan inschakelen zonder de certificaatpaden te wijzigen:

[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

Het geënsceneerdeWebship certificaat is gevalideerd maar wordt niet gebruikt door actieve pass-through-sessies. De oorsprong bij 10.0.0.20:443 moet TLS beëindigen en het door de cliënt onderhandelde protocol ondersteunen.

Schakel beëindiging in wanneer de edge HTTP nodig heeft

Voor een applicatiebewuste edge, schakel beëindiging in en stuur het resulterende HTTP-verkeer naar de geselecteerde oorsprong:

[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

Deze configuratie kan HTTP routeren en inspecteren. Voeg upstream TLS toe wanneer het netwerk tussenWebship en de oorsprong wordt nog niet vertrouwd of is niet geïsoleerd.

Schakel modi zonder opnieuw op te startenWebship

Webship kan veranderentls_termination via een configuratiebestand herladen of de versie gecontroleerdwebship.reverse_proxy.apply_config MCP gereedschap. Lees het huidige object en de versie met webship.reverse_proxy.get_config, wijzig alleen het bedoelde veld in het volledig geretourneerde object en dien het in met het bijbehorende expected_version_id.

Nieuwe TCP-verbindingen gebruiken de nieuwe modus.HTTP/3 clients maken opnieuw verbinding met het vervangen UDP-transport. Wijzigingen in certificaat- en sleutelpad blijven procesgebonden en vereisen een herstart, dus houd een geldige beëindigingsidentiteit klaar voordat u live overschakelt.

Versiecontrole voorkomt dat een operator een gelijktijdige configuratiewijziging overschrijft. Een geweigerde update laat de actieve runtime en de opgeslagen configuratie ongewijzigd.

Een praktische selectiechecklist

Kies doorvoer wanneer aan al deze voorwaarden is voldaan:

1. De oorsprong moet de certificaatstgrens en sessiesleutels behouden.
2. SNI-niveau TCP-routering—of één gedeeldHTTP/3 UDP-bron—is voldoende.
3. De oorsprong biedt de noodzakelijke WAF, autorisatie, logging, lichaamlimieten en misbruikscontroles.
4. Geen edge-cache, pad-herschrijving, doorstuurheaderbeleid of HTTP-protocolvertaling is vereist.

Kies beëindiging wanneer een van deze vereist is bij Webship:

1. Routeren op host, pad of methode.
2. Controleer verzoeken met WAF of API Shield.
3. Handhaaf limieten voor de body, HTTP-time-outs of edge-authenticatie.
4. Cache-antwoorden of herschrijf HTTP-headers.
5. Vertaal tussen downstream- en upstream-HTTP-protocollen.
6. Observeer HTTP-velden bij de proxygrens.

Welke modus je ook selecteert, test SNI, ALPN, certificaatidentiteit, klantannulering, upstream half-sluiting en exacte responssintegriteit. Meet de verzoekcapaciteit en streamingdoorvoer afzonderlijk: de snelste modus voor een klein antwoord is niet noodzakelijk de snelste modus voor een 100 MB-bestand.

Webship maakt doorvoer de standaard omdat een proxy zijn vertrouwensgrens niet stilzwijgend moet verruimen. Terminatie blijft een actuele, expliciete operationele keuze wanneer HTTP-bewust randgedrag die verantwoordelijkheid waard is.

Lees de volledige [reverse-proxy documentatie](/docs/1.3.1), vergelijk de geaccepteerde [benchmarkmatrix](/benchmarks), of download Webship van [Downloads](/downloads).

Bronnen- en inhoudsmethode

Prestatiewaarden zijn geaccepteerde medianen van deWebship 1.3.1 uniforme Debian-capaciteitsbenchmark gedateerd 11 september 2026; de acceptatiepoorten vereisen nul client-, HTTP-, socket-, protocol-, proxy-, major-page-fault enHTTP/3 pakketverliesfouten.