Understanding SSL/TLS ece or What is an SSL Certificate and What Does It Do for Me? J.K. Harris Electrical and Computer Engineering Virginia Tech Oct 2008 1/39 Understanding SSL/TLS ece What is It? How Does It Work? Why is It Important? (What does it do?) But, Most Importantly –> Things the average user should know! 2/39 What is It? ece Something about encryption of Web pages https://... The “lock icon” at the bottom of your browser –> Can Safely Type in Your Credit Card Number! (...are you sure its safe?) In short, very few people know what SSL/TLS is! 3/39 How Does It Work? ➢ Based on the RSA algorithm ➢ Is a public key cryptography system ➢ ece It takes a little math to understand this (I'll keep the math to very little!) 4/39 ece How Does It Work? A little math: For properly chosen (e, d, n) –> Functions are inverses of each other! c=m mod n e m=c mod n d Reference: http://en.wikipedia.org/wiki/Rsa I.e., wikipedia “RSA” 5/39 ece How Does It Work? (Some hand waving: e is not critical, almost all RSA use e = 65537) Think: m = message c = cypher (encrypted message) c=m mod n e m=c mod n d We call: n –> the Public key d –> the Private key 6/39 ece How Does It Work? For properly chosen (e, d, n) We call: n –> the Public key c=m mod n e m=c mod n d d –> the Private key –> Given n can not (easily) find d! 7/39 ece Encryption Standard usage: Alice –> Bob ● Bob properly chooses (e, d, n) ● Bob sends public key (n) to Alice (How?) ● Alice encrypts her message (m) ● Alice sends cypher (c) to Bob ● Bob uses his private key (d) to decrypt c=m mod n e m=c mod n d 8/39 ece Encryption Standard usage: c=m mod n e Very Important and Subtle Point: ● Bob sends public key (n) to Alice (How?) m=c mod n d 9/39 ece Digital Signatures Signing Digital Documents: Digital Signatures Bob –> Alice ● Bob properly chooses (e, d, n) ● Bob sends public key (n) to Alice (How?) ● c=m mod n e m=c mod n d Bob encrypts his document (c) using his private key (d) giving cypher (m) ● Bob sends (m) to Alice ● Alice uses Bob's public key (n) to decrypt 10/39 ece Digital Signatures Signing Digital Documents: c=m mod n e Very Important and Subtle Point: ● Bob sends public key (n) to Alice (How?) m=c mod n d 11/39 ece Digital Signatures Signing Digital Documents: c=m mod n e Work equations in “reverse” Alice knows that Bob sent the message because his public key decrypted a message that could only be created using Bob's private key. m=c mod n d (This assumes that Alice somehow has Bob's public key.) 12/39 ece How Does It Work? Points to remember: c=m mod n e Equations in the “forward” direction –> encryption Equations in the “reverse” direction –> message signing (digital signature) m=c mod n d 13/39 ece How Does It Work? Very Important and Subtle Point: ● Bob sends public key (n) to Alice (How?) Why? “Man in the Middle Attack” c=m mod n e m=c mod n d 14/39 Man in the Middle Attack Alice Bob Charlie ● ● ● ● ece Charlie has full control of the “wire” Charlie sends Alice Charlie's Public key in place of Bob's Public key c=m mod n e m=c mod n d Charlie decrypts Alice's message using his own Private key Charlie uses Bob's Public to send him any message he wants 15/39 Man in the Middle Attack Alice ece Bob Charlie Because Alice does not have Bob's public key – Alice has no way of knowing that she is not communicating with Bob – Bob has no way of knowing that the message did not come from Alice – Charlie can do anything he wants c=m mod n e m=c mod n d 16/39 ece Man in the Middle Alice Bob Charlie How to get Bob's public key safely to Alice? c=m mod n e m=c mod n d 17/39 ece Man in the Middle Alice Bob Charlie How to get Bob's public key safely to Alice? c=m mod n e m=c mod n d –> “Trusted Third Party” (+ lots of confusion) 18/39 Trusted Third Party ece Introducing “Trusted Third Party”, Vera: ● ● Vera has her own public and private key Vera has her public key widely distributed in a fashion that everyone believes (How?) – ● Generally, everyone's web browser has them “built in” (Internet Explorer, FireFox, Safari) (Think Vera –> Verisign) 19/39 Trusted Third Party ● Bob sends his public key to Vera – ● Certificate Signing Request (.csr) Vera verifies that Bob “is who he says he is” (How?) – ● ece This is what you are paying for! Vera “digitally signs” and returns this to Bob – SSL/TLS Certificate (.crt) 20/39 ece Trusted Third Party Vera Bob public key (n) (somehow widely published) Generates public key private key (e, d, n) Alice “built into” the web browser aka root certificates public key (n) certificate signing request .csr Vera verifies Bob's identity (calls on the phone?) Generates public key private key (e, d, n) “digitally signs” SSL/TLS certificate .crt Bob 21/39 Trusted Third Party ece Now the communications between Alice and Bob: ● ● ● Alice asks Bob for his SSL/TLS certificate Alice checks to see if she can verify the digital signature using Vera's public key If the digital signature verifies, and Alice trusts Vera, then Alice believes that the SSL/TLS certificate came from Bob – No one else could have generated Vera's digital signature ● “Inside” of this SSL/TLS certificate is Bob's public key! ● Alice now has Bob's public key and can proceed as before 22/39 Trusted Third Party (m) Alice Alice (m) ece Bob Bob hello check digital signature using Vera's “built in” public key use Bob's public key found in certificate c=m mod n e SSL/TLS certificate .crt RSA encrypted message (c) m=c mod n d (m) 23/39 That's How SSL/TLS Works ece That's it! That's how SSL/TLS works! ... Simple, right? Depends upon: ● Trusting Vera: – Vera actually verifies that Bob “is who he says he is” – Distribution of Vera's public keys (root certificates) 24/39 That's How SSL/TLS Works ece But, think about this a little: ➔ In some sense, we have traded the problem of getting Bob's public key to Alice, for the problem of getting Vera's public key to Alice. 25/39 That's How SSL/TLS Works ece But, think about this a little: ➔ ➔ In some sense, we have traded the problem of getting Bob's public key to Alice, for the problem of getting Vera's public key to Alice. But, there is only one Vera, and lots of Bobs! So, we still have the problem, but we have made the problem much smaller, and possibly tractable. 26/39 What is It? ● Connection is Encrypted – but that's easy ● Verification of “the other end” – (via the trusted third party) – This is the real reason for SSL/TLS!!! ece ... Is it any thing else? – NO! 27/39 Lingering Issues ● Trust ends where the credit card begins ● Who's certificate is this? ● Revocation Lists ● Root certificate poisoning ● Your own government ece 28/39 Trust Ends Where the Credit Card Begins ece – All SSL/TLS tells you is that you have an encrypted connection to whomever was issued that certificate – Do you really trust the person at the other end of the connection? – Rules governing “verification” (you are who you say you are) are being weakened ● Due to high volume of certificates issued ● No human in the loop!!! 29/39 Who's Certificate is This? A.K.A. ece DNS / URL spoofing c=m mod n e Alice Bob Charlie ● Charlie has his own certificate signed by Vera ● Charlie hands his certificate to Alice ● How is Alice to know its not Bob's certificate? m=c mod n d 30/39 Who's Certificate is This? ece c=m mod n e Alice Bob Charlie ● Charlie has his own certificate signed by Vera ● Charlie hands his certificate to Alice ● How is Alice to know its not Bob's certificate? m=c mod n d –> Certificate has Bob's “name” on it 31/39 Who's Certificate is This? ece Certificate has Bob's “name” on it? – What is Bob's “name”? – Bob's “name” is his DNS name –> Always check the URL! 32/39 Always Check the URL? ece Is checking the URL sufficient? What about “similar names” – www.amazon.com –> www.amazone.com – www.capitalone.com –> www.capitolone.com – www.there.com –> www.their.com – www.amazon.com –> www.amazon.çom 33/39 Always Check the URL? ece Is checking the URL sufficient? What about “similar names” – www.amazon.com –> www.amazone.com – www.capitalone.com –> www.capitolone.com – www.there.com –> www.their.com – www.amazon.com –> www.amazon.çom 34/39 Revocation Lists ece Revocation Lists and Short “valid” times ● Certificates usually valid only for 1 – 2 years ● Widely published list of certificates that have been revoked – Minimize the amount of time a “bad guy” can use his certificate – Quickly revoke bad guy's certificate Largely unused! ● I defy you to find these “widely published” revocation list!!! 35/39 Root Certificate Poisoning ece This is a big deal! Most people just ignore this. ● ● ● Microsoft people clicking “ok” might install a bad guy's root certificate Leave your desk, someone could easily, in a couple of clicks, install his own root certificate Product update channels get poisoned along the way 36/39 Your Own Government ece (Get out your tin­foil hats!) ● ● ● ● The US Government's encryption policy: “Strong enough so that citizens can't listen to other citizens, but not so strong that the Government can't” You think the Government does not already has Verisign's private key? DES – Government pushed encryption, now known to have “Government exploitable” weaknesses Recent A.Q. Kahn allegations – implies that it took ~3 years to break encryption on his laptop 37/39 Recommendations for the Average User ● ● ● ece Don't just click ok to any “certificate error” popup unless you really know what your doing!!! Check the URL carefully, is it who you think it should be? Your level of “trust” at the other end of the connection – Don't deal with unknown web sites 38/39 Recommendations for the Sys Admins and Developers ● ● ece Some way to “shore up” the distribution of root certificates Someway to easily verify if any of your users have suspicious root certificates ● Someway to actually use those revocation lists ● Education of your users! ● Other??? 39/39 Understanding SSL/TLS ece End of first half of talk Second half, will be a technical “howto” (If you're a pointy haired boss, now would be a good time to make for the exit.) 40/39 OpenSSL HowTo ece There are two things we would like to cover ● ● Standard SSL use, have “real” signer sign your certificate – what most people want to do “Self signed certificates” – Be your own signing authority (This will be a “Linux” point of view howto) 41/39 OpenSSL HowTo ece A key concept that was left out of the first half: SSL/TLS is usually “one sided” – Anonymous client wants to connect to a verified server – Typical web situation SSL/TLS can be mutual (two sided), just need a certificate for both ends – There have been suggestions that all mail servers should use and require mutual SSL/TLS 42/39 Standard SSL Use ece Have “real” signer sign your certificate – what most people want to do ● Generate your public / private key pair ● Create a “certificate signing request” ● Send it to Verisign ● Receive certificate ● Put files in correct place, and do config files ● Debug 43/39 ece SSL/TLS “Setup” Vera Bob public key (n) Generates public key private key (e, d, n) Alice “built into” the web browser aka root certificates Verisign Does This Generates public key private key (e, d, n) public key (n) certificate signing request .csr Vera verifies Bob's identity (calls on the phone?) “digitally signs” SSL/TLS certificate .crt We Do This Bob 44/39 OpenSSL HowTo ece Before we get started, some questions that need answers: ● Are there different types of certificates? ● Where (what directory) do I do this? ● To Passphrase or not to passphrase? 45/39 OpenSSL HowTo ece Are there different types of certificates? Not really. Sometime you see instructions for apache mod_ssl, apache strong hold, etc. These differences are for config/setup differences. I use the same certificate for SMTP, LDAP, web. Caveat: Windows users, I don't really know. 46/39 OpenSSL HowTo ece Where (what directory) do I do this? You often find instructions that so go to such­n­such directory to generate your keys. It does not matter. I just make a directory someplace and use that. Later on, you move all the files to their proper place. 47/39 OpenSSL HowTo ece To Passphrase or not to passphrase? The short answer is no. Why? Because every time you reboot your web server you have to type in the passphrase. Furthermore, you can “remove” the passphrase anytime you want. Just handle your keys and certificates wisely. 48/39 ece Generate Public & Private Keys Create a directory somewhere, go there and type: openssl genrsa ­out server.key 1024 49/39 Public & Private Keys ece Now, lets look inside this file: openssl rsa ­in server.key ­text ­noout 50/39 ece c=m mod n e m=c mod n d 51/39 ece Create a Certificate Signing Request openssl req ­new ­key server.key ­out server.csr Asks for your “name”!! This MUST be correct. 52/39 Certificate Signing Request ece To see what is inside the .csr: openssl req ­in server.csr ­text ­noout 53/39 Certificate Signing Request ece Has only public key and “name” c=m mod n e m=c mod n d 54/39 Certificate Signing Request ece The .csr is PEM encoded – text format: It is typical that you “cut­n­paste” this text into a web page to submit your .csr to the signing authority. 55/39 Send Your CSR ece ● You send your money and your .csr to Verisign ● Verisign somehow verify that “you are you” ● Verisign will sign and send you your X.509 certificate! 56/39 ece Receive Your Certificate (X.509) Verisign sends you your X.509 certificate! And for the obligatory look inside: openssl x509 ­in server.crt ­noout ­text 57/39 ece 58/39 Configuring Apache ece O.k., so you got your shiny new certificate, lets see it go. Apache setup: vi /etc/httpd/conf.d/ssl.conf c=m mod n e m=c mod n d 59/39 Testing Apache ece Restart you web server, and try https:// If all goes well, you see the little “lock” appear with no “certificate error” popups. 60/39 Debugging ece We all know that in the real world, everything works perfectly, the first time, every time... But should that exceedingly rare event actually occur where things aren't working... ● ● Take a long look at the conf file, make sure the files are where you say they are Look at the log files (note ssl has separate log files ssl_access_log, ssl_error_log) 61/39 Debugging ece And lastly, try openssl s_client ­connect : ­debug ­state Keep in mind that the port number changes for SSL. For web servers, it is not port 80, but port 443. What this does is gives you a lot of output, but most importantly, a bidirectional connection to your web server through SSL. 62/39 Debugging ece openssl s_client ­connect filebox.ece.vt.edu:443 ­debug ­state So, you must be able to “speak HTTP”. Type the above and admire the voluminous output. It will wait for input. There is no prompt, just type: GET / HTTP1.0 More voluminous output, but you should see some HTML looking stuff. 63/39 Standard Use ece Thats it! Its that simple, only two commands: openssl genrsa ­out server.key 1024 openssl req ­new ­in server.key ­out server.csr Note(s) to self: – Protect your keys, especially the private key. Change file/directory permissions. – Make a backup of your keys! If you lose your certificate, they are not suppose to issue you another one (but they do). 64/39 Self Signed Certificates ece “Self signed certificates” – Be your own signing authority ● What do you mean “Self signed certificate”? ● Why would you want to do this? ● ● What happens when you use your self signed certificate? And of course, how do you do this? 65/39 What Do You Mean by “Self Signed Certificate”? ● ece The term “Self signed certificate” is incorrect, the proper phrase is “Being your own Certificate Authority”, or CA ● You have the “root key” ● And you can “sign” other certificates 66/39 ece Why Would You Want to do This? ● ● ● ● Cost – free. Any linux box that has openssl installed (all) has everything you need Provides encryption, but no “verification” Closed systems. Sometimes you want to keep others out. Ex. LDAP /w “require ssl” Keep “Big Brother” from snooping! 67/39 Self Signed Certificates ece What happens when you use your self signed certificate? ● Some applications won't proceed, e.g., LDAP requre ssl ● Well, you get the “certificate error” popup ● You can “install” the public key ● Or you can “install” the root certificate 68/39 Self Signed Certificates ece There is a lot of confusion on the net about this. If you google “self signed certificate” will get lots of hits. They'll give you some commands to type, but almost all of the instructions lack explanation (that I can understand). ... But all these web pages give different instructions! 69/39 Self Signed Certificates ece Before we get started, one important point: – Private keys do not have the “name” in them – Public keys (AKA X.509) Certificates have the “name” When you create an X.509 certificate, you will be asked for the “name”. The “name” is actually more than just the DNS, it is also your “location”, “affiliation” and perhaps a “responsible party”. (Other?) 70/39 Self Signed Certificates ece O.k., enough adieu, lets get started. We need: ● Two sets of keys: – The CA's keys (Certificate Authority) – The certificate you are going to “sign” 71/39 ece SSL/TLS “Setup” CA Server public key (n) Generates public key private key (e, d, n) CA Distributed Somehow Generates public key private key (e, d, n) public key (n) certificate signing request .csr CA Identity Verification? “digitally signs” SSL/TLS certificate .crt Server 72/39 Self Signed Certificates ece Step 1: Create the CA's key pair openssl genrsa ­out CA.key 1024 73/39 Self Signed Certificates ece Step 2: The CA needs its own “certificate” Why? –> This is the “widely published” “root certificate” openssl req ­new ­x509 ­days 3650 ­key CA.key ­out CA.crt –> Ask for “name” This “name” is the CA's name!!! Not a valid DNS name. 74/39 Self Signed Certificates ece Create CA's root Create root cert (asks for “Name”) 75/39 Self Signed Certificates ece Note: For the pedantic minded people, the “root certificate” is the only “self signed” certificate. 76/39 Self Signed Certificates ece Step 3: Create the private key for the server. (The “server” in this case, is you web server.) Just like any other public/private key generation: openssl genrsa ­out server.key 1024 77/39 Self Signed Certificates ece Step 4: Create a “Certificate Signing Request” openssl req ­new ­key server.key ­out server.csr This will ask you for the “name” of the machine. In this case you must use the DNS name!!! 78/39 Self Signed Certificates ece Step 5: “Sign” the certificate. openssl x509 ­req ­days 3650 ­CA CA.crt ­CAkey CA.key ­set_serial 01 ­in server.csr ­out server.crt 79/39 ece 80/39 Self Signed Certificates ● ece You can “look at” the certificates the same as above. ● You install the certificates the same as above. ● And of course, debug as before. 81/39 Self Signed Certificates ece O.k., so you've created your own self signed certificate, now what? ● ● ● Always get the certificate error popup – just click OK Accept the certificate forever – no more popup. Install the “root certificate” – no popups for any certificate signed by this CA. 82/39 Certificate Error Popup ece Always get the certificate error popup – just click OK 83/39 Examine the Certificate ece Sure enough, we see our certificate. 84/39 Accept the Certificate ece You can “bless” this certificate and get rid of the popup. 85/39 Accept the Certificate ece Let's take a look at what “accepting the certificate” did. Click: Edit, Preferences, tab Advanced, View Certificates. Now click: tab Web Sites. 86/39 Install “Root Certificate” ece Suppose you have a number of places that you might use a certificate that is signed by your CA. Rather than accepting the certificate for a given web site, you could install the CA's root certificate. This has the affect of saying: “I trust all certificates signed by this CA.” 87/39 Install “Root Certificate” ece A quick way of doing this is to put the file CA.crt on a web page. Then, from your browser, just click on the file, the browser will know what a .crt file is. 88/39 ece –> 89/39 Install “Root Certificate” ece You must say “for what” you will trust this root certificate: 1. Web 2. email 3. Java applet 90/39 Install “Root Certificate” ece Let's take a look at what “installing the root certificate” did. Click: Edit, Preferences, tab Advanced, View Certificates. Now click: tab Authorities. 91/39 Self Signed Summery ● ece Generate CA (.key and .crt): openssl genrsa ­out CA.key 1024 openssl req ­new ­x509 ­days 3650 ­key CA.key ­out CA.crt ● Generate server (.key and .csr): openssl genrsa ­out server.key 1024 openssl req ­new ­key server.key ­out server.csr ● “Sign” the certificate (.crt): openssl x509 ­req ­days 3650 ­set_serial 01 ­CA CA.crt ­CAkey CA.key ­in server.csr ­out server.crt 92/39 Understanding SSL/TLS ece Wrapping up, last comments ● We talked about SSL, what about TLS? ● Something about DSA ● Protocols that support SSL/TLS ● Things not covered in this talk 93/39 What About TLS? ece Trying to SSL existing applications required a second “TCP port”. Eg. www: 80 (non­SSL) & 443 (SSL port), SMTP: 25 & 465, IMAP: 143 & 585. “Port proliferation”. TLS is basically SSL, but you start the connection unencrypted, and ask: “Can you do TLS?” Then enter into the SSL protocol. 94/39 Something About DSA ece In addition to the RSA algorithm, there are several other algorithms, but to the best of this authors research, the only one widely implemented is RSA. In short, someday we might have something other than RSA, but for right now, just use RSA. 95/39 ece Protocols That Support SSL/TLS ● www ● CORBA ● nntp ● Oracle ● imap ● MS Global Catalog ● pop ● SMTP ● ftps ● LDAP 96/39 ece Things Not Covered in This Talk: – Being a “real” CA – more complicated than you'd ever expect; revocation list, serial numbers, etc. – Mutual trust: certificate at both ends of the connection. Eg. LDAP, SMTP? – Programming using SSL/TLS – Understanding the rhyme and reason behind openssl's command line... – How to do this using Windows 97/39 Understanding SSL/TLS ece References: ● www.openssl.org ● www.openldap.org ● www.courier­mta.org ● http://www.madboa.com/geek/openssl/ (Recommended!) 98/39 Understanding SSL/TLS ece The End (Finally!) 99/39