ACME and the Let's Encrypt! initiative - CrikeyCon 2015

Video: https://www.youtube.com/watch?v=5S8ms93mVC4

Transcript

1. ACME and the Let’s Encrypt! initiative Fraser Tweedale @hackuador February 21, 2015
2. Introduction
3. About me Developer at Red Hat Dogtag Certificate System and FreeIPA IdM Mostly Python and Java at work Mostly Haskell for other projects
4. This talk Deploying TLS (today) Introduction to Let’s Encrypt! initiative and ACME protocol Demo Discussion; future directions
5. Deploying TLS
6. Deploying TLS 0. Pay $$$ to a certificate authority 1. Prove control of domain (ad-hoc process) 2. Certificate request (various protocols) 3. Configure network server (non-trivial)
7. Domain validation
8. Domain validation
9. Certificate request openssl req -nodes -newkey rsa:2048 -sha1 -keyout myserver.key -out server.csr LOL WAT Make sure you put the right info in the right fields. . . “Open the ‘server.csr’ file with a text-editor and copy and paste the contents into the enrollment form when requested.”
10. Server configuration Certificate chain configuration > < Default TLS config suboptimal or outright insecure Out of date info on web ssl ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384 LOL WAT
12. Let’s Encrypt! Initiative to encrypt the whole web EFF, Mozilla, Akamai, Cisco, IdenTrust Free certificate authority ACME protocol
13. Let’s Encrypt! non-goals Not a replacement for X.509 PKI or certificate cartel Not intended for automating / replacing higher forms of validation Not intended to be useful in private / institutional uses of X.509 PKI
14. ACME protocol Automated Certificate Management Environment Domain validation challenges and responses Certificate request, renewal, revocation ACME client configures web server
15. ACME overview Generate account key pair Satisfy DV challenge(s) to authorize account key for a domain Issue and revoke certificates using authorised account key REST-ish API Client request objects signed with account key (JWS)
16. ACME key registration POST /new-reg HTTP/1.1 { "contact": [ "mailto:cert-admin@example.com", ... ] } /* Signed as JWS by account key */ contact URIs used for recovery and/or notifications Location header in response to allow client to POST updated contact details
17. ACME key authorisation POST /new-authz HTTP/1.1 { "identifier": { "type": "dns", "value": "example.org" } } /* Signed as JWS by account key */
18. ACME key authorisation { "status": "pending", "identifier": { /* as above */ }, "key": { /* JWK from JWS header */ }, "challenges": [ { "type": "simpleHttps", "uri": "/authz/foo/0", "token": "IlirfxKKXAsHtmzK29Pj8A" }, { "type": "dns", "uri": "/authz/foo/1", "token": "IlirfxKKXAsHtmzK29Pj8A" }, { "type": "recoveryToken", "uri": "/authz/foo/2" } }, "combinations": [ [0,2], [1,2] ] }
19. ACME domain validation challenges simpleHttps: deploy HTTPS resource dvsni: sign custom certificate for use with SNI dns: provision DNS TXT record proofOfPossession: prove control of already-trusted key recoveryContact: verify previously-authorised client using contact details recoveryToken: verify previously-authorised client by previously issued token
20. ACME DV: simpleHttps { "type": "simpleHttps", "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ+PCt92wr+oA" } { "type": "simpleHttps", "path": "6tbIMBC5Anhl5bOlWT5ZFA" } Provision a file with content of token ASCII, >= 128 bits of entropy Host at .well-known/acme-challenge/<path> text/plain Self-signed certificate (CN is hostname being validated)
21. ACME DV: dvsni { "type": "dvsni", "r": "Tyq0La3slT7tqQ0wlOiXnCY2vyez7Zo5blgPJ1xt5xI", "nonce": "a82d5ff8ef740d12881f6d3c2277ab2e" } { "type": "dvsni", "s": "9dbjsl3gTAtOnEtKFEmhS6Mj-ajNjDcOmRkp3Lfzm3c" } r, s: random 32-byte octet strings, base64-encoded nonce: random 16-byte octet string, hex-encoded Provision host on server Hostname: <nonce>.acme.invalid Self-signed certificate; subjectAltName with two dNSNames domain being validated <hex(sha256(r || s))>.acme.invalid
22. ACME DV: dns { "type": "dns", "token": "17817c66b60ce2e4012dfad92657527a" } { "type": "dns" } token: string; SHOULD be random with >= 128 bits entropy Provision TXT record for domain being validated acme-challenge.<domain>. IN TXT "<token>"
23. ACME certificate issuance POST /new-cert HTTP/1.1 { "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", "authorizations": [ "/authz/foo/0", ... ] } /* Signed as JWS by account key */ CSR is PKCS #10 DER, base64-encoded Can request certificate for multiple validated identifiers (subjectAltName extensionRequest attributes) If successful. . . Respond 201 MUST include Location header, e.g. /cert/<serial> MAY include certificate (application/pkix-cert)
24. ACME certificate revocation POST /cert/<serial> HTTP/1.1 { "revoke": "now", "authorizations": [ ... ] } /* Signed as JWS by account key */ revoke: RFC 3339 date, or literal "now" Server MAY instead accept signature by certificate key
25. Demo
26. Let’s Encrypt! Status Client and server under heavy development ACME protocol still evolving Nginx configurator in the works Mid-2015 launch
27. Protocol evolution Original protocol was RPC-based Moving to REST-ish interface Does this change security characteristics? More HTTP resources means more places to check auth[nz] Switch from custom signature construction to JWS
28. Future
29. Adoption I would like to see: Support for all popular HTTP servers Support from multiple public CAs (even paid ones) Uptake by PaaS and IaaS providers / software
30. Other validation challenges DNSSEC Email (for MTAs?) WHOIS
31. Other applications Validation for other kinds of identifiers? MUAs; validate email address and acquire S/MIME certificate
32. Side-effects Better server configuration mechanisms / APIs (yay!) CA cartel probably won’t like it! Countermeasures (EV, all over again?) Attacks (against Let’s Encrypt! CA or ACME protocol)
33. Get involved https://letsencrypt.org/ https://github.com/letsencrypt/ #letsencrypt on Freenode https://www.ietf.org/mailman/listinfo/acme client-dev+subscribe@letsencrypt.org ca-dev+subscribe@letsencrypt.org
34. Fin Copyright 2015 Fraser Tweedale This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. Slides https://github.com/frasertweedale/talks/ Email frase@frase.id.au Twitter @hackuador