Study Guide
Transport Encryption, Key Agreement and Forward Secrecy
How data is protected while it travels: the three jobs inside a TLS connection, what the certificate proves in HTTPS, how two parties agree a secret in public with ECDHE, what makes a key ephemeral, and why forward secrecy keeps Monday's recording safe when a key is stolen on Friday.
Lesson 6.9 Cryptography & PKI
Data travelling across a network can be read or changed by anyone in between. This lesson works out how a secure connection protects it, how two parties agree a secret in public, and why stealing a key later need not expose what was said before.
Stage: Think
A tapped line
Think it through
Alice wants a private telephone conversation with Bob over a line that Mallory may be tapping. What three things must Alice and Bob manage?
- Hint 1: What if the person who answers is not Bob?
- Hint 2: How can they agree a code if Mallory hears everything?
Show what happens
Make sure the person who answered really is Bob; agree a secret code without Mallory learning it, over the very line she is listening to; and then speak in that code.
Think it through
Show the answer
Answer: A. Yes, if one book covered every call.
Yes, if Bob used one code book for every call. If they made up a new code for each call and destroyed it afterwards, she could not.
Stage: Explain
Transport encryption
Transport encryption protects data in transit between two endpoints, so that anyone in between can neither read it nor change it unnoticed.
The standard protocol is Transport Layer Security (TLS). HTTPS is ordinary web traffic (HTTP) carried inside TLS. TLS also protects email delivery, many VPNs, application programming interfaces and messaging.
Check your understanding
Show the answer
Answer: C. HTTP carried inside TLS
Ordinary web traffic, HTTP, carried inside TLS.
TLS replaced an older protocol called SSL. All versions of SSL, and TLS 1.0 and 1.1, are obsolete and insecure. The versions in use are TLS 1.2 and TLS 1.3, and TLS 1.3 is preferred. People still say “SSL certificate” out of habit; the certificates are the same ones, used with TLS.
HTTPS: TCP, TLS and web communication follows a whole web request through the network. This lesson looks more closely at the cryptography.
Stage: Explain
Three jobs in one connection
A TLS connection does three separate jobs, with three different tools.
Alice wants a private telephone conversation with Bob, over a line that Mallory may be tapping.
- Authentication: is this really Bob? Before saying anything private, Alice checks that the person who answered is Bob and not Mallory imitating him. In TLS this is the certificate, together with proof that the server holds the matching private key.
- Key agreement: agree a secret for this call. Alice and Bob need a secret code that Mallory does not know, and they must arrange it over the very line Mallory is listening to. In TLS this is the key exchange, which produces shared secret material without ever sending it.
- Symmetric encryption: talk in the code. For the rest of the call they speak in that code. In TLS this is a symmetric cipher such as AES, using keys derived from the shared secret.
Where the analogy stops. People recognise each other’s voices; computers cannot, which is why a certificate from a trusted authority is needed. And on a real call, usually only one side is checked: the browser authenticates the server, and the server normally learns nothing verified about the visitor.
Check your understanding
Show the answer
Answer: A. Privacy with an impostor
A perfectly private conversation, possibly with an impostor.
Each job needs the others. Encryption without authentication gives a perfectly private conversation with an impostor. Authentication without key agreement leaves nothing to encrypt with. The division of labour is the same as in hybrid encryption: asymmetric cryptography sets things up, and fast symmetric encryption does the bulk of the work.
Stage: Predict
The handshake, step by step
The opening exchange of a TLS connection is called the handshake. This is a simplified TLS 1.3 handshake between Alice’s browser and a fictional bank’s web server.
Think it through
Put the three jobs in the order they happen in a TLS 1.3 connection: speak in the code, check it is really the bank, agree a code.
- Hint 1: Can anything private be sent before the server is checked?
Show what happens
Agree a code (the key shares are exchanged in the first messages), check it is really the bank (the server proves it holds its certificate’s key), then speak in the code. The step-through shows the detail.
Seven steps, normally completed in a small fraction of a second. Resumed connections and optional features are left out. The bank is fictional.
Browser
Step 1 of 7: Say hello, and send a temporary public key
The browser lists the cipher options it supports and includes the public half of a key pair it has just generated for this connection only.
Technical detail: This message is the ClientHello; the temporary public key is its key share.
Server
Step 2 of 7: Reply with its own temporary public key
The server chooses the options and sends the public half of its own freshly generated key pair.
Technical detail: This is the ServerHello. Everything after it is encrypted.
Browser and server
Step 3 of 7: Each derive the same shared secret
Each side combines its own temporary private key with the other side’s temporary public key. Both arrive at the same secret, which was never sent. Mallory, who saw only the two public halves, cannot compute it.
Technical detail: This is the ephemeral elliptic-curve Diffie-Hellman agreement, ECDHE.
Server
Step 4 of 7: Prove its identity
The server sends its certificate chain and a digital signature, made with the certificate’s private key, over the handshake so far.
Technical detail: These are the Certificate and CertificateVerify messages. Signing the handshake ties the identity to these particular temporary keys.
Browser
Step 5 of 7: Validate the certificate and the signature
The browser checks the chain, dates, name and permitted uses, then verifies the signature with the public key from the certificate. Now it knows the temporary key came from the real server.
Browser and server
Step 6 of 7: Derive the symmetric keys
Both sides derive a set of symmetric keys from the shared secret: the keys that will protect this connection’s data.
Technical detail: A key-derivation function produces separate keys for each direction.
Browser and server
Step 7 of 7: Exchange data under symmetric encryption
Requests and responses now travel encrypted and integrity-protected with those keys. When the connection ends, the temporary keys and the symmetric keys are discarded.
Notice what the certificate’s private key did: it signed. It was never used to encrypt the data or to transport a key.
Stage: Predict
Certificate authentication in HTTPS
When a browser shows that a connection is secure, the certificate check has established exactly this: the server at the other end holds the private key for a certificate that a trusted CA issued for the name in the address bar.
That is server authentication. It answers “am I connected to the genuine harbourbank.example?” It does not answer “is harbourbank.example the site I meant to visit?” or “is this organisation honest?” Public Key Infrastructure and Digital Certificates explains those limits.
Think it through
Show the answer
Answer: C. Only the server
Only the server, normally. The visitor proves who they are afterwards, for example by signing in.
Normally only the server is authenticated; the visitor proves who they are afterwards, by signing in. Where both ends must prove their identity with certificates, for example between two companies’ systems, the arrangement is called mutual TLS.
Stage: Predict
Key agreement: making a secret in public
Step 3 of the handshake is the surprising one. Two parties who share nothing create a shared secret while an eavesdropper watches every message.
Think it through
Can two people who share nothing agree a secret while an eavesdropper hears every message? How might that even be possible?
- Hint 1: Think of something easy to mix and impossible to unmix.
Show what happens
Yes, if they use an operation that is easy to do and infeasible to undo: each mixes in a private ingredient the listener never sees.
The method is the Diffie-Hellman key agreement. A popular way to picture it uses paint.
- Alice and Bob agree on a common colour, say yellow, in public. Mallory sees it.
- Each secretly chooses a private colour. Alice picks red; Bob picks blue.
- Each mixes their private colour with the yellow and sends the mixture to the other. Mallory sees an orange and a green.
- Each adds their own private colour to the mixture they received. Alice adds red to Bob’s green. Bob adds blue to Alice’s orange.
Both now hold the same colour: yellow, red and blue. Mallory has yellow, orange and green, and cannot separate a mixture to recover red or blue, so she cannot make the final colour.
Where the analogy stops. Paint is only a picture of a mathematical operation that is easy to perform and infeasible to undo. And the paint story has no authentication in it: if Mallory can sit in the middle and mix paint with each of them separately, she ends up sharing one colour with Alice and another with Bob. That is why the handshake also needs the certificate and signature in step 4.
The version used in modern TLS is ECDHE: Elliptic Curve Diffie-Hellman Ephemeral. The elliptic-curve mathematics makes it efficient. The final E is the subject of the next section.
Check your understanding
Show the answer
Answer: C. She cannot unmix them.
She cannot separate the mixtures to recover red or blue, so she cannot make the final colour.
Do not confuse: Two ways to get a shared key
- Key transport
- One side creates the secret and sends it, encrypted with the other side’s long-term public key. Older TLS did this with RSA.The secret travels, protected.
- Key agreement
- Both sides contribute, and each computes the same secret. Diffie-Hellman and ECDHE work this way.The secret never travels.
“Key exchange” is the general term, and the one the Security+ objectives use, for either method.
Stage: Predict
Ephemeral keys
Think it through
Show the answer
Answer: A. A new one for each call.
A new one for each call, discarded afterwards, so that losing one exposes nothing else.
An ephemeral key is a temporary key, generated for one connection and discarded when it ends.
Its opposite is a long-term key (also called a static key), such as the private key that belongs to a certificate, which stays the same for months.
In ECDHE, both sides generate a brand-new key pair for every connection. Nothing about one connection’s keys can be worked out from another’s, and once the keys are discarded, they are gone. The server’s long-term key is still used, but only to sign the handshake, proving that the temporary key really came from the server.
In the picture of the private telephone conversation, this means Alice and Bob do not keep one secret code for all their calls. They make up a new code at the start of every call and destroy their notes of it when they hang up.
Stage: Predict
Forward secrecy
Now the harder question. Suppose an attacker records encrypted traffic today and obtains a key later. Can the old recordings be decrypted?
Forward secrecy means that the compromise of a long-term private key does not expose the session keys of connections made before the compromise. It is also called perfect forward secrecy (PFS).
Go back to Alice and Bob’s private telephone conversation. Mallory cannot understand Monday’s call, so she records it and waits.
- One code book for every call. Suppose Bob keeps a single code book in his desk and uses it for all his calls. On Friday, Mallory steals the book. She plays back Monday’s recording, and every other recording she has, and decodes them all.
- A new code for every call. Suppose instead that Alice and Bob make up a fresh code at the start of each call and destroy their notes when they hang up. On Friday, Mallory steals everything in Bob’s desk, including the identity card he uses to prove who he is. Monday’s code is not there. It no longer exists anywhere, so the recording stays meaningless.
The identity card stands for the server’s long-term key: it proves who Bob is and plays no part in the code. The fresh code stands for the ephemeral keys. Forward secrecy is the second arrangement.
Where the analogy stops. In TLS nobody makes up a code aloud: both sides compute the session keys from the ephemeral key agreement, and “destroying the notes” means software reliably erasing those keys from memory. And the stolen identity card still matters: with it, Mallory can pretend to be Bob on future calls.
Check your understanding
Show the answer
Answer: B. A new code for every call
A new code for every call: Monday’s code was destroyed, so there is nothing to steal that decodes it.
This diagram sets out the same two arrangements in TLS terms.
The same attack against two designs. Only the way the shared key was established differs.
Starting pointOn Monday, Mallory records an encrypted conversation between Alice and Bob’s server. She cannot read it. On Friday, she steals the server’s long-term private key.
✗ Without forward secrecy (older RSA key transport)
- On Monday, Alice’s browser created the secret and sent it encrypted with the server’s long-term public key.
- That encrypted secret is in Mallory’s recording.
- On Friday, Mallory uses the stolen private key to decrypt it.
- She derives Monday’s symmetric keys.
OutcomeMallory reads Monday’s conversation, and every other conversation she ever recorded.
✓ With forward secrecy (ephemeral ECDHE)
- On Monday, both sides generated temporary key pairs and agreed a secret that was never sent.
- The long-term key only signed the handshake.
- When the conversation ended, both sides discarded the temporary keys and the symmetric keys.
- On Friday, the stolen key contains nothing that leads back to them.
OutcomeMonday’s conversation stays protected. The stolen key cannot decrypt it.
The whole difference is that, with ephemeral key agreement, the secret needed to decrypt Monday’s conversation no longer exists anywhere, and it was never in the recording.
This matters because traffic is cheap to record and store. An attacker, or an intelligence agency, can collect encrypted traffic for years in the hope of obtaining a key later. Without forward secrecy, one stolen key unlocks the whole archive.
What forward secrecy depends on
Forward secrecy is not an automatic property of “using TLS”.
- The key exchange must be ephemeral. TLS 1.3 allows only ephemeral key exchange for certificate-based connections, so it provides forward secrecy by design. TLS 1.2 provides it only when an ephemeral cipher suite (one with ECDHE or DHE in its name) is chosen, and not when the older RSA key transport is used.
- The keys must actually be discarded. If a server logs its session keys, keeps temporary keys longer than one connection, or re-uses them, the protection is weakened or lost.
Go deeper Resumption: a practical weakening
To save time, TLS lets a returning client resume an earlier connection without a full handshake. The server does this by encrypting some state with a key of its own and handing it to the client as a ticket.
If the server keeps that ticket-protecting key for a long time, then stealing it lets an attacker decrypt resumed connections that were protected by it. Good practice is to rotate such keys frequently. TLS 1.3 can also include a fresh ephemeral key agreement when resuming, which restores forward secrecy for the resumed connection.
This is the sense in which forward secrecy depends on key handling, and not only on which key exchange is used.
Check your understanding
Show the answer
Answer: B. It weakens it.
It weakens it: forward secrecy depends on the session keys actually being discarded.
What forward secrecy does not do
- It does not protect future connections. With the stolen long-term key, Mallory can now impersonate the server to new visitors until the certificate is revoked and replaced. Forward secrecy is about the past.
- It does not protect data at either end. What Alice said on Monday may be sitting in a database or a log on the server. Forward secrecy protects the conversation in transit, not what was stored afterwards.
- It does not help if an endpoint was already compromised on Monday. Malware on the server at the time could read the conversation as it happened.
Stage: Explain
Security+ terminology
The CompTIA Security+ SY0-701 exam objectives (objective 1.4) list transport/communication and key exchange under Encryption.
The objectives do not name TLS versions, ECDHE, ephemeral keys or forward secrecy in objective 1.4; these are how transport encryption and key exchange are done in practice.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: C. Impersonation of the site.
New visitors: the thief can impersonate the bank until the certificate is revoked and replaced. Past sessions stay protected.
Apply it
Apply it
Show the answer
Answer: B. Only control of that name.
That the server controls the name in the certificate, not that it is the site the user meant to visit.
Stage: Check
Check your understanding
These questions come from the approved revision bank. They were approved under owner-authorised delegated review: the site owner authorised the review and did not read each question individually.
Show answer
Answer: Certificate: authenticates the server. Key agreement: sets up shared secrets. Symmetric cipher: protects the data.
In transport encryption such as TLS, authentication identifies the server through its certificate and proof that it holds the matching private key, key agreement gives both sides shared secret material without sending it, and symmetric encryption protects what is exchanged using keys derived from that material. Each mechanism does one job, and the certificate’s key is not used to encrypt the data.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: The server holds the private key for a certificate valid for that name
In HTTPS, authentication identifies the server through its certificate and proof that it holds the matching private key. That tells the visitor the connection reaches a server entitled to that name. It is not a judgement of the owner’s honesty or of the site’s content, and in ordinary HTTPS it is the server, not the visitor, that is authenticated.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: It is fast enough to protect large amounts of data as they flow
Symmetric encryption is fast enough for bulk data, and it protects what is exchanged using keys derived from the shared secret material. It does not authenticate the server, which is the certificate’s job, and it depends on the key agreement having produced a shared secret first. Decrypting sessions later is what forward secrecy is designed to prevent.
Revision sources: Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: True
True. Each side generates a temporary key pair, exchanges the public halves and derives the same shared secret, and the secret itself is never transmitted. An eavesdropper sees only the public halves, which are not enough to compute the secret.
Revision sources: Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: It is generated for one session and discarded afterwards
In an ephemeral key agreement such as ECDHE, each side generates a temporary key pair for one session. A key in a certificate is long-term by comparison, and splitting or escrowing a key are ways of keeping it available, which is the opposite of discarding it.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: Nothing more: the stolen key was not used to derive Monday’s session keys
Forward secrecy, also called perfect forward secrecy, means later compromise of a long-term private key does not expose the session keys of earlier recorded sessions, provided ephemeral key exchange was used and the temporary keys were discarded. The long-term key only authenticated the server on Monday. A certificate holds a public key and no session keys, and a recording cannot be turned into a new session.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: False
False. Forward secrecy depends on ephemeral key exchange and on the temporary keys and session keys being discarded after use. It comes from how the session keys are established and handled, not from the certificate, which only authenticates the server.
Revision sources: Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Show answer
Answer: Impersonating the server in new connections until its certificate is replaced
Forward secrecy protects earlier recorded sessions, but it does not protect future sessions against an attacker who can now impersonate the server. The stolen key lets the attacker pass as the server until the certificate is revoked and replaced. Discarded temporary keys cannot be recovered from a long-term key, and sessions that have finished cannot be changed.
Revision sources: Transport Encryption, Key Agreement and Forward Secrecy (Supplementary Study Guide explanation)
Study and revision
Practise through the Cryptography & Data Protection topic. Questions cover the three jobs in a TLS connection, what the certificate check establishes, why bulk data uses symmetric encryption, ephemeral keys, how the shared secret is derived, and what forward secrecy does and does not protect; four flashcards recall the main points. Most are learning-only. The questions that have been verified against CompTIA Security+ SY0-701 objective 1.4 are also in the Security+ practice track; that does not mean the lesson covers the whole of an objective, and the lesson does not establish practical experience.
Stage: Consolidate
What to remember
- TLS protects data in transit; HTTPS is HTTP inside TLS, and only TLS 1.2 and 1.3 are in use.
- A TLS connection does three jobs: authenticate the server, agree keys, then encrypt symmetrically.
- Diffie-Hellman agrees a secret in public; ECDHE makes the keys ephemeral.
- Forward secrecy: stealing a long-term key does not expose past sessions, if the keys were ephemeral and discarded.
- It does not protect future connections, data at the ends, or a server already compromised.
Key terms
- Transport encryption
Encryption that protects data while it travels between two endpoints, so that anyone in between can neither read it nor change it unnoticed.
- TLS (Transport Layer Security)
A protocol that protects data in transit with encryption for confidentiality and with integrity protection, and authenticates the server when certificate validation succeeds. HTTPS uses it to secure web traffic.
- Key exchange
Any method by which two parties come to share a secret key over a network that others can observe.
- Ephemeral key
A temporary key generated for one connection and discarded when it ends.
- Session key
A symmetric key used to protect one connection or one exchange of data, and then discarded.
- Forward secrecy (PFS)
The property that later compromise of a long-term private key does not expose the session keys of earlier connections.
Common misunderstandings
In modern TLS the certificate’s key only signs the handshake. The data is encrypted with symmetric keys derived from an ephemeral key agreement.
Only if the connections lacked forward secrecy. With ephemeral key agreement, past connections stay protected.
It protects past connections. After a key theft, the attacker can impersonate the server until the certificate is replaced.
HTTPS means the connection is private and the server holds the key for that name. It says nothing about the site’s intentions.
Further reading
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3: the standard. Section 2 gives the handshake overview, and Appendix E.1 discusses forward secrecy.
- NCSC: Using TLS to protect data: recommended versions, key exchange and certificates.
- HTTPS: TCP, TLS and web communication: the same connection seen from the network side.
- CompTIA Security+ SY0-701 exam objectives (PDF): objective 1.4.
Lesson sources and acknowledgements
Sources and scope
- Covered in Session 9 (see the Session 9 Learning Log): transport encryption and TLS, HTTPS and certificate authentication; and key agreement and ECDHE, ephemeral keys and perfect forward secrecy.
- Accuracy qualifications: forward secrecy depends on ephemeral key exchange and on how keys are handled; it protects earlier connections and not later ones; a secure connection authenticates the server and is not a judgement of the website.
- Independently checked: the handshake, the removal of RSA key transport and the forward-secrecy properties against RFC 8446 (TLS 1.3); protocol versions and recommended key exchange against the NCSC’s TLS guidance; and the Security+ wording against the published SY0-701 objectives. These are external references, not course evidence.
- Supplementary explanation: every definition, the telephone and paint analogies and their limits, the telephone analogy continued for ephemeral keys and forward secrecy, the seven handshake steps, mutual TLS, key transport against key agreement, the Monday and Friday comparison, the conditions and limits of forward secrecy, resumption and the misunderstandings. These were developed afterwards and are my explanations, not the tutor’s words. The diagrams are original.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the tapped-line opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. Alice, Bob, Mallory and the bank are fictional. I have not captured or analysed a TLS handshake, or configured a server’s TLS settings, as part of this lesson.
The standard symmetric block cipher, with 128-, 192- or 256-bit keys.
Cryptography that uses a mathematically related pair of keys: a public key that can be shared and a private key that is kept secret.
Establishing or verifying a claimed identity, for example when a user signs in.
An algorithm that turns plaintext into ciphertext, and back again, under the control of a key.
A named set of algorithms that a TLS connection will use, covering key exchange, authentication, encryption and integrity.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
The practice of protecting information by transforming it, so that only the intended parties can read it or trust it.
Data that is moving across a network.
A method by which two parties each contribute a value and both compute the same shared secret, without the secret itself being sent.
A document, signed by a certificate authority, that binds a public key to the identity of its subject. The standard format is X.509.
A key agreement in which each side generates a temporary elliptic-curve key pair, exchanges the public halves and derives the same shared secret.
Transforming data with a cipher and a key so that it cannot be read without the right key. Decryption reverses it.
A device at the end of a network connection that people or programs actually use: a laptop, desktop computer, phone, tablet or server.
A temporary key generated for one connection and discarded when it ends.
The property that later compromise of a long-term private key does not expose the session keys of earlier connections.
The set of rules a web browser and a website use to ask for and send pages. A browser sends a request; the website sends a response.
HTTP protected by TLS. HTTP/1.1 and HTTP/2 commonly use TCP port 443, while HTTP/3 uses QUIC over UDP port 443.
Any method by which two parties come to share a secret key over a network that others can observe.
The two related keys used in asymmetric cryptography: a public key and a private key. What one does, only the other can undo.
A key that stays the same for months or years, such as the private key belonging to a certificate. Its opposite is an ephemeral key.
Malicious software designed to disrupt, damage or gain unauthorised access to devices, networks or data. Ransomware is one type.
TLS in which both ends prove their identity with certificates, not only the server.
The half of a key pair that its owner keeps secret. It decrypts data sent to the owner and creates the owner’s signatures.
An agreed set of rules for how data is formatted, transmitted and interpreted so that devices can communicate.
An asymmetric algorithm whose security rests on the difficulty of factoring the product of two large prime numbers.
A symmetric key used to protect one connection or one exchange of data, and then discarded.
The obsolete predecessor of TLS. Every version of SSL is insecure and should not be used.
Encryption in which the same secret key encrypts and decrypts. It is fast and suits large amounts of data.
A protocol that protects data in transit with encryption for confidentiality and with integrity protection, and authenticates the server when certificate validation succeeds. HTTPS uses it to secure web traffic.
The opening exchange of a TLS connection, in which the two sides agree keys and the server proves its identity before any application data is sent.
Encryption that protects data while it travels between two endpoints, so that anyone in between can neither read it nor change it unnoticed.
A protected connection across a network that is not trusted, usually the internet. Organisations use one to let a computer outside the building reach the internal network as if it were inside.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.