Terminazione TLS o Pass-Through? Scegliere il giusto confine del reverse proxy Webship

Scegliere tra la terminazione TLS e il pass-through TLS non è un'impostazione cosmetica del proxy. Decide dove termina la crittografia, quale sistema detiene le chiavi di sessione, se Webship può ispezionare l'HTTP e quale livello deve applicare la sicurezza delle applicazioni.

Webship per impostazione predefinita passa attraverso. Questo mantiene il testo in chiaro dell'applicazione e le chiavi di sessione attive all'origine. Abilitare la terminazione solo quando il edge deve comprendere e agire sulla richiesta HTTP.

La decisione in una frase

Usa TLS pass-through quando l'origine deve possedere il confine TLS. Usa TLS termination quando Webship deve instradare, proteggere, trasformare, memorizzare nella cache o osservare il traffico HTTP.

Nessuna modalità è universalmente più sicura. Il pass-through riduce il materiale sensibile gestito dal bordo, ma rimuove i controlli di sicurezza HTTP del bordo. La terminazione aggiunge un punto di applicazione ispezionabile, ma rende Webship parte del confine TLS affidabile.

| Preoccupazione | Terminazione TLS | Passaggio TLS | | --- | --- | --- | | Endpoint TLS | Webship | Origine | | Testo semplice dell'applicazione su Webship | Sì | No | | Chiavi di sessione downstream attive a Webship | Sì | No | | Instradamento per percorso HTTP o metodo | Sì | No | | WAF, API Shield e limiti del corpo a Webship | Sì | No | | Cache proxy, riscritture e intestazioni di inoltro | Sì | No | | Input di routing TCP | Autorità HTTP e politica di routing | ClientHello SNI | | HTTP/3 instradamento | Dati della richiesta HTTP | Un'origine UDP condivisa | | Responsabilità dell'origine | TLS upstream configurato tramite HTTP o separatamente | Stack completo TLS, ALPN e HTTP |

La domanda importante quindi non è «Quale interruttore è più veloce?» È «Quale componente deve poter vedere e controllare la richiesta?»

Quale terminazione dà Webship

Con tls_termination = true, Webship completa il TLS a valle e invia la richiesta decrittata nella sua pipeline di reverse-proxy HTTP. Ciò rende possibili le seguenti funzionalità:

• routing consapevole di percorso, host e metodo;
• Ispezione WAF e API Shield;
• limiti del corpo della richiesta e timeout della politica;
• caching del proxy e invalidazione sicura per la generazione;
• gestione dell'intestazione di inoltro e campi del registro degli accessi HTTP;
• gestione delle QUERY consapevole del corpo, tentativi di ripetizione dove sicuro e politica del breaker del circuito;
• traduzione del protocollo tra le connessioni lato client e a monte.

Questa modalità cambia anche la responsabilità della sicurezza. L'host Webship deve proteggere la chiave privata del certificato, le chiavi di sessione, i dati delle richieste e delle risposte decifrati, l'output di osservabilità e qualsiasi rappresentazione memorizzata nella cache. Se il prossimo hop deve rimanere criptato, configurare separatamente il TLS upstream tipizzato; altrimenti l'upstream HTTP è in chiaro.

La terminazione è il confine destro quando Webship è previsto che si comporti come un edge consapevole delle applicazioni, non solo come un relè di trasporto crittografato.

Cosa preserva il pass-through

Con tls_termination = false—l'impostazione predefinita—Webship trasmette traffico TLS o QUIC criptato senza decrittare la richiesta o la risposta HTTP. Il testo in chiaro dell'applicazione e le chiavi di sessione attive rimangono all'origine.

Quel confine di fiducia più piccolo è prezioso quando i certificati devono rimanere sul livello dell'applicazione, le norme di conformità vietano la decrittazione al confine o un'identità TLS specifica dell'origine deve raggiungere il client invariata. Inoltre, elimina l'analisi HTTP e il lavoro sulle policy dal percorso del relay.

