Blogs

    Publish
     
      • How does SSL work? What is an SSL handshake?

        Sep 15 2014, 10:24 AM

        by Robert Lin 0

        A special request was made today: "How does SSL work? What is an SSL handshake?"

        Here are some quick info.

        SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.

        For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.

        For a list of the server softwares Symantec has, have a look at: Symantec CSR Generation

        Note that although certifcates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.

        Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol.  On browser applications it is usually https://www.yourwebsite.com.

        Remember to use your secured website address. Above is just a sample address.

        That will start the SSL/TLS negotiation:

        Keys and Secrets during RSA SSL negotiation

        The following is a standard SSL handshake when RSA key exchange algorithm is used:

        1. Client Hello
          - Information that the server needs to communicate with the client using SSL.
          - Including SSL version number, cipher settings, session-specific data.
           
        2. Server Hello
          - Information that the client needs to communicate with the server using SSL.
          - Including SSL version number, cipher settings, session-specific data.
          - Including Server’s Certificate (Public Key)
           
        3. Authentication and Pre-Master Secret
          - Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
          - Client (depending on the cipher) creates the pre-master secret for the session,
          - Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
           
        4. Decryption and Master Secret
          - Server uses its private key to decrypt the pre-master secret,
          - Both Server and Client perform steps to generate the master secret with the agreed cipher.
           
        5. Generate Session Keys
          - 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
           
        6. Encryption with Session Key
          - Both client and server exchange messages to inform that future messages will be encrypted.

        (Wikipedia: Transport Layer Security)

        Tools such as OpenSSL can be used check the SSL/TLS negotiations:

        OpenSSL s_client -connect www.symantec.com:443 -state -ssl3
        Loading 'screen' into random state - done
        CONNECTED(000001C0)
        SSL_connect:before/connect initialization
        SSL_connect:SSLv3 write client hello A
        SSL_connect:SSLv3 read server hello A
        depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5

        SSL_connect:SSLv3 read server certificate A
        SSL_connect:SSLv3 read server done A
        SSL_connect:SSLv3 write client key exchange A
        SSL_connect:SSLv3 write change cipher spec A
        SSL_connect:SSLv3 write finished A
        SSL_connect:SSLv3 flush data
        SSL_connect:SSLv3 read finished A
        ---
        Certificate chain
         0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Corp Mktg & Comms - Online Exp/CN=www.symantec.com

        There it is. SSL and SSL Negotiation summarized. Mission complete.

        Now! Do Not Forget To Back Up Your Private Key and Certificate in a Secure place in case of system issues!

        • Public Key Infrastructure (PKI)
        • DigiCert Code Signing
        • certificate
        • Security Community Blog
        • Products
        • SSL Negotiation
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • private key
        • #CSR
        • Trust Services
      • SSL Ciphers - Beyond Private key and Certificate

        Oct 20 2017, 8:35 PM

        by Robert Lin 2

        Today SSL is an integral part of online businesses and any secured communication. It is however not an area that many system administrators or security experts are comfortable with. For most administrators the correct installation of the private key and its corresponding certificate is sufficient. As long as the green bar, the padlock, or https:// can be seen during the SSL/TLS negotiation, both the administrators and their clients trust that the connectivity is secure.

        However many security flaws and vulnerabilities have been discovered in the recent years. From the server side there is the infamous Heartbleed bug or CCS injection - CVE-2014-0224, side-channel attacks such as Beast, Lucky 13, Crime or BREACH, and others (SSL Attack Survey).  It is not sufficient to just have a correct installation of the private key and certificate pair on the server. Beside patching up server libraries and client applications, additional control to SSL/TLS negotiations need to be applied. One of those control mechanisms is selecting the right cipher suite.

        The strength of an SSL/TLS negotiation depends not only the size of the private key or certificate. As of 2014, the recommended minimium key pair size is 2048 bit, however this does not guarantee maximum encryption sessions. During SSL/TLS handshakes, the agreement of what cipher suite to use determines if the negotiation will be using SSL or TLS protocols. It also determines the key exchange and encryption algorithms. If the agreed encryption level between the client and the server is low, the SSL/TLS session will still be vulnerable. For a system to be truly secure, strong cipher suites are required.

        To address this issue, a project was initiated. The result, "SSL/ TLS Cipher Suite Analysis and strong Cipher Enablement" is included in this blog.

        The purpose of this research is to provide an implementation process to set up a strongly secured SSL/TLS system by viewing the available cipher suites present in a system, recognizing the strength and weakness of the different ciphers and choosing the most applicable cipher suite.

        Note:  The configuration examples given in this document do not represent the complete or best set of strong ciphers to use. Depending on the various security policies and business requirements, the examples given in the document may not apply .

        • Products
        • Symantec Enterprise Security
        • Thought Leadership
        • ciphersecurity
        • Symantec Website Security
        • SSL
        • encryption
        • private key
        • DigiCert SSL TLS Certificates
        • certificate
        • cipher
        • Security Community Blog