The worker 10.1.4.21 sends GET /orders to https://api.acme.example, at 10.3.2.5 port 443. On
the way, the request crosses p1-edge and p2-edge, routers that neither network A nor network B runs.
Could they read it, turn it into /orders?all or send it twice, and what stops them?
Intent: every router on the path can read, change or replay a packet. TLS seals one connection end to end once a certificate proves who the server is, and IPsec seals everything between two networks. A firewall decides who may start a connection at all.
For TLS, read the road as the open internet: the request goes to the api with no tunnel. The IPsec section then seals the same road for every program.
What a secure path must give#
A router reads a packet’s header to forward it (Part 4). Nothing stops it from also reading the data,
changing it, or sending a recorded copy again later. Four guarantees close those doors between the
worker 10.1.4.21 and the api 10.3.2.5, built from keys and signatures.
| Guarantee | The attack it stops | The tool |
|---|---|---|
| confidentiality | p1-edge reads GET /orders | encryption with a key both ends share |
| integrity | p1-edge changes /orders to /orders?all | a tag over the data, made with the shared key |
| authentication | another machine answers as api.acme.example | a signature, and a certificate that names the signer |
| freshness | p1-edge sends a recorded request again | sequence numbers, and nonces: random values used once |
Replay matters for any request that changes something: an order sent twice is placed twice. No key stops a router from dropping packets. Keys only stop it from reading or changing them without being caught.
The tools#
Each guarantee is built from a few standard tools. The algorithms are public; only the keys are secret.
| Tool | What it does | In use today | Retired |
|---|---|---|---|
| symmetric cipher | one shared key encrypts and decrypts; fast enough for all the data | AES with 128, 192 or 256-bit keys; ChaCha20 | DES (withdrawn by NIST in 2005); 3DES (NIST disallowed it for encryption after 2023-12-31) |
| hash | turns any input into a short fingerprint of fixed size; any change in the input changes it | SHA-256 | MD5 and SHA-1, not for signatures |
| HMAC | a hash keyed with a shared secret: only key holders can make or check the tag | HMAC-SHA-256 | HMAC-MD5, which IPsec must not use |
| key pair for signatures | the private key signs; anyone with the public key can check | RSA with 2,048 bits or more, ECDSA, Ed25519 | RSA under 2,048 bits |
| key pair for key agreement | each side mixes its own secret with the other’s public share | X25519, P-256 | RSA key transport in TLS: the client encrypts the secret with the server’s RSA key |
TLS 1.3 and ESP with AES-GCM encrypt and tag in one step, with an AEAD cipher such as AES-GCM or ChaCha20-Poly1305. The receiver gets either the original data back or an error, never altered data.
Agreeing on a key in public#
How do two machines that never met agree on a key while p1-edge copies every packet? With Diffie-Hellman key exchange on an elliptic curve, such as X25519. Each side picks a random secret and sends a key share made from it, in the open.
Each side then combines its own secret with the other’s share, and both get the same shared secret. p1-edge holds both shares but neither side’s own secret, and the shares alone do not give the shared secret.
Both ends turn the shared secret into the keys for each direction, with a key derivation function. The worker’s first message sealed with them is its Finished (TLS, below), and the data follows.
Both sides pick new secrets for every connection, so each connection has its own keys. If the api’s long-term key is stolen next year, today’s recorded traffic stays sealed, once both sides have deleted the session keys. This is forward secrecy.
The exchange has one gap: it says nothing about who sent a share. p1-edge could run one exchange with the worker and another with the api, and sit in the middle of both. Only a certificate check closes that gap (next section).
A quantum computer could one day open traffic recorded today: a harvest now, decrypt later attack. NIST published ML-KEM, a way to agree on keys meant to resist it, as FIPS 203 on 2024-08-13.
Cloudflare reports running X25519MLKEM768 on TLS 1.3, a hybrid of X25519 and ML-KEM. It protects a connection only if the client supports it too.
Certificates: who vouches for api.acme.example#
Key exchange gives the worker a key it shares with someone. A certificate says who: it binds a name
to a public key, and a certification authority (CA) signs that binding. Here api.acme.example, at
10.3.2.5, sends two certificates, and the worker 10.1.4.21 checks them before it trusts the key.
The chain the worker checks#
The api sends its own certificate, the leaf, and the certificate of the CA that signed it, the intermediate. The root may be left out: the worker must already hold it in its trust store, the list of CAs its system trusts.
| Certificate | Subject (the name) | Issuer | Valid | Signed with the key of |
|---|---|---|---|---|
| leaf | api.acme.example | Example Issuing CA | 2026-09-01 to 2027-02-28 | Example Issuing CA |
| intermediate | Example Issuing CA | Example Root CA | its own dates, checked the same way | Example Root CA |
| root | Example Root CA | itself | in the worker’s trust store | itself |
The worker checks four things:
| Check | Passes when |
|---|---|
| the name | api.acme.example appears in the leaf’s subjectAltName field, the list of names the certificate is valid for; the older Common Name field must not be used |
| the signatures | each certificate is signed by the next one up, and the chain ends at a root in the trust store |
| the dates | the time of the check falls inside each certificate’s dates |
| revocation | the CA has not withdrawn the certificate, by its list of revoked certificates or an online status check (OCSP) |
The worker reads the time of the check from its own clock, here 2026-10-16. A clock set wrong can
fail a good certificate or pass an expired one. When a check fails, the worker ends the handshake with
an alert (an error message), such as certificate_expired for a date.
Why check the name? The check is what stops an on-path router, or someone who controls DNS, from posing as the api. A valid certificate for another name proves nothing about this one.
An everyday picture: a passport. A government you trust issues it, and the officer checks the name, the stamp and the expiry date.
The picture breaks in one place: a certificate is public, so anyone can send a copy. So the api also signs the handshake with its private key (CertificateVerify: a signature over the handshake, which the next section explains). Only after both checks does the worker send its Finished.
Lifetimes are getting shorter#
The CA/Browser Forum, where CAs and browser makers set the rules for public TLS certificates, adopted ballot SC-081 on 2025-04-11. It cuts the longest allowed lifetime from 398 days to 47 days. Since 2026-03-15 the limit is 200 days; it falls to 100 days on 2027-03-15 and to 47 days on 2029-03-15.
The api’s leaf, 180 days from 2026-09-01 to 2027-02-28, sits under today’s limit.
A certificate that lives 47 days cannot be renewed by hand for long. Renewal has to be automated.
Seeing the chain#
openssl s_client -connect api.acme.example:443 -servername api.acme.example -showcerts connects and
prints the certificates the server sent. -servername puts the name in the first message of
the handshake (the ClientHello).
-showcerts prints the chain as sent, not a checked one. By default the tool also goes on after a
failed check. Add -verify_return_error -verify_hostname api.acme.example to make it fail on a bad
chain or a wrong name.
TLS 1.3: one round trip, then sealed records#
TLS runs inside the TCP connection of Part 3, from the worker 10.1.4.21:51514 to the api
10.3.2.5:443, after TCP’s SYN, SYN-ACK and ACK. Its handshake does the key exchange and the
certificate check in one round trip. After that, every record is sealed.
The handshake, message by message#
| Message | From | Carries | Encrypted |
|---|---|---|---|
| ClientHello | worker | the versions it speaks, its cipher suites, an X25519 key share, the server name api.acme.example, a random value | no |
| ServerHello | api | the chosen version and cipher suite (here TLS_AES_128_GCM_SHA256), its own key share, a random value | no |
| Certificate | api | the leaf and Example Issuing CA’s certificate | yes |
| CertificateVerify | api | its signature over every handshake message so far | yes |
| Finished | api | a check value over the handshake, keyed from the shared secret | yes |
| Finished | worker | the same, from its side | yes |
GET /orders | worker | the request, in a sealed record | yes |
The messages after ServerHello are sealed with handshake keys, made from the two key shares. The data uses traffic keys, made after the api’s Finished.
CertificateVerify proves the api holds the private key behind its certificate. Finished proves that both sides saw the same messages. Had p1-edge struck the strong cipher suites from the ClientHello, the two check values would differ and the handshake would fail.
A modern client may also offer a hybrid post-quantum share (above): OpenSSL 3.5.7 negotiated X25519MLKEM768 in a test on 2026-10-16. The figure keeps the X25519 share.
Before Certificate, the api also sends a short EncryptedExtensions message, its other answers to the ClientHello. The server name travels in the ClientHello, so p1-edge can read it. It cannot read the certificate, which TLS 1.2 sent in the clear.
The worker sends its request after one TLS round trip, on top of the TCP handshake (Part 3). TLS 1.2 needed two.
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| round trips before the client’s data | 2 | 1 |
| key exchange | RSA key transport, static Diffie-Hellman or ephemeral Diffie-Hellman (new secrets for each connection) | ephemeral Diffie-Hellman for a certificate handshake, so every such connection has forward secrecy (resumption with a pre-shared key only, and 0-RTT data, are the exceptions) |
| encrypted | from ChangeCipherSpec on: the two Finished messages and the data | everything after ServerHello, the certificate included |
| record protection | AEAD, or a block cipher plus HMAC | AEAD only |
| status | still allowed, but its specification is obsoleted by RFC 9846 (July 2026); RSA key exchange is forbidden by RFC 10015 (July 2026) | RFC 9846 (July 2026); new protocols must make TLS 1.3 the default (RFC 9852) |
TLS 1.0 and 1.1 must not be used (RFC 8996), and neither must SSL 3.0 (RFC 7568).
A sealed record#
After the handshake, data travels in records. Each record’s outer header always says “application data” and version 1.2, whatever it holds. The true type sits inside the encrypted part, so p1-edge sees only a length.
Each side numbers its records from 0, and starts again at 0 when the key changes; the number feeds the per-record nonce. A record that is changed, replayed or moved fails its check.
The receiver then ends the connection with the alert bad_record_mac; an alert is an error message
that ends the connection.
Saving the round trip: 0-RTT and QUIC#
A client that talked to the server before can send data in its very first message, with a key kept from the earlier connection. This 0-RTT data saves the round trip, but nothing in the protocol stops someone from sending it again. Clients may send in it only what is safe to repeat.
TLS does not need TCP under it. HTTP/3 runs on QUIC over UDP (Part 2), and QUIC carries the TLS 1.3 handshake inside its own packets.
IPsec: sealing everything between two networks#
TLS seals one connection between two programs. IPsec seals every packet between two gateways, whatever program sent it. Here border-a1 and border-b1 run a tunnel, so the worker’s query to db-b1 on port 5432 crosses the providers sealed.
The wrap, step by step#
border-a1 receives the worker’s packet, 10.1.4.21 -> 10.3.2.6. It encrypts the whole packet,
header included, and puts an ESP header in front. ESP (encapsulating security payload) is the IPsec
format that seals packets.
The ESP header carries an SPI, 0x2a01, and a sequence number, 7. border-a1 adds a tag over the
ESP header and the sealed packet. Then it puts a new IP header in front: 198.51.100.10 -> 203.0.113.20, protocol 50.
The providers route on that outer header alone. border-b1 finds the right keys by the SPI and checks that sequence number 7 is new. It checks the tag, decrypts, and sends the inner packet on to db-b1.
| p1-edge and p2-edge see | They do not see |
|---|---|
the two gateways, 198.51.100.10 and 203.0.113.20 | the worker 10.1.4.21 and db-b1 10.3.2.6 |
| protocol 50, the SPI and the sequence number | the protocol inside, port 5432, the query |
| each packet’s size and time | anything inside the packet |
The SPI points to a security association (SA): one direction of the tunnel, with its keys and its counter. border-a1 to border-b1 is one SA, and the way back is another.
The tunnel ends at the gateways. From the worker to border-a1, and from border-b1 to db-b1, the packet travels plain, so a host on either network can still read it. TLS between the worker and db-b1 would cover those hops too.
The cost: about 60 bytes a packet#
Every packet carries the new header and the ESP fields. With AES-GCM over IPv4 the total is 54 to 57 bytes; this series rounds it to about 60.
| Added by the tunnel | Bytes |
|---|---|
| new IP header | 20 |
| ESP header: SPI and sequence number | 8 |
| per-packet value for the cipher | 8 |
| trailer: padding, its length, the next header | 2 to 5 |
| tag | 16 |
| total | 54 to 57, about 60 |
| a UDP header, when a NAT sits between the gateways | 8 more |
On a 1,500-byte link, the inner packet may then be about 1,440 bytes. TCP’s largest segment (MSS) is 1,400: 1,440 minus 20 bytes of IP and 20 of TCP. The gateway should lower the MSS in every SYN to 1,400, so TCP never sends a segment that does not fit.
Behind a NAT#
A NAT rewrites ports to tell its connections apart (Part 4), and ESP has no ports. So when a NAT sits between them, the gateways wrap ESP in UDP port 4500. The key exchange starts on UDP port 500 and moves to 4500 once it finds a NAT.
What both ends must agree on#
Nobody types the session keys. The gateways agree on them with IKEv2 (Internet Key Exchange), in a few request and response pairs.
| Exchange | What it settles | Sent |
|---|---|---|
| IKE_SA_INIT | the ciphers, the Diffie-Hellman curve or group with both shares, and nonces; together they make a protected channel | in the clear |
| IKE_AUTH | each gateway’s identity and proof, by a pre-shared key (a secret typed in at both ends) or a certificate; which traffic goes into the tunnel (the traffic selectors); the first pair of SAs for ESP | encrypted |
| CREATE_CHILD_SA | new SAs before the old ones run out (rekeying), with a fresh key exchange if asked | encrypted |
Here the traffic selectors are 10.1.4.0/24 on A’s side and 10.3.0.0/16 on B’s. border-a1 proposes
AES-GCM-128, PRF HMAC-SHA-256 and Group 31 (curve25519). Each gateway picks the SPI of the SA it
receives on: border-b1 picks 0x2a01, border-a1 picks 0x7c03.
| Must match | When it does not |
|---|---|
each gateway’s outside address, 198.51.100.10 and 203.0.113.20 | IKE_SA_INIT gets no answer, only retransmissions in its log; a firewall that blocks UDP 500 or 4500 on the way has the same effect |
| at least one IKE proposal: cipher, key derivation, Diffie-Hellman curve or group | the answer is NO_PROPOSAL_CHOSEN, and the tunnel never comes up |
| the pre-shared key, or the identities in the certificates | IKE_AUTH fails with AUTHENTICATION_FAILED |
| the traffic selectors, mirrored | TS_UNACCEPTABLE: the IKE SA can come up without its ESP SAs, so the tunnel looks up and carries nothing |
| at least one proposal for the ESP SAs | NO_PROPOSAL_CHOSEN for those SAs: the same tunnel that is up and carries nothing |
In a VPC#
A cloud VPN gateway is one end of such a tunnel, run by the provider. The example below is Google Cloud VPN; the other providers’ VPN pages are not used in this part.
| Google Cloud does | You still decide |
|---|---|
| runs the gateway, in ESP tunnel mode, for site-to-site tunnels only | the peer gateway at your end and its outside address |
| speaks IKEv1 and IKEv2, and accepts only a pre-shared key | the pre-shared key, typed the same at both ends |
| offers AES-GCM with 128, 192 or 256-bit keys in IKEv2, and older choices such as 3DES-CBC and Group 2 | one cipher per role, the same at both ends: Google’s advice, since the pick changes the MTU |
| keeps the IKE SA 36,000 s (IKEv2) and the ESP SAs 10,800 s by default | the lifetimes on your device |
| uses a gateway MTU of 1,460 (1,440 on HA VPN over Cloud Interconnect) and clamps the MSS; the inner packet gets 1,406 bytes with AES-GCM on IPv4, 1,398 behind a NAT | your device’s MTU, set to 1,460 to match |
Firewalls: who may start a connection#
TLS and IPsec protect the packets that should arrive. A firewall decides which packets may arrive at all. Here border-b1 lets the worker reach db-b1 on port 5432, and drops a stranger who tries the same.
Stateless or stateful#
A stateless filter judges each packet alone, by its header. A stateful one writes every connection it let start into a connection table, and lets that connection’s packets through.
| Stateless filter | Stateful filter | |
|---|---|---|
| reads | each packet’s addresses, protocol, ports and TCP flags | the same, plus its connection table |
| remembers | nothing | each connection it allowed, until it closes or goes quiet |
| how a reply gets in | a second rule must allow it: from port 5432 back to the client’s port | it matches a row; no rule needed |
| in a VPC | AWS network ACLs | AWS security groups, Google Cloud VPC firewall rules, Alibaba Cloud security groups |
A stateless filter cannot tell a reply from a stranger’s packet that looks like one. To pass the replies, it must allow every packet from port 5432 to the client’s whole port range.
The rules on border-b1#
border-b1 reads its rules from the top, and the first match decides.
| Rule | Action | Matches in the figure |
|---|---|---|
| 1 | allow TCP from 10.1.4.0/24 to 10.3.2.6 port 5432 | the worker’s SYN |
| 2 | allow packets of a tracked connection | db-b1’s SYN-ACK and everything after it |
| 3 | drop everything else | the stranger’s SYN |
The worker’s SYN, 10.1.4.21:40001 -> 10.3.2.6:5432, matches rule 1. border-b1 writes a row for the
connection in state SYN_SENT, and the row reads ESTABLISHED once the worker’s ACK passes. db-b1’s SYN-ACK matches the row
under rule 2.
Now a SYN from the stranger, 198.51.100.66, reaches border-b1 through p2-edge, also for
10.3.2.6:5432. It matches no row and no allow rule, so rule 3 drops it, without a reply. It is the
NAT row of Part 4 again: no row, no way in, unless a rule lets a new connection start.
How long a row lives#
A row goes when its connection closes, or after it stays quiet for a while (600 s in the figure). After that, a packet that only the row let through is treated like the stranger’s: a NAT and most cloud filters drop it.
On border-b1 that is db-b1’s answer to the worker, say to a long query. It matches no row and no allow rule, so rule 3 drops it. The worker’s own packets still match rule 1.
Linux connection tracking, by default, may pick up such a mid-stream TCP packet from the worker and write the row again. A UDP packet needs no pickup: with no row, it starts a new one if the rules allow it.
| Where | A quiet row is removed after |
|---|---|
| Linux connection tracking, an established TCP connection | 432,000 s (5 days), by default |
| Linux connection tracking, UDP | 30 s, or 120 s once the kernel sees a stream |
| a NAT, an established TCP connection | RFC 5382 says no less than 2 hours 4 minutes; a real NAT may use less (Google Cloud NAT: 1,200 s by default) |
| Google Cloud VPC firewall rules | the state stays active while one packet passes at least every 10 minutes |
| Alibaba Cloud security groups | the page says a session can last up to 910 seconds; it does not say whether that is an idle time |
On a Linux firewall, conntrack -L lists the rows. A connection that dies after a long silence may
have lost its row on a device on the path. Keepalives sent more often than the idle limit keep it
(Part 3).
In a VPC#
In a VPC the firewall is not one box at the border: Google Cloud applies its rules at each VM. Each provider’s filters differ, and their pages say how.
| Provider | Filter | State | Order of the rules |
|---|---|---|---|
| Google Cloud | VPC firewall rules, set on the network and applied per VM | stateful; a reply to an allowed connection cannot be denied | by priority; the lowest number that matches wins |
| AWS | security groups, attached to each VM | stateful | only traffic a rule allows gets in |
| AWS | network ACLs, on each subnet | stateless: replies need their own rule | by rule number, lowest first; the first match decides |
| Alibaba Cloud | security groups | stateful | priority 1 to 100, smallest first; at the same priority, drop before allow |
The provider runs the filter. You still write the rules: here, TCP 5432 from 10.1.4.0/24 to db-b1,
and nothing else comes in.
When it breaks#
| Case | Description | Check with | Why | Fix |
|---|---|---|---|---|
| a certificate the worker rejects | the call to https://api.acme.example fails with a certificate error | openssl s_client -connect api.acme.example:443 -servername api.acme.example -verify_return_error -verify_hostname api.acme.example; read the chain and the dates | the leaf has expired, or api.acme.example is not in its subjectAltName | renew it, and automate renewal since lifetimes keep shrinking; put the name in subjectAltName |
| an old client is refused | a client that speaks only TLS 1.2 with RSA key exchange fails the handshake, often with handshake_failure | openssl s_client ... -brief shows the version and cipher a working client gets; then the old client’s TLS library version | RSA key exchange gives no forward secrecy and is now forbidden (RFC 10015) | upgrade the client to TLS 1.3, or at least to ephemeral Diffie-Hellman |
| an IPsec tunnel that will not come up | the tunnel stays down, or comes up and carries nothing | the IKE log on both gateways: NO_PROPOSAL_CHOSEN, AUTHENTICATION_FAILED, TS_UNACCEPTABLE, or no answer | the proposals, the pre-shared key or the traffic selectors differ; or UDP 500 or 4500 is blocked | one proposal per role at both ends, the same key, mirrored selectors; let UDP 500, UDP 4500 and protocol 50 pass between the gateways |
| a tunnel that is up, but big transfers hang | the connection opens and small queries work; a large result never arrives | ping -M do -s 1412 10.3.2.6 from the worker (1,440 minus 28), then 1,413, which should fail; tracepath 10.3.2.6 | the tunnel costs about 60 bytes, and a blocked ICMP 3/4 keeps the sender from learning it (Part 5) | lower the MSS to 1,400 at the tunnel; let ICMP 3/4 through |
| replies dropped by a stateless rule | the SYN reaches db-b1, but the worker never sees the SYN-ACK | the subnet’s network ACL, both directions | a network ACL keeps no state: the reply from port 5432 to the worker’s port needs its own rule | allow the client ports back: 32768 to 60999 for Linux clients; other systems use other ranges, such as 49152 to 65535 |
Remember#
- A router on the path can read, change and replay a plain packet; encryption, a tag, a signature and a sequence number each stop one of these.
- Key exchange gives a shared key; the certificate says who holds the other end: the name, the chain to a trusted root, the dates.
- TLS 1.3 needs one round trip and encrypts everything after ServerHello; TLS 1.0, 1.1 and RSA key exchange are forbidden.
- IPsec seals every packet between two gateways for about 60 bytes: inner MTU 1,440, MSS 1,400, and both ends must agree on proposals, key and selectors.
- A stateful firewall lets replies in by its connection table; a stateless one needs a rule for them.
Sources#
Checked 2026-10-16.
- RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3: the handshake (sec. 2), what changed from TLS 1.2 (sec. 1.3), the record (sec. 5), 0-RTT (sec. 2.3, sec. 8), the required algorithms (sec. 9.1); obsoletes RFC 8446 and RFC 5246
- RFC 8446, TLS 1.3, the earlier version, obsoleted by RFC 9846
- RFC 5246, TLS 1.2: the full handshake (sec. 7.3)
- RFC 10015, deprecating static Diffie-Hellman and RSA key exchange in (D)TLS 1.2
- RFC 9852, new protocols using TLS must require TLS 1.3
- RFC 9155, Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2
- RFC 8996, Deprecating TLS 1.0 and TLS 1.1, RFC 7568, Deprecating SSL 3.0
- RFC 6066, TLS Extensions: server name indication (sec. 3)
- RFC 5280, Internet X.509 PKI Certificate and CRL Profile: validity, subjectAltName, path validation (sec. 6), revocation lists (sec. 5)
- RFC 9525, Service Identity in TLS: the name check, no Common Name
- RFC 6960, Online Certificate Status Protocol (OCSP)
- RFC 9110, HTTP Semantics: https certificate verification (sec. 4.3.4); port 443 (sec. 4.2.2)
- RFC 7748, Elliptic Curves for Security: X25519 and its Diffie-Hellman (sec. 6)
- RFC 5869, HKDF: the key derivation, RFC 2104, HMAC, RFC 8439, ChaCha20 and Poly1305
- RFC 9001, Using TLS to Secure QUIC
- RFC 4301, Security Architecture for the Internet Protocol: security associations (sec. 4.1)
- RFC 4303, IP Encapsulating Security Payload (ESP): SPI, sequence number, anti-replay
- RFC 4106, AES-GCM in ESP: the per-packet value, the tag and the packet expansion (sec. 7)
- RFC 8221, Cryptographic Algorithm Implementation Requirements for ESP and AH
- RFC 3948, UDP Encapsulation of IPsec ESP Packets
- RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2): the exchanges (sec. 1.2, 1.3), NAT traversal (sec. 2.23), the error types (sec. 3.10.1)
- RFC 9293, Transmission Control Protocol (TCP), RFC 5382, NAT Behavioral Requirements for TCP, RFC 6335, port number ranges
- NIST, FIPS 197 (AES), FIPS 203 (ML-KEM), SP 800-131A Rev. 2, withdrawal of 3DES, retirement of SHA-1
- CA/Browser Forum, Ballot SC-081v3, adopted 2025-04-11; TLS Baseline Requirements: the 200, 100 and 47-day steps (sec. 6.3.2)
- Cloudflare, Post-quantum cryptography
- openssl-s_client(1ssl), Debian, conntrack(8), Debian
- Linux kernel, nf_conntrack sysctl, ip-sysctl: the local port range
- Google Cloud, Cloud VPN overview, Supported IKE ciphers, MTU considerations, Tune NAT configuration, VPC firewall rules
- AWS, Security groups, Network ACLs
- Alibaba Cloud, Security group rules