Talpor Solutions Blog SSL/TLS certificates beginner's tutorial

This is a beginner's tutorial on SSL certificates (which by now should be called TLS certificates, but old habits die hard). I'll cover both how they function, and how to create a SSl/TLS certificate using OpenSSL, either self-signed or signed by a CA.As a disclaimer, getting security wrong is very easy, and I'm not an expert. If your systems handle anything vital such as credit card information, payments, personal information, weapons systems, etc, then hire an expert, use already available services and just use the code provided to you by people that knows what they are doing. This is not gonna make you an expert on SSL/TLS, not even a novice, it will just make you able to undertand to a basic level what you're talking/hearing about. Things that are essential to TLS secure setup and that are NOT addressed here include:How to secure your keysHow to provision themHow to secure your serversWhat protocols/algorithms/ciphers/modes of operation should your server allow A whole lot moreSeriously, be mindful about how much the information/services that you administer are worth, and what could happen if they were compromised. Then consider carefully if you need to hire extra help or educate yourself more in the subject, security breaches can seriusly f@#* you up, your close ones, and people you dont even know.That said, this tutorial is divided in 7 parts:Introduction to SSL/TLSConfidentiality and integrity in TLSBasics of authentication in TLS (aka. TLS/SSL certificates)Step-by-step instructions on how to create certificates on LinuxIntermediate certificatesBasic constraintsWrap up and useful links Introduction to SSL/TLSSSL (Secure Socket Layer) is an old protocol deprecated in favor of TLS (Transport Layer Security).TLS is a protocol for secure transmission of data heavily based on SSLv3. It offers confidentiality, integrity and authentication. In layman's terms that means that it:Confidentiality: hides the content of the messagesIntegrity : detects when they've been tampered withAuthentication: ensures that whoever is sending them is who he says he is.Additionally it detects missing and duplicated messages.TLS is the primary way to secure web traffic, and is mostly used for that purpose. A whole lot of pages trust that TLS is secure (from the smallest online shop to Facebook), that is why things like POODLE and Heartbleed receive so much press.At this point I want to make something abundantly clear, SSL IS BROKEN, ALL THREE VERSIONS. The latest one, version 3, had its confidentiality severely compromised by POODLE. DO NOT USE SSL. Confidentiality and integrity in TLSFirst I'll briefly explain how TLS offers confidentiality and integrity. We will leave authentication at the end as that will be the bulk of the tutorial.I will be using a lot of crypto jargon here so do not fret if any of this seems too alien to you, generally you won't be fiddling with this directly as TLS negotiates much of this for you.However I do recommend getting familiar with the basics of public key encryption. Not the inner workings mind you, just how they are used in practice to encrypt/authenticate.If you are really interested on these subjects I'd recommend researching:AESBlock ciphers modes of operationCryptographic hashesSHA-2HMACKey exchangeDiffie-HellmanPublic key cryptographyThe Stanford course in Coursera about Cryptography is an awesome starting point.For confidentiality TLS uses either Diffie-Hellman (elliptic curve mode supported) or RSA for the key exchange. With the whole Heartbleed debacle, it is now recommended using a key exchange mechanism with forward secrecy, which implies Diffie-Hellman in this case. The actual encryption is normally done using AES with several modes available (CBC, CCM, GCM).For integrity normally HMAC is used, today is pretty much mandatory to use SHA256. Basics of authentication in TLSAuthentication is the part that you will most likely have to fiddle with the most and the one that actually costs you money, it is also essential for the security of your communications: You. Cannot. Have. Secure. Communications. Without. Authentication.How is that you might ask? Well the thing about confidentiality and integrity is that they are worthless without authentication. If there is no way to ensure that the guy that says "I am gmail.com I swear" is in fact gmail.com and not evil8yoldhacker.com, then you could potentially encrypt and validate a spurious connection.So without authentication you would be open to, for example, MitM (Man in the Middle) attacks. But how can you authenticate a server if you have never seen it before, and let alone exchanged any credentials with it?The answer is TLS certificates. Certificates are just a public key with a bunch of information attached to it, such as the FQDN being authenticated, a contact email, the "issued on" and "expires on" dates, among other things. The server stores and keeps secret the corresponding private key. TLS uses these keys to authenticate the server to the client.Recall that in public key cryptography, messages encrypted with the public key can only be decrypted using the private key, but messages encrypted with the private key can be decrypted with either. The owner of the keys keeps the private key secret, and distributes the public key freely.Now, the usual way to authenticating someone using public key cryptography is the following (Assume that Bob wants to authenticate Alice):Bob sends Alice a random message encrypted with Alice's public keyAlice decrypts the message using her private key and sends it back to BobBob compares the message from Alice against the one that it send. If they match Alice is who she say she is, because only her could have decrypted the message, because only she has her private keyTLS uses a variation of this technique, but is essentially the same.Now, even with this trick validation of a certificate is not straightforward, so for didactic purposes we'll begin with an oversimplified, naive and flawed solution.Solution #1:A hash of the certificate is made, encrypted with the private key, and then appended to the certificate to create a new certificateThe server sends this new certificate to the clients that connect to itTo verify the certificate the client decrypts the hash using the public key of the certificate, then calculates its own hash and compares them, if they are equal the certificate is validIt then sends a random message to the server encrypted with the provided public key, if the server sends the original unencrypted message back, then is considered authenticatedThis process ensures that:The provided public key correspond to the private key used to encrypt the hashThe server has access to the private keyThe encrypted hash created appended to the certificate is called a digital signature. In this example, the server has digitally signed its own certificate, this is called a self-signed certificate.Now, this scheme does not authenticates at all if you think about it. If an attacker manages to intercept the communications or divert the traffic, it can replace the public key on the certificate with his own, redo the digital signature with his own private key, and feed that to the client.The problem lies in the fact that all the information necessary for verification is provided by the server, so the only thing you can be sure of is that the party that you're talking to has the private key corresponding to the public key that it itself provided.This is why when you connect to an entity with a self signed certificate browsers will give a warning, they cannot ensure that whoever you are communicating with is who they say they are.However, these kind of certificates are really useful in some scenarios. They can be created free of charge, quickly, and with little hassle. Thus they are good for some internal communications and prototyping.Solution #2:So that did not work out. How can we solve it? Well, since the problem is that the server provides all the information for authenticating the certificate, why don't we just move some of that information to the client?Let us drive over to the client after lunch with a copy of the certificate in an USB drive, and store it directly on the client. Later when the server sends it's certificate:The client generates its own hash of the certificate and decrypts the provided hash with the public key of the copy of the certificate that was provided earlier in the USB drive, this way it ensures that: 1. the certificate has not changed, 2. whoever signed it has the correct private key.It then sends a random message to the server encrypted with the public key in the copy of the certificate that was stored earlier, if the server sends back the original unencrypted message we consider it authenticatedIf someone intercepts or diverts the connection, they have no hope of passing our random number challenge and providing a valid certificate, without the private key that is computationally infeasible.The "driving over to the client after lunch with an USB drive" is called an out of band process.Now this solution actually authenticates, and is sometimes used for internal communications. However it is not very practical for several use cases. It would be cumbersome to have to download a certificate every time you need to access a new secure website like a bank or eshop, or worse, waiting for someone to drive over to you house after lunch with an USB drive.Moreover, you have to ensure that the certificate is not tampered with on the way, which is one of the problems TLS should be solving for us in the first place. There is also the problem of what to do when the certificate expires, or how to revoke it if the private key becomes compromised. Solution #3:Well, we got something working, but it is not quite ready for use on the landing page of your online store yet. How can we solve it? Well, here is where money comes in.Meet Bob, he is a well known member of the community, a truly and responsible fell