Choisir entre la terminaison TLS et le passage TLS n'est pas un réglage de proxy cosmétique. Cela détermine où se termine le chiffrement, quel système détient les clés de session, si Webship peut inspecter le HTTP, et quelle couche doit appliquer la sécurité des applications.
Webship est par défaut en mode passage. Cela permet de garder le texte en clair de l'application et les clés de session actives à l'origine. Activez la terminaison seulement lorsque le point de terminaison doit comprendre et agir sur la requête HTTP.
La décision en une phrase
Utilisez le passage TLS lorsque l'origine doit posséder la frontière TLS. Utilisez la terminaison TLS lorsque Webship doit router, protéger, transformer, mettre en cache ou observer le trafic HTTP.
Aucun mode n'est universellement plus sûr. Le mode transit réduit le traitement du matériel sensible par le périphérique, mais supprime les contrôles de sécurité HTTP du périphérique. La terminaison ajoute un point d'application inspectable, mais fait de Webship une partie de la frontière TLS de confiance.
| Préoccupation | Terminaison TLS | Pass-through TLS | | --- | --- | --- | | Point de terminaison TLS | Webship | Origine | | Application en texte brut sur Webship | Oui | Non | | Clés de session en aval actives chez Webship | Oui | Non | | Routage par chemin ou méthode HTTP | Oui | Non | | WAF, Bouclier API et limites de corps chez Webship | Oui | Non | | Mise en cache du proxy, réécritures et en-têtes de transfert | Oui | Non | | Entrée du routage TCP | Autorité HTTP et politique de routage | SNI ClientHello | | Routage HTTP/3 | Données de requête HTTP | Une seule origine UDP partagée | | Responsabilité de l'origine | HTTP ou TLS en amont configuré séparément | TLS complet, ALPN et pile HTTP |
La question importante n'est donc pas « Quel interrupteur est plus rapide ? » Il s'agit de « Quel composant doit être autorisé à voir et à contrôler la requête ? »
Quelle terminaison donne Webship
Avec tls_termination = true, Webship complète le TLS en aval et transmet la requête déchiffrée dans son pipeline de proxy inverse HTTP. Cela rend les fonctionnalités suivantes possibles :
- routage conscient du chemin, de l’hôte et de la méthode ;
- Inspection WAF et API Shield;
- limitations du corps de la requête et délais d'expiration de la politique ;
- mise en cache proxy et invalidation sécurisée pour la génération ;
- gestion des en-têtes de transfert et champs du journal d'accès HTTP ;
- Gestion des requêtes consciente du corps, nouvelles tentatives là où c'est sûr, et politique de disjoncteur ;
- traduction de protocole entre les connexions côté client et en amont.
Ce mode change également la responsabilité en matière de sécurité. L'hôte Webship doit protéger la clé privée du certificat, les clés de session, les données de requête et de réponse décryptées, les résultats d'observabilité et toute représentation mise en cache. Si le prochain saut doit rester chiffré, configurez le TLS amont typé séparément ; sinon, l'amont HTTP est en clair.
La terminaison est la limite droite lorsque Webship est censé se comporter comme un edge conscient des applications, et pas seulement comme un relais de transport chiffré.
Ce que la transmission directe préserve
Avec tls_termination = false—par défaut—Webship relaie le trafic TLS ou QUIC chiffré sans décrypter la requête ou la réponse HTTP. Le texte en clair de l'application et les clés de session actives restent à l'origine.
Cette frontière de confiance plus restreinte est précieuse lorsque les certificats doivent rester au niveau de l'application, que la politique de conformité interdit le décryptage en périphérie ou qu'une identité TLS spécifique à l'origine doit atteindre le client sans changement. Elle supprime également l'analyse HTTP et le travail de politique du chemin de relais.
Le compromis est strict : Webship ne peut pas inspecter ce qu'il ne peut pas déchiffrer. Il ne peut pas appliquer les règles WAF HTTP, router par chemin, réécrire les en-têtes, appliquer une politique d'API consciente du corps, ni remplir les journaux d'accès aux champs HTTP. L'origine doit fournir elle-même tous ces contrôles.
Le passage direct n'est donc pas une « terminaison avec moins de fonctionnalités ». C'est une architecture différente avec un propriétaire de sécurité différent.
Les limites spécifiques au protocole sont importantes
Pour HTTP/1.1 TLS et HTTP/2 TLS, Webship inspecte le ClientHello seulement autant que nécessaire pour sélectionner la destination TCP configurée par SNI. Chaque domaine en passage direct nécessite une route path_prefix = "/" générique car le chemin réel de la requête reste chiffré. Un client sans SNI n'est accepté que lorsque la configuration comporte un seul domaine.
L'origine doit négocier l'ALPN du client et prendre en charge le protocole sélectionné. Webship ne peut pas convertir un client HTTP/2 en une origine HTTP/1.1 tandis que la session TLS passe inchangée.
HTTP/3 utilise QUIC sur UDP et a une limite plus stricte. Le passage direct ne peut pas acheminer en toute sécurité par autorité HTTP chiffrée, donc chaque route HTTP/3 configurée doit se résoudre sur le même socket IP-UDP d'origine. Webship rejette les sockets Unix et plusieurs origines de passage direct HTTP/3 lors de la validation de la configuration plutôt que de router silencieusement de manière ambiguë.
Le HTTP/1.1 en clair et h2c ne sont pas affectés par reverse_proxy.tls_termination. Le paramètre contrôle uniquement le TLS HTTP/1.1 en aval, le TLS HTTP/2 et le TLS HTTP/3.
Capacité de demande mesurée
Le benchmark de capacité Webship 1.3.1 Debian a mesuré séparément les deux modes de reverse-proxy chiffrés. Chaque échantillon accepté nécessitait zéro erreur HTTP, socket, protocole, proxy, faute majeure de page et perte de paquet HTTP/3.
| Mode reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminaison TLS | 123 344 RPS | 124 957 RPS | 131 529 RPS | | Transmission TLS | 203 950 RPS | 266 845 RPS | 167 010 RPS |
Le passage à réponse faible nécessite moins de travail de la part de l'application : il relaie les données de transport chiffrées au lieu de terminer le TLS, d’analyser le HTTP, d’évaluer la politique et de produire un nouveau flux TLS en aval. Les taux de requêtes plus élevés en mode passage reflètent ce travail plus restreint.
Ces lignes ne représentent pas des ensembles de fonctionnalités identiques, et elles ne devraient pas être utilisées pour affirmer qu'une architecture de sécurité est universellement meilleure. La terminaison paie pour des capacités conscientes du HTTP que le passage direct ne peut fournir intentionnellement.
La diffusion en masse modifie le résultat
Le même benchmark a utilisé un corps de réponse de exactement 99 943 778 octets pour la matrice de streaming de 100 Mo. Ici, la terminaison TLS a produit un débit de charge utile médian plus élevé pour les trois protocoles :
| Mode reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminaison TLS | 3,585,7 Mio/s | 3,355,0 Mio/s | 1,938,6 Mio/s | | Passage TLS | 2 783,2 Mio/s | 2 135,0 Mio/s | 1 748,5 Mio/s |
Pourquoi la direction change-t-elle ? En mode de terminaison, l'origine du benchmark envoie du HTTP en clair à Webship, et Webship possède le chemin en vrac en aval optimisé. Les grandes réponses HTTP/1.1 et HTTP/2 peuvent utiliser kTLS Linux adaptatif et un tampon limité spécifique au transport. HTTP/3 utilise l'ordonnancement QUIC, DPLPMTUD, et le regroupement par réacteur au lieu de kTLS.
En mode pass-through, l'origine possède le TLS en aval et Webship relaie le flux chiffré ou les paquets QUIC résultants. Cela préserve la frontière TLS de l'origine, mais il ne peut pas utiliser le chemin de réponse en vrac conscient du HTTP de Webship.
La qualification HTTP/3 en sept échantillons a également vérifié la stabilité. Le streaming terminé a atteint une médiane de 1 938,6 Mio/s avec un coefficient de variation de 2,12 % ; le passage direct a atteint 1 748,5 Mio/s avec un coefficient de variation de 1,65 %. Les deux ont livré exactement le même contenu sans aucune erreur côté client, de protocole ou de perte de paquets.
Configurer le passage direct délibérément
Une configuration minimale de passage maintient l'identité TLS en attente afin qu'un opérateur puisse activer la terminaison plus tard sans changer les chemins des certificats :
[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 = 30000Le certificat Webship mis en scène est validé mais n'est pas utilisé par les sessions de passage actives. L'origine à 10.0.0.20:443 doit terminer TLS et supporter le protocole négocié par le client.
Activer la terminaison lorsque le périphérique a besoin de HTTP
Pour un edge conscient des applications, activez la terminaison et envoyez le trafic HTTP résultant vers l'origine sélectionnée :
[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 = 30000Cette configuration peut acheminer et inspecter le HTTP. Ajoutez TLS en amont lorsque le réseau entre Webship et l'origine n'est pas déjà fiable ou isolé.
Changer de mode sans redémarrer Webship
Webship peut modifier tls_termination via un rechargement du fichier de configuration ou l’outil MCP webship.reverse_proxy.apply_config vérifié par version. Lisez l’objet et la version actuels avec webship.reverse_proxy.get_config, modifiez uniquement le champ prévu dans l’objet complet renvoyé, et soumettez-le avec le expected_version_id correspondant.
Les nouvelles connexions TCP utilisent le nouveau mode. Les clients HTTP/3 se reconnectent au transport UDP remplacé. Les modifications de chemin de certificat et de clé restent liées au processus et nécessitent un redémarrage, donc gardez une identité de terminaison valide préparée avant une bascule en direct.
La vérification de version empêche un opérateur d'écraser une modification de configuration simultanée. Une mise à jour rejetée laisse le runtime actif et la configuration persistante inchangés.
Une liste de contrôle pratique de sélection
Choisissez le mode de passage lorsque toutes ces conditions sont vraies :
- L'origine doit conserver la limite du certificat et les clés de session.
- Le routage TCP au niveau SNI — ou une seule origine UDP HTTP/3 partagée — est suffisant.
- L'origine fournit le WAF nécessaire, l'autorisation, la journalisation, les limites de corps et les contrôles d'abus.
- Aucune mise en cache en périphérie, réécriture de chemin, politique d’en-tête de transfert, ni traduction de protocole HTTP n’est requise.
Choisissez la résiliation lorsque l'une de ces options est requise sur Webship :
- Acheminer par hôte, chemin ou méthode.
- Inspecter les requêtes avec WAF ou API Shield.
- Appliquer des limites de corps, des délais d'attente HTTP ou une authentification au niveau du point de terminaison.
- Mettre en cache les réponses ou réécrire les en-têtes HTTP.
- Traduire entre les protocoles HTTP en aval et en amont.
- Observer les champs HTTP à la frontière du proxy.
Quel que soit le mode que vous sélectionnez, testez SNI, ALPN, l'identité du certificat, l'annulation côté client, la fermeture partielle en amont et l'intégrité exacte des réponses. Mesurez séparément la capacité de requête et le débit en streaming : le mode le plus rapide pour une petite réponse n'est pas nécessairement le mode le plus rapide pour un corps de 100 Mo.
Webship fait du passage la valeur par défaut car un proxy ne devrait pas élargir silencieusement sa frontière de confiance. La terminaison reste un choix opérationnel actif et explicite lorsque le comportement à la périphérie conscient du HTTP vaut cette responsabilité.
Lisez la [documentation sur le reverse-proxy](/docs/1.3.1) complète, comparez la [matrice de test de référence](/benchmarks) acceptée, ou téléchargez Webship depuis les [Téléchargements](/downloads).
Sources et méthode de contenu
Les valeurs de performance sont des médianes acceptées provenant du benchmark unifié Debian Webship 1.3.1 datant du 11 septembre 2026 ; ses critères d'acceptation nécessitent zéro erreur côté client, HTTP, socket, protocole, proxy, faute de page majeure et perte de paquets HTTP/3.