◇ OpenCyber Academy
Technical · Chapter 2 · English

Chapter 2 — Networks and protocols

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Networks and protocols

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Three secure channels"]
  N2["2.2 Hybrid key exchange"]
  N3["2.3 Reading the negotiated group"]
  N4["2.4 Bigger handshakes"]
  N5["2.6 Hands-on activity"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Three secure channels"]
  N2["2.2 Hybrid key exchange"]
  N3["2.3 Reading the negotiated group"]
  N4["2.4 Bigger handshakes"]
  N5["2.6 Hands-on activity"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 Three secure channels]
    |
    v
[2.2 Hybrid key exchange]
    |
    v
[2.3 Reading the negotiated group]
    |
    v
[2.4 Bigger handshakes]
    |
    v
[2.6 Hands-on activity]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) explain TLS, SSH and IPsec at the level needed to check them; (2) identify the key-exchange and authentication parts of each; (3) read which key-exchange group a TLS connection used; and (4) explain why post-quantum handshakes are larger.

2.1 Three secure channels

TLS protects web and API traffic; SSH protects administrator logins and file transfers (SFTP); IPsec protects site-to-site VPNs. Each first agrees a session key (key exchange) and proves identity (certificates, host keys or pre-shared keys), then encrypts data with a symmetric cipher.

For each channel, ask two questions: how is the key agreed, and how is identity proved? Post-quantum work changes the first part with hybrid key exchange and, later, the second with new certificates or keys. At HHG, the site VPNs use IPsec, the channel file exchange uses SFTP and the guest portal uses TLS.

2.2 Hybrid key exchange

The transition design combines a post-quantum and a classical method so that both would have to be broken — called hybrid (RFC 9794). In TLS 1.3 the hybrid group X25519MLKEM768 is defined in RFC 10024. In SSH, OpenSSH offers mlkem768x25519-sha256 (OpenSSH release notes). In IPsec, RFC 9370 adds extra key exchanges such as ML-KEM.

Check the product's documentation for its name.

2.3 Reading the negotiated group

On a lab machine with a current OpenSSL, openssl s_client -connect lab-server:443 -groups X25519MLKEM768:X25519 prints details of the handshake, including the negotiated group in recent versions. Server logs can record the group if configured. For SSH, ssh -v prints the key-exchange algorithm chosen ("kex: algorithm: …"). Only run such commands against systems you are authorized to test.

Save the output with the date and the client version, since an old client cannot show a hybrid group even when the server offers one. On HHG's staging guest portal, this is how the group-order problem of Chapter 5 was first seen.

2.4 Bigger handshakes

The client's TLS key share grows from 32 bytes (X25519) to 1,216 bytes (X25519MLKEM768), so the first message often no longer fits in one network packet. Most networks handle this; some old firewalls do not. Post-quantum signatures add more when certificates change: an ML-DSA-44 signature is 2,420 bytes.

For operators the practical effect is that a hybrid handshake can fail on one network path while working on others. When you see timeouts only through one firewall or proxy, think of message size before blaming the algorithm. Note the device model and firmware, as the HHG operator did at the Summit property.

2.5 Worked example

An HHG operator connects from the lab to the staging guest portal with a current client and sees the hybrid group negotiated. With an older client, the connection succeeds with X25519 — the expected fallback. Through the lab copy of the Summit property's old firewall, the connection times out; the operator records the firewall model and firmware for follow-up.

The three results mean different things: the hybrid result shows the server works, the fallback shows older clients are still served, and the timeout points to the network path, not the server. The operator does not change the portal; the firewall becomes a follow-up item.

2.6 Hands-on activity

In your lab, run a TLS client against a test server twice — with and without the hybrid group offered — and record the negotiated group each time. Repeat for SSH with ssh -v.

Record for each run the command, client version, target, time and negotiated group or key-exchange algorithm. Then explain in one or two sentences why the results differ. If your client cannot show the group, note that and use a newer client. Use only your own lab servers. Keep the output files with dated names, because later chapters ask you to compare runs and write findings from them.

2.7 Common errors and limits

Each error leads to a wrong conclusion or an unsafe act. Hybrid key exchange protects session keys, but the server still proves its identity with a classical certificate. Testing without authorization can break a service and cost your team the right to test. A firewall that drops large messages, as at Summit, is a network problem, and removing hybrid to fix it would leave all other traffic unprotected. Check your notes against these three before writing a finding.

Exercises

Synthesis

TLS, SSH and IPsec each agree keys and prove identity. Hybrid key exchange is available in all three; operators read negotiated algorithms from client output and logs.

Continue studying — chapter 02 of 18

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →