Terminação TLS ou Pass-Through? Escolhendo o Limite de Proxy Reverso Webship Certo

Escolher entre terminação TLS e passagem TLS não é uma configuração de proxy cosmética. Isso decide onde a criptografia termina, qual sistema mantém as chaves de sessão, se Webship pode inspecionar o HTTP e qual camada deve aplicar a segurança da aplicação.

Webship padrão é pass-through. Isso mantém o texto simples do aplicativo e as chaves de sessão ativas na origem. Habilite a terminação apenas quando a borda precisar entender e agir sobre a requisição HTTP.

A decisão em uma frase

Use TLS pass-through quando a origem precisar possuir a fronteira TLS. Use TLS termination quando Webship precisar rotear, proteger, transformar, armazenar em cache ou observar o tráfego HTTP.

Nenhum modo é universalmente mais seguro. O modo de passagem reduz o material sensível manipulado pela borda, mas remove os controles de segurança HTTP da borda. A terminação adiciona um ponto de aplicação inspecionável, mas torna Webship parte da fronteira confiável do TLS.

| Preocupação | Término TLS | Encaminhamento TLS | | --- | --- | --- | | Ponto de extremidade TLS | Webship | Origem | | Texto simples do aplicativo em Webship | Sim | Não | | Chaves de sessão ativas a jusante em Webship | Sim | Não | | Rota por caminho ou método HTTP | Sim | Não | | WAF, API Shield e limites de corpo em Webship | Sim | Não | | Cache de proxy, reescritas e encaminhamento de cabeçalhos | Sim | Não | | Entrada de roteamento TCP | Autoridade HTTP e política de rota | ClientHello SNI | | HTTP/3 roteamento | Dados de requisição HTTP | Uma origem UDP compartilhada | | Responsabilidade de origem | TLS HTTP ou TLS upstream configurado separadamente | TLS completo, ALPN e pilha HTTP |

A questão importante, portanto, não é “Qual interruptor é mais rápido?” É “Qual componente deve ser permitido ver e controlar a solicitação?”

Qual término dá Webship

Com tls_termination = true, Webship conclui o TLS a montante e envia a requisição descriptografada para o seu pipeline de proxy reverso HTTP. Isso torna os seguintes recursos possíveis:

• roteamento consciente de caminho, host e método;
• Inspeção de WAF e API Shield;
• limites do corpo da solicitação e tempo limite de política;
• cache de proxy e invalidação segura para geração;
• gerenciamento de cabeçalho de encaminhamento e campos de registro de acesso HTTP;
• manuseio de CONSULTA consciente do corpo, tentativas novamente quando seguro e política de disjuntor;
• tradução de protocolo entre as conexões voltadas para o cliente e as conexões ascendentes.

Este modo também altera a responsabilidade de segurança. O host Webship deve proteger a chave privada do certificado, as chaves de sessão, os dados de requisição e resposta descriptografados, a saída de observabilidade e qualquer representação em cache. Se o próximo salto precisar permanecer criptografado, configure o TLS a montante tipado separadamente; caso contrário, o upstream HTTP é em texto claro.

A terminação é o limite correto quando Webship deve se comportar como uma borda ciente de aplicativos, e não apenas como um retransmissor de transporte criptografado.

O que o repasse preserva

Com tls_termination = false—o padrão—Webship retransmite tráfego TLS ou QUIC criptografado sem descriptografar a solicitação ou resposta HTTP. O texto simples do aplicativo e as chaves de sessão ativas permanecem na origem.

Essa fronteira de confiança menor é valiosa quando os certificados devem permanecer na camada de aplicação, a política de conformidade proíbe a descriptografia na borda ou uma identidade TLS específica da origem precisa chegar ao cliente inalterada. Também remove a análise de HTTP e o trabalho de política do caminho de retransmissão.

O compromisso é rigoroso: Webship não pode inspecionar o que não pode descriptografar. Não pode aplicar regras de WAF HTTP, rotear por caminho, reescrever cabeçalhos, impor política de API consciente do corpo, ou preencher logs de acesso de campos HTTP. A origem deve fornecer todos esses controles por si mesma.

Porta de passagem, portanto, não é "rescisão com menos recursos." É uma arquitetura diferente com um proprietário de segurança diferente.

Os limites específicos do protocolo importam

Para HTTP/1.1 TLS e HTTP/2 TLS, Webship inspeciona o ClientHello apenas o suficiente para selecionar o destino TCP configurado pelo SNI. Cada domínio de passagem precisa de uma rota path_prefix = "/" genérica porque o caminho real da solicitação permanece criptografado. Um cliente sem SNI é aceito apenas quando a configuração possui um domínio.

A origem deve negociar o ALPN do cliente e suportar o protocolo selecionado. Webship não pode converter um cliente HTTP/2 em uma origem HTTP/1.1 enquanto a sessão TLS passa sem alterações.

HTTP/3 usa QUIC sobre UDP e possui uma fronteira mais restrita. O encaminhamento direto não pode rotear com segurança pelo HTTP criptografado, então cada rota HTTP/3 configurada deve resolver para o mesmo IP-socket de origem UDP. Webship rejeita sockets Unix e múltiplas origens HTTP/3 de encaminhamento direto durante a validação da configuração, em vez de rotear silenciosamente de forma ambígua.

Cleartext HTTP/1.1 e h2c não são afetados por reverse_proxy.tls_termination. A configuração controla apenas HTTP/1.1 TLS, HTTP/2 TLS e HTTP/3 TLS a jusante.

Capacidade de solicitação medida

O Webship 1.3.1 benchmark de capacidade do Debian mediu os dois modos de proxy reverso criptografados separadamente. Cada amostra aceita exigiu zero erros de HTTP, socket, protocolo, proxy, falha de página principal e HTTP/3 perda de pacotes.

