Whole document tree
1.3. What is SSL and what are Certificates?
The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol use a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how does it work.
A browser request a secure page (usually https://).
The web server send its public key with its certificate.
The browser check that the certificate was issued by a trusted party (us-ally a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
The browser then use the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required and other encrypted http data.
The web server decrypts the symmetric encryption key using its private key, uses the symmetric key to decrypt the URL and http data.
The web server sends back the requested html document and http data encrypted with the symmetric key.
The browser decrypt the http data and html document using the symmetric key and displays the information.
Several concepts have to be understood here.
1.3.1. Private Key/Public Key:
The encryption using a private key/public key pair ensure that the data can encrypted by one key can only be decrypted by the other key. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used in alternatively. The key pair is based on prime numbers and their length in terms of bits ensure the difficulty of being able to decrypt the message. the trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. This ensures that anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secure you have just signed it. Everybody has the public key, remember!
1.3.2. The Certificate:
How do you know that you are dealing with the right person or rather the right web site. Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust, you have his/her certificate loaded in your browser. A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, and resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certify (sign) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who sign this certificate, therefore you also trust this certificate. This is what is called a certificate trust tree. Usually your browser or application has already loaded the root Certificate of well known Certification Authorities (CA) or root CA Certificate. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign certificate using itself, it is called a self signed certificate. All root CA certificates are self signed.
1.3.3. The Symmetric key:
Well any Private Key/Public Key encryption algorithm is great, but it is usually not practical. It is asymmetric because you need the other key pair to decrypt. You can't use the same key to encrypt and decrypt. An algorithm using a symmetric key is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. The problem is that you must transmit the key to the other party without the enemy getting its hands on it. And as you know, nothing is secure on the Internet. The solution, is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. As you never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.
1.3.4. Encryption algorithm:
There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented its algorithms, then he would have been able to sue Albert Einstein... So algorithms cannot be patented except in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the application will indicate to each other a list of algorithm that can be understood by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.
1.3.5. The Hash:
A hash is a number given by a hash function. This is a one way function, it means that it is impossible to get the original message knowing the hash, however the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message without modify its hash. Hash function are used in password mechanism, in certifying applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with.
1.3.6. Signing:
Signing a message, means authentifying that you have yourself assured the authenticity of the message. The message can be a text message, or someone else certificate. To sign a message, you create its hash, and then encrypt the hash with your private key, you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally that it trusts the certificate.
1.3.7. PassPhrase:
A passprase is like a password except it is longer. In the early days passwords on Unix system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password more difficult it is to guess it. Nowadays Unix systems use MD5 hashes which have no limitation in length of the password.