El protocolo SSL (Secure Sockets Layer) fue diseñado con el objeto de proveer privacidad y confiabilidad a la comunicación entre dos aplicaciones. Este se compone de dos capas:
SSL Record Protocol. Está ubicada sobre algún protocolo de transporte confiable (como por ejemplo TCP) y es usado para encapsular varios tipos de protocolos de mayor nivel.
SSL Handshake Protocol. Es uno de los posibles protocolos que pueden encapsularse sobre la capa anterior y permite al cliente y al servidor autenticarse mutuamente, negociar un algoritmo de cifrado e intercambiar llaves de acceso.
Una de las ventajas del SSL es que es independiente del protocolo de aplicación, ya que es posible ubicarlo por encima del mismo en forma transparente.

Las conexiones realizadas por medio de este protocolo tienen las siguientes propiedades básicas:
Privada. Después de un proceso inicial de "handshake" en el cual se define una clave secreta, se envía la información encriptada por medio de algún método simétrico (DES, RC4).
Segura. La identidad de cada extremo es autenticada usando métodos de ciftrado asimétricos o de clave pública (RSA, DSS).
Confiable. El transporte del mensaje incluye un control de la integridad del mismo usando una MAC cifrada con SHA y MD5.

Los objetivos del protocolo SSL son, en orden de prioridad:

• Seguridad Criptográfica. Debe ser usado para establecer una conexión segura entre dos partes.
• Interoperatividad. Programadores independientes deben poder desarrollar aplicaciones que, utilizando SSL, permitan intercambiar en forma exitosa parámetros de cifrado sin tener conocimiento del código utilizado por el otro.
• Flexibilidad. Debe ser una base sobre la cual puedan incorporarse nuevos métodos de cifrado. Esto trae aparejado dos objetivos más: evitar la creación de un protocolo nuevo y la implementación de una nueva biblioteca de seguridad
• Eficiencia. Dado que las operaciones de cifrado consumen gran cantidad de recursos, en especial CPU, incorpora ciertas facilidades que permiten mejorar este aspecto, además de mejorar el uso de la red.

SSL es un protocolo estratificado, por lo que en cada capa se le agregan a los mensajes campos con distintos tipos de contenido, como el largo de los mismos, algún tipo de descripción y la información propiamente dicha. Éste toma los mensajes a transmitir, los fragmenta en bloques de un tamaño conveniente, los comprime en caso de ser necesario, les aplica una MAC, los cifra y el resultante de todo esto lo transmite al otro extremo. El proceso inverso implica el descifrado, verificación, descompresión, rearmado y entrega a los clientes de las capas superiores de los datos recibidos.
Una sesión SSL posee diferentes estados y es responsabilidad del SSL Hanshake Protocol la coordinación de los mismos entre el cliente y el servidor para que ambos funcionen en forma consistente, a pesar del hecho que no estén exactamente en paralelo. Además, cada sesión SSL puede tener múltiples conexiones seguras y cada parte puede tener múltiples sesiones seguras.

El estado de las sesiones incluye los siguientes elementos:

• Session Identifier: Es una secuencia arbitraria de bytes elegida por el servidor para identificar una sesión en estado activo o retomable.
• Peer Certificate: Certificado X509 de la parte. Puede ser nulo.
• Compression Method: El algoritmo utilizado antes de realizar el encriptado.
• Cipher Spec: Especifica el algoritmo de compresión de los datos (puede ser ninguno, DES, etc.) y el algoritmo para la MAC, tal como MD5 o SHA.
• Master Secret: Es un secret de 48 bytes compartido entre el cliente y el servidor.
• Is Resumable: Es un flag que indica si la sesión puede ser utilizada para iniciar nuevas conexiones.

El estado de las sesiones incluye los siguientes elementos:

• Server and Client Random: Secuencia de bytes elegidas por el servidor y el cliente para cada conexión.
• Server Write MAC Secret: Es el secret usado en operaciones MAC sobre datos escritos por el servidor.
• Client Write MAC Secret: Es el secret usado en operaciones MAC sobre datos escritos por el cliente.
• Server Write Key: Es la clave de cifrado para los datos que van del servidor al cliente.
• Client Write Key: Es la clave de cifrado para los datos van del cliente al servidor.
• Initialization Vectors: Utilizado para bloques de cifrado en estado CBC.
• Sequence Numbers: Cada parte mantiene una secuencia separada de números para los mensajes transmitidos y recibidos para cada conexión. Cuando una de las partes envía o recibe un mensaje de cambio Cipher Spec, la secuencia correspondiente es puesta a cero.

Otro tipo de información que puede ser intercambiada son las alertas, de las cuales se encarga la capa SSL Record Layer. Los mensajes de alerta poseen niveles de importancia y una descripción de las mismas. Algunas pueden llegar a provocar que una sesión sea cerrada. Como ocurre con otros mensajes, se encuentran encriptados y comprimidos.

Los mensajes de alerta pueden ser de los siguientes tipos

• Cierre: El cliente y el servidor deben saber cuando la conexión será cerrada para evitar un ataque por truncado.
• Error: Cuando un error es detectado, la parte que lo detectó envía una alerta a la otra parte.

Los parámetros de cifrado del estado de una sesión son generados por el protocolo SSL Handshake Protocol, el cual funciona por encima del SSL Record Layer. Cuando un cliente y un servidor inician una conexión, se ponen de acuerdo en la versión del protocolo y el algoritmo de cifrado, en ocasiones se autentican entre sí, y usan técnicas de cifrado de clave pública para generar los secrets compartidos. Estos procesos son llevados a cabo por el protocolo de hanshake, el cual puede ser resumido como: El cliente envía un mensaje Client Hello al cual el servidor debe responder con un mensaje Server Hello, en caso contrario ocurrirá un error fatal y la conexión fallará. Estos mensajes son usados para establecer los siguientes atributos: Protocol Version (versión del protocolo), Session ID (identificador de la sesión), Cipher Suite (conjunto de cifrado), y Compression Method (método de compresión). Adicionalmente, se intercambian dos valores generados al azar: ClientHello.random y ServerHello.random.
Luego, el servidor enviará sus certificados en caso que deba autenticarse y un mensaje de intercambio de claves si se le es requerido. Después de esto solicitará los certificados al cliente (sólo si es necesario), enviará un mensaje Server Hello Done, indicando que la fase de saludo inicial ha terminado y esperará la respuesta del cliente. El cliente enviará su certificado o un mensaje de alerta en caso de no poseerlo y su mensaje de intercambio de clave, cuyo contenido dependerá del algoritmo de clave pública seleccionado en la primera instancia. Si el cliente envió un certificado con posibilidad de ser firmado, un certificado de verificación firmado digitalmente será enviado en esta instancia.

Aquí, un mensaje de cambio de Cipher Spec es enviado por el cliente, guardándolo en estado pendiente. Inmediatamente después envía el mensaje terminado bajo los nuevos algoritmos, claves y secrets. En respuesta, el servidor enviará su propio mensaje de cambio de Cipher Spec, lo transferirá de pendiente a corriente y enviará el mensaje de terminado bajo la nueva Cipher Spec. En este punto, el proceso de handshake se ha completado y las partes pueden comenzar a intercambiar información.

Cuando el cliente y el servidor deciden retomar una sesión previa o duplicar una existente en lugar de negociar nuevos parámetros de seguridad, el flujo de mensajes es el siguiente:

El cliente envía un ClientHello usando la SessionID de la sesión que será retomada. Entonces el servidor controla su cache de sesiones y si la encuentra y está dispuesto a restablecerla bajo el estado especificado, enviará un ServerHello con el mismo valor de ServerID. En este punto, ambos cliente y servidor deben enviar mensajes de cambio de Cipher Spec proceder directamente a los mensajes terminados. Una vez que el proceso termina, el cliente y el servidor pueden comenzar a intercambiar datos de la capa de aplicación. Si no se encuentra la SessionID en el cache, el servidor genera una nueva SessionID y se realiza un proceso de handshake completo.

Los mensajes con datos de las aplicaciones son llevados por la capa SSL Record Layer en forma transparente y son fragmentados, comprimidos y encriptados de acuerdo al estado de la conexión.