| Modo reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminação TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | TLS pass-through | 203.950 RPS | 266.845 RPS | 167.010 RPS |

O encaminhamento de resposta pequena exige menos trabalho do aplicativo: ele retransmite dados de transporte criptografados em vez de encerrar o TLS, analisar HTTP, avaliar políticas e produzir um novo fluxo TLS downstream. As taxas mais altas de solicitações de encaminhamento refletem esse trabalho mais restrito.

Essas linhas não representam conjuntos de recursos idênticos e não devem ser usadas para afirmar que uma arquitetura de segurança é universalmente melhor. A terminação paga por capacidades conscientes de HTTP que a passagem direta intencionalmente não pode fornecer.

A transmissão em massa altera o resultado

O mesmo benchmark usou um corpo de resposta exato de 99.943.778 bytes para a matriz de streaming de 100 MB. Aqui, a terminação TLS produziu maior taxa média de transferência de payload para os três protocolos:

| Modo reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Término TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Passagem de TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Por que a direção muda? No modo de terminação, a origem do benchmark envia HTTP em texto claro para Webship, e Webship é responsável pelo caminho de bulk otimizado a jusante. Grandes respostas HTTP/1.1 e HTTP/2 podem usar kTLS adaptativo do Linux e buffering limitado específico de transporte. HTTP/3 usa controle de ritmo QUIC, DPLPMTUD e batching por reator em vez de kTLS.

No modo pass-through, a origem possui o TLS a jusante e Webship retransmite o fluxo criptografado resultante ou os pacotes QUIC. Isso preserva a fronteira TLS da origem, mas não pode usar o caminho de resposta em massa ciente de HTTP do Webship.

A qualificação de sete amostras HTTP/3 também verificou a estabilidade. A transmissão interrompida atingiu uma mediana de 1.938,6 MiB/s com 2,12% de coeficiente de variação; o modo pass-through atingiu 1.748,5 MiB/s com 1,65% de coeficiente de variação. Ambos entregaram o corpo exato sem erros de cliente, protocolo ou perda de pacotes.

Configure a passagem direta deliberadamente

Uma configuração mínima de passagem mantém a identidade TLS em estágio para que um operador possa habilitar a terminação posteriormente sem alterar os caminhos do certificado:

[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

O certificado Webship em estágio é validado, mas não é usado por sessões ativas de passagem direta. A origem em 10.0.0.20:443 deve encerrar o TLS e suportar o protocolo negociado pelo cliente.

Ativar terminação quando a borda precisar de HTTP

Para uma borda com reconhecimento de aplicativos, ative a terminação e envie o tráfego HTTP resultante para a origem selecionada:

[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

Essa configuração pode rotear e inspecionar HTTP. Adicione TLS upstream quando a rede entre Webship e a origem não for previamente confiável ou isolada.

Mude de modo sem reiniciar Webship

Webship pode alterar tls_termination através de um recarregamento de arquivo de configuração ou da ferramenta webship.reverse_proxy.apply_config MCP verificada por versão. Leia o objeto e a versão atuais com webship.reverse_proxy.get_config, altere apenas o campo pretendido no objeto completo retornado e envie-o com o expected_version_id correspondente.

Novas conexões TCP usam o novo modo. Clientes HTTP/3 reconectam ao transporte UDP substituído. Alterações no caminho de certificados e chaves continuam vinculadas ao processo e exigem uma reinicialização, portanto, mantenha uma identidade de terminação válida preparada antes de uma troca ao vivo.

A verificação de versão impede que um operador sobrescreva uma alteração de configuração concorrente. Uma atualização rejeitada mantém a configuração ativa em tempo de execução e a configuração persistida inalteradas.

Uma lista de verificação de seleção prática

Escolha passagem direta quando todos estes forem verdadeiros:

1. A origem deve manter o limite do certificado e as chaves de sessão.
2. O roteamento TCP em nível SNI—ou uma origem UDP HTTP/3 compartilhada—é suficiente.
3. A origem fornece o WAF necessário, autorização, registro, limites de corpo e controles de abuso.
4. Nenhum cache de borda, reescrita de caminho, política de cabeçalho de encaminhamento ou tradução de protocolo HTTP é necessário.

Escolha a rescisão quando qualquer um destes for necessário em Webship:

1. Roteie por host, caminho ou método.
2. Inspecione solicitações com WAF ou API Shield.
3. Impor limites de corpo, tempos limite HTTP ou autenticação de borda.
4. Armazenar em cache respostas ou reescrever cabeçalhos HTTP.
5. Traduzir entre os protocolos HTTP de downstream e upstream.
6. Observe os campos HTTP na fronteira do proxy.

Qualquer modo que você selecionar, teste SNI, ALPN, identidade do certificado, cancelamento pelo cliente, meia-fechadura a montante e integridade exata da resposta. Meça a capacidade de solicitação e a taxa de transferência de streaming separadamente: o modo mais rápido para uma resposta pequena não é necessariamente o modo mais rápido para um corpo de 100 MB.

Webship torna o pass-through o padrão porque um proxy não deve ampliar silenciosamente seu limite de confiança. A terminação continua sendo uma escolha operacional explícita e ativa quando o comportamento de borda consciente de HTTP vale essa responsabilidade.

Leia a [documentação do reverse-proxy](/docs/1.3.1) completa, compare a [matriz de benchmark](/benchmarks) aceita ou baixe Webship em [Downloads](/downloads).

Fontes e método de conteúdo

Os valores de desempenho são medianas aceitas do benchmark unificado de capacidade Debian 1.3.1 Webship datado de 11 de setembro de 2026; seus portões de aceitação exigem zero erros de cliente, HTTP, socket, protocolo, proxy, falha de página principal e perda de pacotes HTTP/3.