Il compromesso è rigoroso: Webship non può ispezionare ciò che non può decrittografare. Non può applicare regole WAF HTTP, instradare per percorso, riscrivere intestazioni, far rispettare policy API consapevoli del corpo, o compilare i log di accesso ai campi HTTP. L'origine deve fornire tutti questi controlli da sola.

Il pass-through quindi non è una “terminazione con meno funzionalità.” È un'architettura diversa con un proprietario della sicurezza diverso.

I limiti specifici del protocollo sono importanti

Per HTTP/1.1 TLS e HTTP/2 TLS, Webship esamina il ClientHello solo quanto basta per selezionare la destinazione TCP configurata tramite SNI. Ogni dominio pass-through necessita di una rotta path_prefix = "/" a tutto tondo perché il percorso reale della richiesta rimane criptato. Un client senza SNI è accettato solo quando la configurazione ha un solo dominio.

L'origine deve negoziare l'ALPN del client e supportare il protocollo selezionato. Webship non può convertire un client HTTP/2 in un'origine HTTP/1.1 mentre la sessione TLS passa invariata.

HTTP/3 utilizza QUIC su UDP e ha un confine più ristretto. Il pass-through non può instradare in modo sicuro per autorità HTTP criptata, quindi ogni percorso HTTP/3 configurato deve risolversi nello stesso origine UDP del socket IP. Webship rifiuta i socket Unix e molteplici origini HTTP/3 durante la convalida della configurazione piuttosto che instradare silenziosamente in modo ambiguo.

Il testo chiaro HTTP/1.1 e h2c non sono influenzati da reverse_proxy.tls_termination. L'impostazione controlla solo TLS HTTP/1.1 a valle, TLS HTTP/2 e TLS HTTP/3.

Capacità di richiesta misurata

Il benchmark di capacità Debian Webship 1.3.1 ha misurato separatamente i due modi di reverse-proxy crittografati. Ogni campione accettato richiedeva zero errori HTTP, socket, protocollo, proxy, page-fault principali e perdita di pacchetti HTTP/3.

| Modalità reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminazione TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | Passaggio TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Il passaggio a piccola risposta richiede meno lavoro all'applicazione: trasmette dati di trasporto criptati invece di terminare TLS, analizzare HTTP, valutare le policy e generare un nuovo flusso TLS a valle. I tassi di richiesta più elevati nel passaggio riflettono quel compito più ridotto.

Queste righe non rappresentano set di funzionalità identici e non dovrebbero essere utilizzate per affermare che un'architettura di sicurezza sia universalmente migliore. La terminazione paga per le capacità consapevoli di HTTP che il pass-through intenzionalmente non può fornire.

Lo streaming in blocco cambia il risultato

Lo stesso benchmark ha utilizzato un corpo della risposta esatto di 99.943.778 byte per la matrice di streaming da 100 MB. Qui, la terminazione TLS ha prodotto un throughput medio del payload più alto per tutti e tre i protocolli:

| Modalità reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminazione TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Passaggio TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Perché cambia la direzione? In modalità di terminazione, l'origine del benchmark invia HTTP in chiaro a Webship, e Webship possiede il percorso a bassa latenza ottimizzato a valle. Risposte grandi di HTTP/1.1 e HTTP/2 possono utilizzare kTLS adattivo di Linux e buffering limitato specifico per il trasporto. HTTP/3 utilizza pacing QUIC, DPLPMTUD e batching per reattore invece di kTLS.

In modalità pass-through, l'origine possiede il TLS a valle e Webship inoltra il flusso crittografato risultante o i pacchetti QUIC. Ciò preserva il confine TLS dell'origine, ma non può utilizzare il percorso di risposta bulk consapevole di HTTP di Webship.

La qualificazione a sette campioni HTTP/3 ha anche verificato la stabilità. Lo streaming terminato ha raggiunto una mediana di 1.938,6 MiB/s con un coefficiente di variazione del 2,12%; il pass-through ha raggiunto 1.748,5 MiB/s con un coefficiente di variazione dell'1,65%. Entrambi hanno fornito il corpo esatto senza errori di client, protocollo o perdita di pacchetti.

