Certificates, PKI, and SSL/TLS for infrastructure builders and operators
Download as PPTX, PDF1 like422 views
This document discusses the importance of managing infrastructure components that rely on TLS and certificates for transport security, covering applied cryptography basics, public key infrastructures, and SSL/TLS configurations. It emphasizes the practical security implications of key management, certificate lifecycles, and the challenges of key distribution and trust. Additionally, it outlines recommendations for proper certificate issuance, management, and configuration to enhance security against threats such as man-in-the-middle attacks.
Certificates, PKI, and SSL/TLS for infrastructure builders and operators
- 1. Certificates, Public Key Infrastructures, and SSL/TLS for infrastructure builders and operators David Ochel, August 2019 2019-08-31-00 Unless otherwise noted, clip art is from pixabay.com and subject to PixaBay’s license (https://pixabay.com/service/terms/#license). All remaining content that has not otherwise been attributed is released into the public domain under the CC0 1.0 – https://creativecommons.org/publicdomain/zero/1.0/.
- 2. Agenda & Outline Objective: Align on the practical and security implications of managing infrastructure components that rely on TLS and (server) certificates for enabling transport security. • Applied crypto basics – 20’ • Symmetric & asymmetric encryption • Hashes and digital signatures • What makes crypto hard • Public Key Infrastructures – 40’ • Certificates & CAs – and how they are used in TLS • Lifecycle considerations for server keys and certificates • SSL/TLS – Configuration Gotchas – 30‘
- 3. Thwarting the “Man in the Middle” PLAIN TEXT PLAIN TEXTtPLAIN TEXT • Communication over (public) networks is not confidential, by design • Emails, web traffic, secrets, etc. can be intercepted and/or manipulated • Originators of content can be impersonated • Unless it is protected and authenticated, typically using encryption • TLS (as in, HTTPS, FTPS) • IPsec, OpenVPN, MACsec, … (or application-specific, like PGP and SSH)
- 4. Crypto basics (because it’s the foundation for everything)
- 5. 01101001 11100011 10001111 10010101 10110100 00000110 11010100 10010011 11001111 10110000 00001010 11110000 10100011 00100001 10001011 01001111 Secret Key – Symmetric Encryption • One key, multiple copies • Good: fast, straightforward • Bad: key distribution (requires out-of-band, can’t control copies) • Examples: AES, Blowfish – e.g., 256 bit key length PLAIN TEXT PLAIN TEXT CIPHER TEXT the key (it’s actually a random string of bits)
- 6. Public and private keys – Asymmetric Encryption • Mutually complementary pair of keys • Good: distribution (private key stays with owner, copies of the matching public key can be distributed freely); digital signatures • Bad: high CPU need, based on (theoretically solvable) math problems • Examples: RSA, Diffie Hellman – e.g., 2048 bit key length PLAIN TEXT PLAIN TEXT CIPHER TEXT private key public key
- 7. Cryptographic Hashes • Maps a message into a fixed-size digest (“hash”) • Deterministic • Collision-resistant • Non-reversible (one way), cannot compute message from hash • Examples: bcrypt, SHA-2 PLAIN TEXT hash PLAIN TEXT hash PLAIN TEXT PLAIN TEXT hash From https://en.wikipedia.org/wiki/File:Cryptographic_Hash_Function.svg
- 8. Digital Signatures • Originator encrypts hash with private key (“digital signature”) • Recipient decrypts hash with originator’s public key, and computes its own hash over the message • If the two hashes match, the message must have been signed by somebody in possession of the private key PLAIN TEXT hash PLAIN TEXT PLAIN TEXT PLAIN TEXT hash signature signature signature hash
- 9. Typical Crypto Limitations • Implementing crypto algorithms is hard Use approved libraries/products • Key material “weakens” (risk of eventual compromise increases) over time Rotate keys on defined frequencies Use recommended key lengths and algorithms • Protecting access to secret and private keys is hard Re-key if somebody with access to a secret key leaves organization Keep keys in as few locations as possible, defend them thoroughly Don’t re-use the same key for different purposes or in different trust settings • Distributing public keys in a trustworthy manner is still hard Use public key infrastructures!
- 10. Public Key Infrastructures (or, how do I know that Alice’s public key that I grabbed from the web is the one that in fact matches Alice’s private key, and not Chuck’s, who is pretending to be Alice?)
- 11. Remember the Man in the Middle? • We want to distribute public keys freely, over networks • But is Alice in fact the one that possesses the private key to the public key that has her name on it? • Can I trust that digital signatures signed with the corresponding private key are in fact Alice’s signatures, and not somebody who’s pretending to be her? • Can messages I encrypt with this key only be decrypted by her? PLAIN TEXT PLAIN TEXT A A C CA C A C
- 12. Attesting to a distributed key’s authenticity • Crowd-sourced web of trust (e.g., PGP) • Users attest to the authenticity of public keys by signing each other’s public keys (after having established that they have the same key in front of them) • Key Signing Party, anyone? • Trusted Third Parties • Certificate authorities establish a hierarchical chain of trust into public keys • All users trust the same CA, thus any public key signed by the CA is extended trust (without the need for a secure channel to obtain individual public keys) https://imgs.xkcd.com/comics/responsible_behavior.png
- 13. Certificates! Cert Signing Request Name: Alice Address: [email protected] Public key: Certificate Authority PLAIN TEXT PLAIN TEXT CIPHER TEXT A signature A A A A A CERTIFICATE Expiration: … Name: Alice Address: … Public key: CA signature A CA CA A CA
- 14. Transport Layer Security – crypto (simplified) CERTIFICATE Expiration: … Name: Company A Address: … Public key: CA signature A CERTIFICATE Expiration: … Name: Company A Address: … Public key: CA signature A 1: Client requests server certificate, validates it against CA cert 2: Client generates symmetric session key* A 3: Client & server exchange traffic encrypted with the session key ENCRYPTED PAYLOAD (e.g., HTML) *This is a much simplified view of how key generation with RSA works. Authentication of the server with RSA is implicit. DH/ECDH works differently. AA
- 15. Lifecycle of a server certificate 1. Public/private keypair management 2. Certificate request 3. Certificate issuance 4. Certificate use and revocation 5. Certificate consumption by clients
- 16. (1) Managing server public/private keys • Private keys should never leave the server (need to keep confidential) • Use Certificate Signing Requests instead of letting the CA generate the server’s public/private key pair • Do not share private keys across trust domains / between different services (lest compromise of the weakest link will compromise them all) • Beware of aging keys • Limit validity of certificates to an appropriate number of days or years • Generate new keys when “renewing” a cert instead of getting a new cert for the same old key • Consider new keys & certs if an operator with access leaves the organization • Self-signed certificates
- 17. (2) Requesting a certificate • Prefer FQDN subject names over wildcards • Wild cards encourage proliferation of the same keys across different services / trust domains • Consider multiple Subject Alternative Names instead • Choose your CA wisely • Consider reputation of different CAs, even though browsers might trust them all • Consider validation and support needs (e.g., Let’s Encrypt – domain validation only) • Identity Verification • Registration Authorities – (in-person) offices of the CA for high-trust situations (e.g., validating somebody’s passport in person - not common in TLS server scenarios • Domain Validation – does the requesting organization control the domain that the cert is for? • Organization Validation – can the requesting organization prove its name/DBA/address as listed in the CSR? • Extended Validation – subject name matches organization’s incorporation doc • Certificate Signing Request (CSR) – standardized format to request a certificate • Does not include the user’s|server’s private key, but is signed by its private key to demonstrate possession of it
- 18. (3) Issuing a certificate • Do not use self-signed certs • Teaching users to click through warnings in their browsers desensitizes them against actual threats • Internal CAs for internal services are OK *if* they are managed properly • Mitigate risk of CA compromise • The root CA should be highly protected, offline, and only used to issue certs to certificate-issuing CAs lower down in the hierarchy • Consider using different cert-issuing CAs for different cert purposes / environments • Automation is OK… • ...if cert requests are properly authenticated & authorized
- 19. (4) Hosting and revoking certificates • Serve certificate chains with your certificate • Clients may break if intermediate certs are not served by your server, since they may only have the root CA certs in their trust stores • Monitor for certificate expiration • Revoke certificates for compromised or retired keys
- 20. Certificates – the devil is in the details • Expiration Date • Purpose (domain validation, cert issuer) • Subject Alternative Names • Wildcard Certs vs. FQDN • Key Usage
- 21. Other uses of certificates & trust chains • Code signing • Windows updates • Europe: electronic signatures • Device authentication • User authentication • S/MIME • DNSSEC • PGP Web of Trust
- 22. Using certificates for authentication • Authentication factors: what you have; what you know; what you are • Certs (i.e., private keys!) are “what you know” • Same issue as passwords – can be cloned onto multiple devices, picked up by malware, … • Can be used to implement “what you have” if protected from cloning • E.g., on a smart card, HSM, secure enclave • Do certs authenticate users or devices? • Certs don’t authenticate anything, it’s the private key that corresponds to the public key in the cert that does the authentication • Arguably, the CA’s digital signature on the certificate provides for authenticity of the certificate’s content • Do keys (SSH keys, keys related to device certs, …) authenticate users or devices? • It depends – on usage, protection of the keys, context, …
- 23. SSL/TLS – Configuration Gotchas
- 24. Transport Layer Security – crypto (simplified) CERTIFICATE Expiration: … Name: Company A Address: … Public key: CA signature A CERTIFICATE Expiration: … Name: Company A Address: … Public key: CA signature A 1: Client requests server certificate, validates it against CA cert 2: Client generates symmetric session key* A 3: Client & server exchange traffic encrypted with the session key ENCRYPTED PAYLOAD (e.g., HTML) *This is a much simplified view of how key generation with RSA works. Authentication of the server with RSA is implicit. DH/ECDH works differently.
- 25. Versions • SSL is outdated and insecure • v2 – 1994 (Netscape Navigator 1.1 ) • v3 – 1995 • TLS • 1.0 – 1999 (RFC 2246), similar to SSLv3 • 1.1 – 2006, uses MD5 and SHA-1 (on it’s way out) • 1.2 – 2008 • 1.3 – 2018
- 26. Cipher Suites • Determine the mix and match of crypto algorithms a client and server can agree on for: • Authentication • Key exchange • Encryption algorithm & key sizes • Etc. Disable weak cipher suites Prefer them in order of strength
- 27. Other Tidbits • Perfect Forward Secrecy • Session keys don’t depend on protection by the server’s private key • A result of using DH/ECDH (instead of RSA) for key agreement • If RSA is not supported by a web server, MITM traffic inspection will break ;-) • Various other, security-relevant configuration settings. For example: • Prevent protocol version downgrade attacks (TLS_FALLBACK_SCSV) • Reject insecure renegotiation (support the Renegotiation Indication extension, RFC 5746) • Tell clients to always use TLS (Strict Transport Security (HSTS)) • Only use the TLS NULL compression method • Support OCSP stapling (RFC 6066) • Support session resumption
- 28. Potential Client Issues • Mismatch of supported protocol versions • Mismatch of supported ciphersuites • Certificate Pinning • Will interfere with MITM attempts to de- and re-encrypt traffic (e.g., for inspection)
- 29. Fun Tools • Dealing with certs • OpenSSL • Checking TLS configs • sslyze • www.ssllabs.com • observatory.mozilla.org • References • https://www.ssllabs.com/projects/documentation/
Editor's Notes
- #4: https://pixabay.com/vectors/robber-burglar-bandit-stripes-303444/