Apache webserver 2.2.15.el6 SSL/TLS part 2

how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

1. A company wishes to secure communications to their web server company.com.
2. They create a public and private key for company.com (this is also known as as “SSL Certificate“).
3. They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
4. Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s own private key… we will see why below.

Then, when Jason wishes to communicate with the company at company.com,

1. Jason makes a connection to company.com with its computer (e.g. from his web browser if this is a web site). This connection is made to a special “port” (address) on company.com that is set up for SSL communications only (alternately, Jason could connect to a non-secure port and the initiate a secure connection after the fact … see SSL vs TLS – what’s the difference).
2. Jason connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
3. Jason gets the public key and decides if it is “OK”…
   1. If the public key has expired, this could be a problem (these are only valid for a certain number of years before they have to be re-verified)
   2. If the public key claims to be for some domain that is not company.com that could be a significant problem.
   3. Jason has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, Jason can decrypt the validation information, prove the validation is actually from Thawte, and verify that the public key is certified by Thawte. If Jason trusts Thawte, then he can trust that he is really communicating with Company. If Jason doesn’t trust Thawte, or whatever Third Party verification company is actually being used, then the identity of who is running the servers to which Jason is connecting is suspect.
4. If Jason doesn’t trust the server, then the communication is terminated before anything sensitive is communicated.
   1. Note: If Jason has his own SSL certificate, he may send that to the server at this point to see if the server trusts Jason.  These “Client-side SSL certificates” are not commonly used, but provide a good way for users like Jason to authenticate themselves with a server without using a username or password (or in addition to doing so, as a second factor).  In cases where this is used, the server would have to already know about the Jason’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.
5. Once Jason is happy with the server (and the server with Jason, if needed), then he can  choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (a password) for use with that Cipher.  Jason encrypts this password using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this password, which is now shared by both Jason and server.
   
6. Jason will then start communicating with the company by encrypting all data using this password and the chosen Cipher.  Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly Jason to prove its identity and right to domain.com and to enable Jason and server to generate and securely communicate the unique, shared password.

SSL vs TLS
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which are designed to provide communication security over the Internet. They use X.509 certificates and hence asymmetric cryptography to assure the counterparty whom they are talking with, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties
There are two distinct ways that a program can initiate a secure connection with a server:

1. By Port: Connecting to a specific port means that a secure connection should be used.  For example, port 443 for https (secure web), 993 for secure IMAP, 995 for secure POP, etc.  These ports are setup on the server ready to negotiate a secure connection first, and do whatever else you want second.
2. By Protocol: These connections first begin with an insecure “hello” to the server and only then switch to secured communications after the handshake between the client and the server is successful. If this handshake fails for any reason, the connection is severed.  A good example of this is the command “STARTTLS” used in outbound email (SMTP) connections.

The “By Port” method is commonly referred to as “SSL” and the “By Protocol” method is commonly referred to as “TLS” in many program configuration areas.  Sometimes, you have only the option to specify the port and if you should be making a secure connection or not and the program itself guesses from that what method should be used … many old email programs like Outlook and Mac Mail did th
To Review: In email programs and other systems where you can select from SSL or TLS together with the port a connection will be made on:

1. SSL means a “by port” connection to a port that expects to the session to start with security negotiation
2. TLS means a “by protocol” connection where the program will connect “insecurely” first and use special commands to enable encryption
3. Use of either could result in a connection encrypted with either SSL or TLS of any version based on what is installed on the sever and what is supported by your program.
4. Both methods of connection result in equally secure communications.

So then, should I choose TLS or SSL?

If you are configuring a server, you should install software that supports the latest version of the TLS standard, and configure it properly.  This ensures that the connections that your user make is as secure as possible.  Using an excellent security certificate will also help a lot — e.g. one with 2048+ bit keys, Extended Validation, etc.
 current vers:
TLS 1.2 was defined in RFC 5246 in August 2008.
 From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak

Basic TLS handshake

A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:

1. Negotiation phase:
   • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites 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 TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected.
   • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).^[102]
   • 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.
2. 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.
3. 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.
4. 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.

Client-authenticated TLS handshake

The following full example shows a client being authenticated (in addition to the server like above) via TLS using certificates exchanged between both peers.

1. 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 compression methods.
   • The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
   • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).^[102]
   • The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.
   • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
   • The client responds with a Certificate message, which contains the client's certificate.
   • The client sends 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 sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the 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.
2. 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 was negotiated). " The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
   • Finally, the client sends an 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.
3. 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 own encrypted Finished message.
   • The client performs the same decryption and verification.
4. 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 encrypted exactly like in their Finished message.