VIDEO Intypedia009en LESSON 9: INTRODUCTION TO THE SSL PROTOCOL AUTHOR: PhD Alfonso Muñoz Muñoz PhD Telecommunications Engineer – Technical University of Madrid R&D Security Researcher T>SIC Group – UPM ALICE Hello and welcome to Intypedia. Today we will explain the basics of the SSL/TLS encryption protocol; a very important protocol for electronic commerce and secure Virtual Private Networks. This is a very interesting topic... Come along! 1. THE ORIGIN OF SSL ‐ ATTACKS TO DATA IDENTITY AND INTEGRITY BOB In the 90's, the company Netscape Communication—famous for making the Netscape Navigator Web browser—created and developed a method for providing secure communications over a network; the SSL (Secure Sockets Layer) standard protocol. ALICE This protocol is very useful because when we surf the Internet, many attacks can be made to the exchanged information (integrity and confidentiality) as well as attacks to the identity of persons or services we connect to (authentication), as we saw in Lesson 4. BOB Script Intypedia009en 1 That's right. In such cases, the use of the SSL protocol is very helpful. Unfortunately, it isn't always implemented and when users don't use it properly, it's easier to perform attacks without having to change the security measures defined therein. In telecommunication networks, like the Internet, these attacks are usually carried out through Man‐in‐the‐middle attacks (MITM). When integrity and authenticity procedures aren't enabled, it's possible to change or modify the information in transit and also to impersonate the sender or receiver of the communication. Nowadays, such attacks are very easy to carry out using free tools available on the Internet. A recent Man‐in‐the‐middle attack famous for the publication of the Firesheep tool, consists of stealing a user's session cookie (the one that authenticates) when the user logs into a Web service like Facebook, Twitter or a Google account. ALICE Wow! And how is that possible? BOB It's possible when the attacker has access to the exchanged traffic—when they are in the same wireless network, for example—and when the data can be read easily. Once they have the session cookie that authenticates the user, they can impersonate the user and enter the sites that this validation provides access to. The attack based on stealing a session cookie—the HTTP session hijacking attack—has been known for a long time, but the Firesheep tool, a Firefox browser extension developed by Eric Butler in October 2010, shows that these attacks are very common nowadays. Interestingly, this incident prompted some companies to enable the SSL protocol for accessing their services securely. A significant example of this was Facebook. Maybe they hadn't considered it before because of its complexity, cost and that it would slow down the communications. ALICE How fascinating! So how does this protocol work? BOB Interesting question, Alice. Now we're going to explain it in detail. 2. HOW SSL WORKS – THE SSL HANDSHAKE PROTOCOL BOB SSL (Secure Sockets Layer) is a cryptographic protocol that provides authentication, integrity and confidentiality of the information in a client/server communication over a network, like Script Intypedia009en 2 the Internet. It runs in a layer between the application protocols such as HTTP, SMTP or NNTP and the TCP transport protocol. Today it is also possible to implement it on UDP. Usually, it is configured so that the communication server is authenticated while the client remains unauthenticated. This is typical, for example, when we connect to our bank's online website through https, where the s for security means that the SSL protocol is being used. Mutual authentication of client and server is also possible using this protocol. ALICE I have a question, Bob: I've heard that a protocol called TLS is also used for these purposes. Are SSL and TLS the same thing? BOB Good question, Alice, because many people are confused about this. The SSL protocol has been the basis for developing the TLS (Transport Layer Security) protocol, currently in version 1.2 (also known as SSL 3.3) defined in RFC 5246. SSL and TLS are conceptually similar, only that TLS enhances the classic SSL in some aspects such as protecting against further attacks, providing new cryptographic algorithms, avoiding the forced use of more vulnerable versions of the protocol, and so on. Apart from agreeing on the version of the protocol in order to establish the communication with the integrity, confidentiality and authenticity requirements, it is also necessary to agree in advance upon the security parameters that will enable a secure communication. These phases are performed by the SSL/TLS Handshake Protocol. However, we mustn't forget about another important protocol: the SSL/TLS Record Protocol that specifies how to encapsulate the sent and received data, and even the negotiation data. ALICE I see you've studied the subject. Could you explain how the SSL Handshake Protocol works? BOB This protocol focuses on three things: First, the client and server negotiation of the algorithms that will be used in the communication. Some of the cryptographic algorithms used for encryption, key exchange and signing are: 3DES, IDEA, AES, RSA, Diffie‐Hellman, DSA, SHA‐2. Second, the exchange of keys and the authentication based on digital certificates, using, whenever necessary, a validation through Public Key Infrastructure (PKI). And third, the encryption of traffic using symmetric cryptography. A session key is generated for communication based on the negotiated parameters, thus enabling the encryption of the data. As mentioned in previous lessons, symmetric cryptography is fast and requires less hardware resources, which is ideal when it is running on client, which usually has fewer resources than the server. Asymmetric cryptography is only used for key exchange and signing. Therefore, this protocol is a good example of the usefulness of hybrid ciphering. Script Intypedia009en 3 The secure connection begins once the parameters have been negotiated. But if the negotiation fails in any of its stages, the connection is cancelled. Let's take a look at an example where only the server is authenticated by its certificate. The following are the most important messages exchanged in the negotiation until the communication is established by means of a simple TLS handshake. 1. The client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number and a list of authentication, ciphering, MAC (Message Authentication Code) and compression algorithms. 2. The server responds with a ServerHello message, containing the selected protocol version (the highest supported by client and server), a random number, the chosen algorithms from those sent by the client and its digital certificate (using a Certificate message) to authenticate itself. 3. The client verifies the server's certificate through a trusted authority or a PKI. Then, the client answers with a ClientKeyExchange message containing a PreMasterSecret (a secret number) with information to generate the session key. If the RSA algorithm is used, the message will be encrypted with the server's public key and the random number generated by the client will have 48 bytes. 4. The client and server use the exchanged random numbers and the PreMasterSecret (retrieved by the server using its private key). With this data they compute a common secret called the master secret. All the subkeys for this connection are derived from the master secret by means of the established pseudorandom function. 5. The client now sends a ChangeCipherSpec record and tells the server that from that moment on, all the exchanged information will be authenticated and—if established previously by the server—it will also be encrypted. 6. Finally, the client sends a signed and encrypted Finished message, containing a hash and MAC of the messages negotiated previously. 7. The server then decrypts the Finished message sent by the client and verifies the hash and MAC. If the decryption or verification fails, the connection doesn't go through. 8. If everything goes well, the server sends a ChangeCipherSpec to the client indicating that, from that moment on, everything it sends will be signed and—if encryption was previously negotiated—encrypted. The server then sends a signed and encrypted Finished message containing a hash and MAC of the messages negotiated previously, which is then validated by the client. 9. The negotiation phase ends and the client and server can now exchange authenticated (and encrypted, if encryption was negotiated) messages. ALICE How interesting! And all of this is done in a transparent way for the user. Script Intypedia009en 4 3. APPLICATION OF THE SSL PROTOCOL – E‐COMMERCE AND VPNs BOB There is no doubt that the success of the SSL/TLS protocol is due to the expansion of electronic commerce on the Internet. Most financial institutions advocate its use: Visa, MasterCard, and American Express, just to name a few. Today it is hard to think of secure Internet communications without the use of SSL, digital certificates and public key infrastructures. A clear example is the securing of Web traffic, where https is used instead of http. SSL can also be used to tunnel an entire network and create a Virtual Private Network (VPN). This can be achieved with the open software tool OpenVPN, for instance. It provides a point‐ to‐point connection with hierarchical validation of remotely connected users and hosts, among other benefits. It is also widely used to provide authentication and encryption in voice over IP traffic (VoIP), that is, voice transmitted over the Internet using the IP network protocol. ALICE From what you have told me, I understand that since the SSL protocol is above the transport layer and below the application layer, with this protocol it would be possible to secure the communication between any software.