To SSL And Back...

SSL/TLS talk from the Philly 'Burbs May 9th Meetup

Transcript

1. To SSL And Back… An Unexpected a547679dc740320636e35774026b7666%!@
2. Doug Stewart aka @zamoose
3. I work for 10up.* *I can neither confirm, nor deny whether this is a contractual obligation for me to mention, even in casual conversation. We’re usually hiring.** **This, also, may well be contractual and… wait, did you hear that? Hide! They’re coming for us!
4. But first… (well, actually…)
5. SSL •Secure •Sockets •Layer
6. TLS •Transport •Layer •Security
7. TLS is the official name of the successor to SSL.
8. Nobody seems to call it “TLS” except for geeks.
9. Like Kleenex, Band-Aid, or Xerox, that train has sailed. Give it up, Nelson.
10. So what is/are it/they?
11. https://en.wikipedia.org/wiki/Transport_Layer_Security SSL and TLS are “[…]cryptographic protocols that provide communications security over a computer network.”
12. ?
13. Enigma machine https://en.wikipedia.org/wiki/Enigma_machine
14. Why use TLS? • Keeps your in-flight* information secure from third parties** • That’s pretty much it.
15. * • The server at the other end has to do something to secure your data once it’s there. It’s not a guarantee of database- or file-level protection.
16. ** • Domestic gov’t intelligence operatives • Foreign gov’t intelligence operatives • Crackers/hackers/thieves • Nosy neighbors • Curious classmates • etc.
17. How does it work? The Handshake
18. Basic TLS handshake • A typical connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate: • Negotiation phase: • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. • The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.0 should not be selected. • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[257] • The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.[1] • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate. • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function. • The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record- level protocol with content type of 20. • Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages. • The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down. • Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)." • The server sends its authenticated and encrypted Finished message. • The client performs the same decryption and verification. • Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.
20. The Handshake • Client: (web browser, mobile app, DNS client, etc.) connects to server and says “Hi, I’d like to talk securely with you. Here’s the versions of TLS I support. Over!” • Server: “Hello! I support that version of TLS (plus a bunch more). Here’s a random number and a recipe for how to talk further. Also, here’s a big Secret Codebook you can use to make up some awesome secret phrases. Over!”
21. The Handshake (cont.) • Client: (furiously tries to remember how to do trigonometry and algebra, does a bunch of calculations) “Okay, here’s a secret password I made using your awesome codebook. Over!” • Server: “Okay, great. Now take that passphrase and that number I sent you and we’ll both make an even more super-secret…er password that only we’ll know. Over!”
22. The Handshake (cont.) • Client: (sucks on pencil eraser, creases brow) “Okay, great. I used our passphrase and encrypted all the stuff we just talked about. See if it all matches up and whether I did it correctly. Oh, and if you say ‘yes’, everything else I say to you will be in that secret code. Over!” • Server: (reads back transcripts like a court stenographer, mouthing words slightly) “Looks good! I agree, let’s talk in code from here on out. Over!”
23. (Conversation continues but looks like encrypted garbage characters incomprehensible to the rest of the world, unsolvable until the heat death of the universe. Harriet the Spy approves.)
24. Sounds great! (Starts with an earthquake/Birds and snakes/An airplane/Lenny Bruce is not afraid) [Sorry -ed.]
25. We’ve shaken hands. Now what?
26. Exchange Information • Personally-identifiable information (PII) • Social Security numbers • Contact information • Birth dates • Benefits registration • PCI (credit card company standard) compliance • Credit card numbers
27. Exchange Information (cont.) • File taxes • Renew your license with the DMV • Have a trusted arbiter verify your site is what it says it is so visitors will trust your site • Secret governmental information absconders/heroes/traitors[*] wish to send highly sensitive (explosive, even) information to friendly media sources and leave few tracks before they’re able to defect to an enemy of the state
28. But that’s not all!
29. Other Advantages • HTTP/2 Support* • Data compression of HTTP headers • HTTP/2 Server Push. • Pipelining of requests • Fixing the head-of-line blocking problem in HTTP 1.x • Multiplexing multiple requests over a single TCP connection
30. Other Advantages (cont.) • HSTS • Google ranking boost • Nifty green badges
31. Site Verification
32. Go from this…
33. To this.
34. Red badge != courage Well, I guess you have to be courageous to throw caution to the wind. Don’t say I didn’t warn you.
35. Getting Your TLS On
36. Certificate Process 1. Generate a private key • You never, ever, ever, (EVER) share this with anyone. Full-stop. 2. Generate certificate-signing request (CSR) 3. Send CSR to certificate authority (CA) 4. CA uses CSR to generate certificate 5. CA returns cert to you 6. Install cert and key on web server[s], tell web server daemon where to find them, and restart
37. Certificate Authorities • Generally well-trusted third parties responsible for verifying whether information you’ve provided is accurate • Implicitly and explicitly trusted by all major operating systems, devices, and web browsers
38. Certificate Authorities (cont.) • During The Handshake, your OS and/or browser will take the certificate offered by web server and verify it against the trusted CA certificate chains • If everything matches up, your computer gives a big :thumbsup: • If something doesn’t compute, you get a red demerit badge
39. Traditional method
40. • Usually expensive • Web/phone-based confirmation process • Can take a while to validate • (Sometimes) insurance • Extended validation
41. Better Method
42. • CLI-driven • Cheap • Automate-able • CLI is life! CLI is power!
43. New-fangled, free, mostly-sorta best method
44. • Free • Automate-able • Open • Free! • Kinda-sorta a pain in the butt right now • Max cert age: 90 days • Web-based verification only real option currently • Big pain behind load balancers
45. Other Alternatives
46. • Buy a certificate through your web host • Use Akamai or other CDN providers ($$) • Use CloudFlare (free! mostly!)* • Self-signing (remember that red badge?)
47. *I hope you like party lines
48. Q&A
49. Links • https://en.wikipedia.org/wiki/Transport_Layer_Security • https://en.wikipedia.org/wiki/HTTP/2 • https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security • https://webmasters.googleblog.com/2014/08/https-as-ranking- signal.html • https://github.com/certbot/certbot/wiki/Web-Hosting- Supporting-LE • http://wordpress.tv/2016/05/01/zack-tollman-understanding- https-and-tls/
50. Thanks!