SSL Secure socket layer


Published on

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SSL Secure socket layer

  1. 1. 0 2nd Assignment of Comm. Sys. & Computer N.W Department of Information Technology, Institute of Graduate Studies and Research, University of Alexandria, Egypt. Presented by: Ahmed Atef Elnaggar Supervisor: Prof . Shawkat K.Guirguis
  2. 2. 1 Abstract: The Secure Socket Layer (SSL) and Transport Layer Security (TLS) is the most widely deployed security protocol used today. It is essentially a protocol that provides a secure channel between two machines operating over the Internet or an internal network. In today’s Internet focused world, the SSL protocol is typically used when a web browser needs to securely connect to a web server over the inherently insecure Internet. Contents 1- Introduction 1.1- Objectives and Scope…………………………..…..2 1.2- Basic overview………………………………….….2 1.3- Technical overview …………………….................2 1.4- Brief history…………………………….................3 1.5- Family tree of SSL……………………………..…3 1.6- SSL v2 vs. v3……………………………….….….3 2- SSL protocol structure………………………….…….…4 3-How Does SSL Work with My Browser?..........................5 4- Handshake procedures……………………….................6 5- SSL applications……………………………….….….....8 6-SSL Goals………………………………………..…….…9 7- Report advices…………………………………...……..10 8- Conclusion……………………………………………..10 9- Future scope…………………………………………...10 10- References……………………………………………11 11- Glossary ………………………………………..........12 Kindly find the attached softcopy.
  3. 3. 2 1- Introduction SSL (Secure Sockets Layer) is a protocol that provides a secure channel between two machines, and facilities for protecting data in transit and identifying the machine with which you are communicating. 1.1- Objectives and Scope This report is intended to serve as a primer for learning the basic concepts of how SSL operates. Overview information on how SSL termination devices are deployed in a Web server environment also is included. Because this report is intended for a technical audience, a basic understanding of network infrastructure and security concepts is assumed. The SSL protocol is intended primarily for readers who will be studying network security and those doing cryptographic analysis of the protocol. The spec has been written with this in mind, and it is intended to reflect the needs of those two groups. For that reason, this document is intended to supply some details of service definition and interface definition which are included in the body of the report. 1.2- Basic Overview Secure Socket Layer (SSL) is an effective method of protecting data which is sent over a local or wide area network. It works by encrypting data sent over a network, It can be configured on both wired and wireless networks and will work with other forms of security such as WPA keys and firewalls. 1.3- Technical Overview The primary goal of the SSL protocol is to provide privacy and reliability between two communicating applications. The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [RFC0793]), is the SSL record protocol. The SSL record protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the SSL handshake protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. One advantage of SSL is that it is application protocol independent. A higher level protocol can layer on top of the SSL protocol transparently.
  4. 4. 3 1.4- Brief history We present a brief history of the development of SSL protocol. Brief History: 1. SSLv1 (1994), all the pre-IETF versions of SSL was designed by engineers at Netscape Communications. 2. SSLv2 started in 1994. The initial design goal is to provide confidentiality between client and servers. Then further provide: (a) Encryption of a session. (b) Authentication of a server, and optionally a client. (c) Message authentication. 3. SSLv3 [RFC 6101 2011], designed in 1995, targets at fixing the problems from SSLv2.Led by the Internet Engineering Task Force (IETF), Transportation Layer Security (TLS) was designed between 1997 and 1999 by IETF [RFC 2246 1999]. (Most commonly deployed protocol). 4. The Microsoft version of Private Communication Technology (PCT 1995) and Secure Transport Layer Protocol (STLP 1996) were originated from the SSLv2 and SSLv3. 5. The wireless version of TLS is called WTLS (1998). 1.5- Family tree of SSL: As shown in Fig1 1.6- SSL v2 vs. v3  Downgrade Attack: Crypto choices not protected in V2. Finished message in v3 contains digest of all previous messages  Truncation Attack: V2 closes SSL on TCP connection close ⇒ not protected. V3 added session finished message to close SSL session. Figure 1
  5. 5. 4 Figure 2: SSL protocol structure 2-SSL protocol structure SSL is designed on top of TCP. In Figure 2, the SSL protocol structure is presented. The Record Layer support four types of sub-layer protocols: Application data, Alert protocol, Handshake protocol, and Change Cipher Specification protocol. Our discussion is focused on SSLv2. The SSL message transmission sequence is presented in Figure 2.  SSL Handshake Protocol  negotiation of security algorithms and parameters  key exchange  server authentication and optionally client authentication  SSL Record Protocol  fragmentation  compression  message authentication and integrity protection  encryption  SSL Alert Protocol  error messages (fatal alerts and warnings)  SSL Change Cipher Spec Protocol  a single message that indicates the end of the SSL handshake
  6. 6. 5 3-How does SSL work with my browser? Technically, SSL is a transparent protocol which requires little interaction from the end user when establishing a secure session. In the case of a browser for instance, users are alerted to the presence of SSL when the browser displays a padlock, or, in the case of Extended Validation SSL, when the address bar displays both a padlock and a green bar. This is the key to the success of SSL – it is an incredibly simple experience for end users. Standard SSL Certificates (such as Global Sign Domain SSL and Organization SSL) display: As shown in Figure 3 As opposed to unsecured HTTP URLs which begin with "http://" and use port 80 by default, secure HTTPS URLs begin with "https://" and use port 443 by default. HTTP is insecure and is subject to eavesdropping attacks which, if critical information like credit card details and account logins is transmitted and picked up, can let attackers gain access to online accounts and sensitive information. Ensuring data is either sent or posted through the browser using HTTPS is ensuring that such information is encrypted and secure. Behind the scenes, the browser retrieves the SSL certificate whenever it connects to a secure site. The browser check to make sure that the certificate has not expired, whether or not the issuing authority is one that the browser trusts, and that the certificate is being used by the same website to which it was issued. If either safety check fails, the browser will let the user know that the site is not secured by SSL through a warning message. The user has the choice of trusting the site or leaving. Figure 3: SSL Standard
  7. 7. 6 4- Handshake procedures The steps involved in the SSL handshake are as follows (note that the following steps assume the use of the cipher suites listed in Cipher Suites with RSA Key Exchange: Triple DES, RC4, RC2, DES) As shown in Figure 4: 1) The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL. 2) The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate. 3) The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4. 4) Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server. 5) If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret. 6) If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. 7) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection). 8) The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
  8. 8. 7 9) The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished. 10) The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity. 11) This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself Figure 4: Handshake procedures
  9. 9. 8 5- SSL applications SSL was originally created to secure web traffic information, in particular data sent between web browsers and servers. For example, when you use Internet Banking and you see https:// and the little padlock in bottom right hand corner of the web browser, you are using SSL. It then grew to work with other applications such as telnet, printers and FTP software in order to become a universal solution for online security. Its original design intentions are still being used today by many online retailers and banks to secure sensitive data, such as credit card numbers, customer records etc. SSL uses extremely high levels of encryption and is trusted by banks all over the world since it is unlikely that it will be broken. According to VeriSign™, a leading online SSL Certificate Authority (CA) 1, it would take a hacker ‘well over a lifetime’ to hack through a standard SSL encrypted document. In practice, how is SSL used in today’s modern e-commerce enabled / online workflow and service society?  To secure online credit card transactions.  To secure system logins and any sensitive information exchanged online.  To secure webmail and applications like Outlook Web Access, Exchange and Office Communications Server.  To secure workflow and virtualization applications like Citrix Delivery Platforms or cloud-based computing platforms.  To secure the connection between an email client such as Microsoft Outlook and an email server such as Microsoft Exchange.  To secure the transfer of files over https and FTP(s) services such as website owners updating new pages to their websites or transferring large files.  To secure hosting control panel logins and activity like Parallels, cPanel.  To secure intranet based traffic such as internal networks, file sharing, extranets, and database connections.  To secure network logins and other network traffic with SSL VPNs such as VPN Access Servers or applications like the Citrix Access Gateway.
  10. 10. 9 6-SSL goals All mentioned applications have a number of shared themes:  Confidentiality The data being transmitted over the Internet or network needs confidentiality. In other words, people do not want their credit card number, account login, passwords or personal information to be exposed over the Internet.  Integrity Protection The data needs to remain integral, which means that once credit card details and the amount to be charged to the credit card have been sent, a hacker sitting in the middle cannot change the amount to be charged and where the funds should go.  Authentication Your organization needs identity assurance to authenticate itself to customers / extranet users and ensure them they are dealing with the right organization. Your organization needs to comply with regional, national or international regulations on data privacy, security and integrity Some additional goals of SSL protocol, in order of their priority are: I. Cryptographic security SSL should be used to establish a secure connection between two parties. II. Interoperability Independent programmers should be able to develop applications utilizing SSL that will then be able to successfully exchange cryptographic parameters without knowledge of one another’s code. III. Extensibility SSL seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: to prevent the need to create a new protocol (and risking the introduction of possible new weaknesses) and to avoid the need to implement an entire new security library. IV. Relative efficiency Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the SSL protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.
  11. 11. 10 7- Report advices for defending against web application session-tracking attacks  Digitally sign or hash session-tracking information using a cryptographic algorithm.  Encrypt the information in the URL, hidden form element, or cookie; don’t just rely on SSL.  Make sure your session IDs are long enough to prevent accidental collision.  Consider making your session IDs dynamic, changing from page to page throughout your web application.  Apply a time stamp within the session ID variable and encrypt it. 8- Conclusions The Secure Sockets Layer (SSL) protocol uses a combination of public-key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption; however, public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques, and then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server. 9- Future scope SSL is vital to Web security. It provides a strong sense of confidentiality, message integrity, and server authentication to users. Presently, SSL/TLS become backbone of not only in E-commerce but in any secured information exchange across Internet which is tied closely to consumer confidence in the operation of SSL across the net. In the future, SSL termination devices will be able to handle more transactions at a faster rate. The encryption of key lengths and the cipher suites used will also continue to evolve in order to ensure the security of sensitive information over the Web. This way, e-commerce will be able to continue to grow in popularity as users grow more confidants in shopping and banking online, and embracing new online applications.
  12. 12. 11 10- References Websites:- 1. 2. 3. ssl .org / 4. Books:- 1. M. Bellare, R. Canetti, and H. Krawczyk, Keying Hash Functions for Message Authentication," Advances in Cryptology|CRYPTO '96 Proceedings, Springer-Verlag, 1996, pp. 1{15. 2. S. Bellovin, Problem Areas for the IP Security Protocols", Proceedings of the Sixth USENIX Security Symposium, Usenix Association, 1996, pp. 3. A. Freier, P. Karlton, and P. Kocher, The SSL Protocol Version 3.0", March 4 1996, Internet Draft, work in progress. [Koc96] P. Kocher, personal communication, 1996. 4. V. Voydock and S. Kent, Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, v. 5, n. 2, June 1983, pp. 135{171. 5. Benaloh, B. Lampson, D. Simon, T. Spies, and B. Yee, Microsoft Corporation's 6. SSL & TLS Essentials-by Stephen A. Thomas 7. Network Security with Open SSL-by John Viega, et al 8. SSL and TLS-by Eric Rescorla (Author) 9. T. Dierks, E. Rescorla (August 2008). "The Transport Layer Security (TLS) Protocol, Version 1.2". 10. A. Freier, P. Karlton, P. Kocher (August 2011). "The Secure Sockets Layer (SSL) Protocol Version 3.0". 11. "SSL/TLS in Detail". Microsoft TechNet. Updated July 31, 2003. 12. "Description of the Secure Sockets Layer (SSL) Handshake". Support. 2008-07-07. Retrieved 2012-05-17
  13. 13. 12 11- Glossary Certificate A digitally signed statement from one entity (a company or person) that says that the public key and other information from another entity have a certain value. When data is digitally signed, its authenticity and integrity can be validated by the signature. HTTP Hypertext Transfer Protocol HTTPs Hypertext Transfer Protocol secure 3DES Triple Data Encryption Standard DES Data Encryption Standard IP Internet Protocol MAC Message Authentication Code MTU Maximum Transfer Unit NIC Network Interface Card OSI Open Systems Interconnection Private key a number that is known only to its owner. The owner uses the private key to read (decrypt) an encrypted message. RC2, RC4 A series of encryption algorithms published by RSA Security; all developed by cryptography pioneer Ron Rivest. (Rivest Cipher 2, or Ron’s Code 2 = RC2) All of them are important commercial implementations of symmetric key cryptography where the entity that encrypts and the entity that decrypts both must know the same key. RFC Request for Comment RSA Rivest-Shamir-Adleman RTO Retransmission Timeout ID Identifier Session ID After a user authenticates to a web application (by providing a user ID and password, or through a client-side certificate on an HTTPS session), most web applications generate a session ID to track the user’s session. SSL Secure Socket Layer SSN Stream Sequence Number TCP Transmission Control Protocol TLS Transport Layer Security TSN Transmission Sequence Number UDP User Datagram Protocol ULP Upper Layer Protocol Thanks for reading