Cryptography: TLS/SSL Protocol

     Network interactions require specific protocols for them to take place. These protocols are based around user authentication and confidentiality. Protocols can be used for authentication, confidentiality, or both. The protocols allow you to make secure transactions, application connections, and user connections over non-secure networks. Examples of these protocols are TLS/SSL, IPSec, and Kerberos. I’ll focus this blog on TLS/SSL as that is the protocol most visible to everyone today.

TLS/SSL

     We all use this protocol when we browse the internet because TLS/SSL is the underlying security protocol for HTTPS. The protocol is implemented at the socket layer (to use it applications have to implement it) and is relatively simple. TLS/SSL main purpose is for secure transaction. To purchase an item you want to be sure you are dealing with the real business (authentication), you want your credit card information to be protected (confidentiality and integrity), and the business does not need to authenticate you since all they want is the money (no mutual authentication). Now to the actual steps of the protocol. If you are ready to purchase an item on Amazon then the first step is for you to request a connection with Amazon.  Along with it you will send a list of ciphers that you support and a random nonce (number used once). Amazon will then reply with their certificate, a chosen cipher, and their own random nonce. You then reply with a secret that is encrypted with Amazon’s public key and another encrypted message that is used for integrity check and establishes a session key. Amazon replies with one last message to prove that they were able to decrypt your previous messages. A couple of important parts are the certificate sent by Amazon and the established session key. The certificate prevents a man-in-the-middle attack because it is signed by a certificate authority and your browser will check the certificate signature. If an attacker sends a false certificate the browser will see that it is not signed and gives a warning to you. Unfortunately users can ignore this warning and allow the connection to proceed which allows the man-in-the-middle attack to succeed. This is a flaw in human nature not the protocol. The other important part of the protocol messages is the session key. The session key is a hash of the secret you sent and both of the nonces. Often your browser opens multiple parallel connections to improve performance. The TLS/SSL session are costly but given an existing session new connections are cheap. Thus any number of new connections can be created from the existing key to allow multiple parallel connections.

Book I've been reading: Information Security: Principles and Practice by Mark Stamp.