SSL and HTTP/S

SSL is a public key-based protocol that was developed by Netscape and is supported by all popular Web browsers. SSL 3.0 has been used for over a decade along with its predecessor, SSL 2.0, in all the major Web browsers. In systems where SSL or some other method of system-to-system authentication and data encryption is not employed, data is transmitted in cleartext, just as it was entered.This data could take the form of e-mail, file transfer of documents, or confidential information such as social security numbers or credit cards numbers. In a public domain such as the Internet, and even within private networks, this data can be easily intercepted and copied, thereby violating the privacy of the sender and recipient of the data.We all have an idea of how costly the result of information piracy is. Companies go bankrupt; individuals lose their livelihoods or are robbed of their life savings as a result of some hacker capturing their information and using it to present a new technology first, to access bank accounts, or to destroy property. At the risk of causing paranoia, if you purchased something via the Web and used a credit card on a site that was not using SSL or some other strong security method, you are opening yourself up to having your credit card information stolen by a hacker.Thankfully, nowadays most, if not all, e-commerce Web sites use some form of strong security like SSL or TLS to encrypt data during the transaction and prevent stealing by capturing packets between the customer and the vendor.

While SSL is widely used on the Internet for Web transactions, it can be utilized for other protocols as well, such as Telnet, FTP, LDAP, Internet Message Access Protocol (IMAP), and Simple Mail Transfer Protocol (SMTP), but these are not commonly used.The successor to SSL is TLS, which is an open, Internet Engineering Task Force (IETF)-proposed standard based on SSL 3.0. RFC's 2246, 2712, 2817, and 2818.The name is misleading, since TLS happens well above the Transport layer.The two protocols are not interoperable, but TLS has the capability to drop down into SSL 3.0 mode for backward compatibility, and both can provide security for a single TCP session.

SSL and TLS

SSL and TLS provide a connection between a client and a server, over which any amount of data can be sent securely. Both the server and the browser generally must be SSL- or TLS-enabled to facilitate secure Web connections, while applications generally must be SSL- or TLS-enabled to allow their use of the secure connection. However, another trend is to use dedicated SSL accelerators as virtual private network (VPN) terminators, passing the content on to an end server.

SSL works between the Application Layer and the Network Layer just above TCP/IP in the Department of Defense (DoD) TCP/IP model. SSL running over TCP/IP allows computers enabled with the protocol to create, maintain, and transfer data securely, over encrypted connections. SSL makes it possible for SSL-enabled clients and servers to authenticate themselves to each other and to encrypt and decrypt all data passed between them, as well as to detect tampering of data, after a secure encrypted connection has been established.

SSL is made up of two protocols, the SSL record protocol and the SSL handshake protocol. SSL record protocol is used to define the format used to transmit data, while the SSL handshake protocol uses the record protocol to exchange messages between the SSL-enabled server and the client when they establish a connection.Together, these protocols facilitate the definition of the data format that is used in the transaction and to negotiate the level of encryption and authentication used. SSL supports a broad range of encryption algorithms, the most common of which include the RSA key exchange algorithms and the Fortezza algorithms.The Fortezza encryption suite is used more by U.S. government agencies. SSL 2.0 does not support the Fortezza algorithms. Its lack of backward compatibility may be another reason why it is less popular.

The SSL handshake uses both public-key and symmetric-key encryption to set up the connection between a client and a server.The server authenticates itself to the client (and optionally the client authenticates itself to the server) using Public Key Cryptography Standards (PKCS).Then the client and the server together create symmetric keys, which they use for faster encryption, decryption, and tamper detection of data within the secure connection.

When the client connects to a server, a stateful connection between the two is negotiated through the handshake procedure.The client connects to the SSL-enabled server and requests that the server sends back information in the form of a digital certificate.The certificate contains information used for authentication, containing such data as the server's name, public encryption key, and the trusted Certificate Authority (CA). As we'll discuss later in this tutorial, when we cover code signing, the CA is a server or entity that issues digital certificates, such as an internal certificate server on a network or a trusted third party like VeriSign (www.verisign.com). Once the client has the certificate, they may proceed further by contacting the CA to ensure that the certificate is authentic, and will present the server with a list of encryption algorithms that the server can use to choose the strongest algorithm that the client and server can support. Data exchanged between the client and server is then used with hashing functions to generate session keys that are used for encryption and decryption throughout the SSL session.