TLS, certificates and digital signatures · TLS、证书与数字签名
| English | 中文 | Pinyin · 拼音 |
|---|---|---|
| TLS/ˌtiː el ˈes/ | 传输层安全 | chuán shū céng ān quán |
| digital certificate/ˈdɪdʒɪtl səˈtɪfɪkət/ | 数字证书 | shù zì zhèng shū |
| digital signature/ˈdɪdʒɪtl ˈsɪɡnɪtʃə/ | 数字签名 | shù zì qiān míng |
| authenticity/ɔːθənˈtɪsɪti/ | 真实性 | zhēn shí xìng |
| integrity/ɪnˈteɡrɪti/ | 完整性 | wán zhěng xìng |
| Certificate Authority/səˈtɪfɪkət əˈθɒrɪti/ | 证书颁发机构 | zhèng shū bān fā jī gòu |
Encryption alone would not have helped
- Suppose your connection to your bank is perfectly encrypted, and suppose an attacker sits between you and the bank, holding an encrypted connection to each side.
- Every byte is encrypted. Every byte is also read, and changed, by the attacker. Encryption did exactly what it promised and protected nothing that mattered.
- What was missing was not secrecy but identity: proof that the public key you encrypted to belongs to the bank and not to whoever answered.
- This lesson is the three things that close that gap: TLS 传输层安全 for the connection, a digital certificate 数字证书 for identity, and a digital signature 数字签名 for authenticity and integrity.
What TLS provides
- TLS, Transport Layer Security, the successor to SSL, is the protocol that secures data in transit. It provides three things together, and the exam wants all three named.
- Encryption, so an eavesdropper reads only ciphertext. Authentication, so the client knows which server it is talking to. Integrity 完整性, so any tampering in transit is detected.
- It is what the padlock in a browser means, and it is used by HTTPS, secure email, VPNs and online banking.
TLS provides which combination of protections for data in transit?
TLS encrypts the traffic, authenticates the server (via a certificate) and detects tampering (integrity).
Which protections does TLS provide for data in transit? Select all · 所有 that apply.
Delivery is TCP's job. TLS adds confidentiality, identity and tamper-detection on top of it.
The handshake
- The client proposes the cipher suites it supports. The server replies with its choice and its digital certificate, which contains its public key.
- The client checks the certificate. If it is satisfied, the two sides use asymmetric encryption to agree a fresh session key.
- All subsequent traffic is encrypted symmetrically with that session key: fast, and freshly keyed for this one conversation.
- The certificate check is the step that defeats the attack in the hook. Without it, the client would happily agree a session key with the attacker.
Asymmetric to agree the key, symmetric for everything after
The TLS handshake · TLS 握手
Step through what happens before a padlock appears. The slow public-key crypto is used only to agree a shared key; the actual page then travels under fast symmetric encryption.
Put the steps of the TLS handshake in order.
The certificate check comes before the key agreement, which is what stops a man-in-the-middle from agreeing a key with the client.
Digital certificates
- A digital certificate binds an identity, a domain or organisation, to a public key, and is signed by a trusted Certificate Authority 证书颁发机构 (CA).
- It contains the subject whose identity it certifies, the subject's public key, the issuer, a validity period, and the CA's digital signature over all of it.
- The signature is what makes it trustworthy: anyone can create a document claiming to be a bank, but only the CA can produce a signature that verifies with the CA's public key.
A trusted third party vouches that this key belongs to this name
Match each security mechanism to what it does.
A certificate vouches for a public key; a signature uses the private key to prove who sent it and that nothing changed.
Worked example: how a client verifies a certificate
- Describe the checks a browser makes on a website's digital certificate. [4]
- It checks the certificate is within its validity period, neither expired nor not yet valid.
- It checks the subject name matches the domain the user asked for, which is the check that catches an attacker presenting a genuine certificate for a different site.
- It verifies the CA's signature on the certificate using the CA's public key, proving the certificate has not been altered.
- It follows the chain to a root CA the browser already trusts. If any check fails, the browser shows the "connection is not private" warning.
When verifying a certificate, the client checks that it is:
The browser checks validity dates, that the subject name matches the site, and the CA signature up to a trusted root.
What makes a digital certificate trustworthy?
Anyone can write a document claiming to be a bank and put a key in it. Only the CA can produce a signature that verifies with the CA's public key.
Digital signatures
- A digital signature proves authenticity 真实性, who sent the message, and integrity, that it was not changed. It does not encrypt the message or make it secret.
- To sign: the sender puts the message through a hash function to produce a digest, then encrypts that digest with their own private key. The encrypted digest is the signature, and it travels with the message.
- To verify: the receiver decrypts the signature with the sender's public key to recover the digest, hashes the received message themselves, and compares the two.
- If they match, only the holder of the private key could have made the signature (authenticity) and the message cannot have changed (integrity), since any change would produce a different hash.
Sign the digest with the private key, check it with the public key
To create a digital signature, the sender:
Signing = hash the message, then encrypt the digest with the private key; the receiver verifies with the public key.
A digital signature proves authenticity and integrity (who signed it, and that nothing changed) but does NOT hide the message — you must encrypt it as well for confidentiality.
Signing and encrypting are separate goals: the signature proves origin/integrity; encryption keeps the contents secret.
To sign a message, the sender encrypts its digest with their own ____ key.
The receiver then decrypts it with the sender's public key. Only the private-key holder could have produced a signature that opens that way.
Worked example: why the keys are the other way round
- In confidential messaging the sender uses the recipient's public key. In signing, the sender uses their own private key. Explain why.
- For confidentiality you want only one person to be able to read it, so you lock with the key everyone has and it opens only with the one key nobody else has.
- For a signature you want everyone to be able to check it and only you to be able to produce it, so you lock with the key only you have and it opens with the key everyone has.
- The direction of the key pair follows from what you are trying to prove. This is the single most tested idea in the topic.
Encrypting a connection is by itself enough to stop a man-in-the-middle attack.
Encryption protects a channel to whoever is at the far end. The certificate proves who that is, which is why verification is the load-bearing step.
Acquiring a certificate
- The server owner generates a key pair and sends the public key and identity details to a Certificate Authority. The private key stays with the owner. The CA checks control of the domain or the identity required by the certificate type.
- The CA signs a certificate binding that identity to the public key, using the CA's private key, and returns it for installation. A certificate is public evidence about a key, not a container for the owner's secret key.
Which items belong in a certificate request to the CA? Select all that apply.
The CA checks the claimed identity and binds it to the public key. The applicant private key stays secret.
Order the steps for acquiring a digital certificate.
The identity is checked before the CA signs the binding. The server presents the certificate to clients.
Worked example: whose key signs what?
- A software publisher signs a download with the publisher's private key. The receiver obtains the publisher's public key from a valid certificate and uses it to verify the download signature.
- The CA's private key signs the certificate; the publisher's private key signs the download. A valid certificate establishes whose public key to trust. It does not itself sign the program or prove the program is harmless.
Match each operation to the correct key.
The CA vouches for the identity-to-key binding. The publisher signs its own content; the receiver checks it with the matching public key.
Marks that slip away
- TLS provides encryption, authentication and integrity. Naming only encryption loses two-thirds of the answer.
- A signature encrypts the hash of the message with the sender's private key, not the message itself, and it does not make the message secret.
- Verifying a certificate means the dates, the name matching the domain, the CA's signature and the chain to a trusted root. The name check is the one candidates forget.
- The certificate is what stops a man-in-the-middle. Encryption on its own does not: it protects a channel to whoever is at the other end.
You've got it
- TLS gives encryption, authentication and integrity; its handshake presents a certificate, then agrees a session key for fast symmetric encryption
- a digital certificate binds an identity to a public key and is signed by a Certificate Authority; it carries the subject, its public key, the issuer, the validity period and the CA's signature
- verify a certificate by the dates, the name matching the domain, the CA's signature and the chain to a trusted root
- a digital signature is the message's hash encrypted with the sender's private key, checked with the sender's public key: it proves authenticity and integrity, not confidentiality