Configura il pass-through intenzionalmente

Una configurazione di passaggio minimo mantiene l'identità TLS pronta in modo che un operatore possa abilitare la terminazione successivamente senza cambiare i percorsi dei certificati:

[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

Il certificato Webship in fase di allestimento è convalidato ma non è utilizzato dalle sessioni di pass-through attive. L'origine a 10.0.0.20:443 deve terminare TLS e supportare il protocollo negoziato dal client.

Abilita la terminazione quando il edge necessita di HTTP

Per un edge consapevole dell'applicazione, abilita la terminazione e invia il traffico HTTP risultante all'origine selezionata:

[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

Questa configurazione può instradare e ispezionare HTTP. Aggiungi TLS upstream quando la rete tra Webship e l'origine non è già fidata o isolata.

Passa modalità senza riavviare Webship

Webship può modificare tls_termination tramite un ricaricamento del file di configurazione o lo strumento webship.reverse_proxy.apply_config MCP controllato per versione. Leggi l'oggetto corrente e la versione con webship.reverse_proxy.get_config, modifica solo il campo previsto nell'oggetto completo restituito e invialo con il corrispondente expected_version_id.

Le nuove connessioni TCP utilizzano la nuova modalità. I client HTTP/3 si riconnettono al trasporto UDP sostituito. Le modifiche ai percorsi di certificato e chiave rimangono vincolate al processo e richiedono un riavvio, quindi tieni pronta un'identità di terminazione valida prima di un passaggio live.

Il controllo della versione impedisce a un operatore di sovrascrivere una modifica della configurazione concorrente. Un aggiornamento rifiutato lascia invariata la configurazione attiva in esecuzione e quella salvata.

Una checklist di selezione pratica

Scegli il pass-through quando tutte queste condizioni sono vere:

1. L'origine deve mantenere il confine del certificato e le chiavi di sessione.
2. Il routing TCP a livello SNI—o un'origine UDP HTTP/3 condivisa—è sufficiente.
3. L'origine fornisce il WAF necessario, l'autorizzazione, la registrazione, i limiti del corpo e i controlli degli abusi.
4. Non sono richiesti cache ai bordi, riscrittura del percorso, politica degli header di inoltro o traduzione del protocollo HTTP.

Scegli la cessazione quando è richiesta una qualsiasi di queste opzioni su Webship:

1. Instrada per host, percorso o metodo.
2. Ispeziona le richieste con WAF o API Shield.
3. Applicare limiti del corpo, timeout HTTP o autenticazione ai margini.
4. Memorizza nella cache le risposte o riscrivi le intestazioni HTTP.
5. Tradurre tra i protocolli HTTP downstream e upstream.
6. Osservare i campi HTTP al confine del proxy.

Qualunque modalità scegliate, testate SNI, ALPN, l'identità del certificato, l'annullamento da parte del client, la chiusura parziale a monte e l'integrità esatta della risposta. Misurate separatamente la capacità di richiesta e il throughput dello streaming: la modalità più veloce per una piccola risposta non è necessariamente la modalità più veloce per un corpo di 100 MB.

Webship rende il pass-through l'impostazione predefinita perché un proxy non dovrebbe ampliare silenziosamente il proprio confine di fiducia. La terminazione rimane una scelta operativa viva ed esplicita quando il comportamento edge consapevole di HTTP vale quella responsabilità.

Leggi la documentazione completa sul [reverse-proxy](/docs/1.3.1), confronta la [matrice di benchmark](/benchmarks) accettata, o scarica Webship da [Download](/downloads).

Fonti e metodo dei contenuti

I valori di prestazione sono mediane accettate dal benchmark unificato della capacità Debian Webship 1.3.1 datato 11 settembre 2026; i suoi criteri di accettazione richiedono zero errori lato client, HTTP, socket, protocollo, proxy, major-page-fault e perdita di pacchetti HTTP/3.