FIT1093 Chap.10 Security Protocols: TLS, IPsec and Bluetooth
Security Protocols: TLS, IPsec and Bluetooth
Week 9 shows how real-world systems combine the cryptographic tools of the first six weeks, and which design principles keep the combinations secure.
Workshop 9 has students role-play a browser connecting to a university web server, with a certification authority in the background and an attacker trying to interfere, and then compare IPsec and Bluetooth Secure Connections with TLS.
In TLS, certificate issuance comes first: a certification authority signs a certificate that binds the server's name to its public key, which is the fix for the public-key substitution problem raised in Week 5. The handshake then runs a client hello and a server hello with the certificate, a key exchange, and the derivation of session keys, after which the record protocol encrypts and integrity-protects the application data.
This is hybrid encryption in practice, with public-key cryptography used once to set up fast symmetric keys.
The workshop asks what passive and active attackers can achieve, and what happens if the server's private key is stolen: in the older RSA-based key exchange of TLS 1.2, past sessions recorded by an attacker become readable, which is why TLS 1.3 relies on ephemeral Diffie-Hellman exchanges that provide forward secrecy.
IPsec provides similar protection lower down, at the level of IP packets, which suits virtual private networks that must protect every application between two networks.
Bluetooth Secure Connections runs an elliptic-curve Diffie-Hellman exchange between devices that usually have no certificates, so it defends against a man in the middle by involving the user or a second channel, for example by asking both devices to display the same number for confirmation. Across all three protocols, the recurring question is how each exchanged key is authenticated.
What this chapter covers
- 01
Certificate issuance and the role of the certification authority
- 02
The TLS 1.2 handshake steps and the record protocol
- 03
Passive, active and stolen-key attackers
- 04
Forward secrecy and the TLS 1.3 change
- 05
IPsec for virtual private networks
- 06
Bluetooth Secure Connections and pairing confirmation
Worked example · free
Decide which recorded sessions a stolen server key exposes
- 2RSA key transport sessions: each pre-master secret was encrypted under the server's public key, so the stolen private key decrypts it and the session keys can be re-derived.
- 2Ephemeral Diffie-Hellman sessions: the session keys came from one-time exponents that were discarded, and the server key only signed the exchange, so these recordings stay unreadable.
- 2Going forward, the attacker can impersonate the server until the certificate is revoked and replaced, so the key compromise must be reported and the certificate reissued.
Key terms
- Certification Authority
- A trusted organisation that verifies identities and signs certificates binding names to public keys.
- TLS Handshake
- The opening phase of a TLS connection in which client and server agree on algorithms, authenticate the server and derive session keys.
- Forward Secrecy
- The property that compromise of a long-term private key does not reveal the keys of past sessions.
- Virtual Private Network
- A protected connection that carries traffic between networks or devices over an untrusted network such as the internet.
Security Protocols: TLS, IPsec and Bluetooth FAQ
What does the certificate prove in a TLS connection?
It shows that a trusted certification authority vouched for the binding between the server's name and its public key. The browser checks the authority's signature, which stops an attacker substituting their own key during the handshake.
Why does a stolen server key expose old TLS 1.2 sessions?
With RSA key transport, each session's pre-master secret was encrypted under the server's long-term public key. Anyone holding the private key can decrypt recorded handshakes and re-derive every past session key.
Why is IPsec common for company VPNs?
It protects traffic at the network layer, so every application between two sites or between a laptop and the office network is covered without changes to the applications themselves.
How does Bluetooth pairing stop a man in the middle?
The devices derive a short confirmation value from the public keys they actually received and ask the user to compare or enter it. If an attacker swapped keys, the values differ and the user can reject the pairing.
Assessment move
For each protocol in this chapter, write the same three lines: who the attacker might be, which keys are exchanged, and how each key is authenticated. Role-play the TLS handshake with two friends as the workshop suggests, saying aloud what each message contains and which earlier week's tool it relies on.
Practise the stolen-key question until you can explain forward secrecy in two sentences and connect it to ephemeral Diffie-Hellman from Week 5. Then compare IPsec and TLS by the layer they protect and what that means for a VPN, and compare Bluetooth pairing with web certificates by asking how each defeats key substitution when the parties start with no shared secret.
Working through Security Protocols: TLS, IPsec and Bluetooth in FIT1093? Sia is AskSia’s AI Cybersecurity tutor — ask any FIT1093 Security Protocols: TLS, IPsec and Bluetooth question and get a clear, step-by-step explanation grounded in how FIT1093 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
