In Transit Encryption

In Transit Encryption

1) Definition and limits of control

In-transit encryption is the protection of data along the entire network transmission path (browser ↔ server, service ↔ service, agent ↔ broker, database ↔ application, data center ↔ data center) so that passive interception and active attacks on the channel do not reveal the content and do not allow it to be modified without detection.

What we cover: public and private APIs (HTTP/HTTPS, gRPC), streaming and brokers (Kafka, NATS, RabbitMQ), WebSocket, databases and caches over the network, service traffic within clusters, VPN/between-data centers and clouds, DNS requests, mobile/IoT clients.

What we do not fully cover: attacks on endpoints (host/browser compromise), application vulnerabilities, leaks from logs/dumps. This is solved by separate controls (A&A, rights minimization, encryption at rest, secure logging).

2) Threat model and targets

Risks: traffic interception/spoofing (MITM), protocol downgrade/cipher suite, fake certificates/CA, key leakage, SNI/metadata attacks, mixed content, TLS mistermination on balancers, insecure service interconnections.

1. Confidentiality + integrity with cryptographic authentication.

2. Opposition to downgrade (strict policy and config).

3. Identification of the parties (server, if necessary - mutual).

4. Managed certificate/key lifecycle and auditing.

5. Performance profile without security trade-offs.

3) Basic principles

TLS is everywhere by default. External and internal traffic - encrypt.
Modern versions. TLS 1. 3 as standard; TLS 1. 2 - only under strict policies. Disable 1. 0/1. 1.
AEAD cipher suites with PFS. AES-GCM or ChaCha20-Poly1305; PFS via (EC) DHE.
Curves/Key Examination X25519 (preferably) or secp256r1 (P-256). RSA keys ≥2048, better than ECDSA (P-256).
mTLS where trust is scarce. Inter-service channels, admin APIs, brokers, databases - through mutual authentication.
HSTS for web. Forced HTTPS + preload for public domains.
"Encrypt-and-encrypt-again" consciously. TLS-termination on the perimeter + re-encryption to backends or end-to-end passthrough - select according to the threat model.
Crypto-agility. Ability to change curves/suites/versions with zero downtime.

4) Protocol stack and scripts

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 for HTTP/2, h3 for HTTP/3; h2c inhibit (without TLS).
HTTP/3/QUIC: reduces latency, embedded 0-RTT, and compound migration; 0-RTT allow selectively (replay risk).
gRPC: over h2/h3; mandatory TLS, optional mTLS + per-RPC authorization.
WebSocket: wss ://only; in proxies/balancers - correct upgrade and TLS pinning of the domain.

4. 2 Inter-service traffic and service-meshes

Sidecar model (Istio/Linkerd, etc.). Automatic mTLS, permission policies, certificate rotation.
SPIFFE/SPIRE. Decentralized service identities (SPIFFE ID), SVID certificates, short TTLs.
TLS parameters are centralized. Minimize config discrepancies in service code.

4. 3 Brokers/Streaming/Queues

Kafka/NATS/RabbitMQ: TLS for kliyent↔broker and broker↔broker; mTLS if possible.
SASL over TLS: if mTLS is not possible, authentication by tokens/logins, but encrypt the channel.
ACL and topic authorization. Encryption ≠ access control.

4. 4 Databases and caches

PostgreSQL/MySQL/SQL Server: enable TLS, CN/SAN validation, CA pin/root.
Redis/Memcached: use stunnel/TLS radishes; prohibition of plain traffic in the product.

4. 5 Network/tunnels

Between data centers/clouds: IPsec (IKEv2) or WireGuard (a modern set of primitives).
Admin access: SSH with modern KEH/ciphers; no passwords, only keys/SSO.

4. 6 DNS and auxiliary protocols

DNS over HTTPS (DoH )/DNS over TLS (DoT) for clients and within the cluster where possible.
Disable mixed content. Nothing at http ://on pages https ://.

5) Certificates, PKI and Key Management

PKI model: for external domains - public CA; for internal traffic - own CA or SPIRE-CA.
Automation: ACME/Cert-manager for Kubernetes, short TTL, auto-rotation.
OCSP stapling и CRL. Turn on stapling at the fronts; regularly update chains.
Pinning - with caution. In mobile/desktop clients - pin CA/SPKI with an emergency rolling mechanism.
Key storage: private keys in HSM/KMS/secret storages; minimum exposures; logging prohibition.

6) Configurations: practice profiles

• Versions: TLS 1. 3 (required), TLS 1. 2 (fallback).

• TLS 1. 3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256' (+ options AES256/CHACHA20 if required).
• Curves: X25519, secp256r1.
• Certificates: ECDSA-preferred, RSA-fallback.
• Secure headers: 'Strict-Transport-Security', 'X-Content-Type-Options', 'X-Frame-Options' (by case), 'Referrer-Policy'.
• Cookies: 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict by design).

• Client certificate is required.
• Short TTL client SVID (hours/days), automatic rotation.
• Policies: who can connect to whom (intent-based/work through mesh authorization).

7) Performance and reliability

Hardware acceleration: AES-NI/ARMv8 Crypto, preference ChaCha20-Poly1305 on CPU without AES-NI.
Session resumption: TLS 1. 3 tickets; think over the life span (balance between perfume and safety).
0-RTT: for idempotent queries only; protect against replay (server anti-replay mechanisms).
Balancers/proxies: clearly select termination vs passthrough; at termination - re-encrypt to the backend.
Observability: ALPN handshake/error/negotiation metrics, TLS percentage 1. 3, certificate expiration, OCSP status.

8) Testing and verification

Scan of TLS profile. Regular checks of supported versions/suites/curves and HSTS/OCSP.
Negative tests: prohibition of downgrade, rejection of weak suits, failure of connections without SNI/without valid chain certificate.
Channel pentest: MITM simulations, pinning checks in mobile clients, 0-RTT replay attempts.
Chaos tests: expiration/revocation of certificate, unavailability of OCSP/CA.

9) Frequent mistakes and how to avoid them

TLS enabled, but no host validation. We always check CN/SAN, prohibit 'InsecureSkipVerify'.
Mixed content. Block http resources on https pages, use CSP.
Weak/outdated versions and suits. Disable TLS 1. 0/1. 1, CBC/RC4/3DES.
Lack of inward re-encryption. Plain traffic from the balancer to the application is a risk.
Long-lived certificates. Do short TTLs and auto-updates.
Bad SNI/ALPN behind proxy. Correct SNI/ALPN transmission with TLS pass/termination.

10) Mini recipes (configuration fragments)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Policies and compliance

Minimum requirements: TLS 1. 3 wherever possible; TLS 1. 2 - with a limited set of suites.
Regulation: PCI DSS/financial sector - prohibition of weak versions/suites; mandatory rotation and audit.
Zero Trust approach: identities per workload, continuous validation and service-level policies.

12) Operation and SLO

SLO: ≥99% successful handshakes, ≥95% traffic on TLS 1. 3, 0% mixed content.
Alerts: expiration of certificates (<14 days), increase in handshake failures, drop in TLS 1 share. 3, OCSP stapling errors.
Procedures: emergency replacement of the CA/root, revocation of the compromised key, disabling the 0-RTT.

13) Checklists

• TLS 1 disabled. 0/1. 1 and weak suites, AEAD and PFS included.
• ALPN configured (h2/h3); prohibition of h2c.
• HSTS enabled (for public domains), no mixed content.
• Certificates are auto-updated, OCSP stapling is running.
• Internal channels are protected by mTLS (or WireGuard/IPsec equivalent).
• Validated host/chain validation on clients/SDK.

• Monitor TLS/ALPN/error and expiration versions.
• Crypto-agility plan (translation to new suites/curves).
• Periodic channel pentests and config reviews.

14) FAQ

Q: Is TLS only enough on the perimeter?
Oh no. Internal traffic must also be encrypted (mTLS/tunnels/mesh), especially in the clouds and during multi-lease.

Q: Do you need a 0-RTT?
A: Enable pointwise for idempotent requests, otherwise disable due to the risk of replay.

Q: What to choose for the inter-data center? IPsec or WireGuard?
A: WireGuard is simpler and faster, IPsec is mature and widely supported. Both are valid when configured correctly.

Q: How do you protect webhooks "on the go"?
A: HTTPS with a modern profile + sender certificate verification (if mTLS) + payload signature and timestamp verification (see Webhook Delivery Guarantees, Request Signing and Verification).

• "At Rest Encryption"
• "Authentication and Authorization"
• "Sign and Verify Requests"
• "S2S Authentication"
• "Key Management and Rotation"