SSL

Definición

Secure Sockets Layer (SSL) es el protocolo más conocido que ofrece privacidad y confiabilidad para la
comunicación cliente-servidor a través de Internet. SSL por sí mismo es conceptualmente muy simple: se
negocia los algoritmos de cifrado y las claves entre los dos lados de una comunicación, y establece un túnel
encriptado a través del cual otros protocolos (como HTTP) pueden ser transportados. Opcionalmente, SSL
también puede autenticar ambos lados de la comunicación mediante el uso de certificados.

SSL es un protocolo de capas y se compone de cuatro sub-protocolos:

• SSL Handshake Protocol

• SSL Change Cipher Spec Protocol
• SSL Alert Protocol
• SSL Record Layer

La posición de los protocolos anteriores de acuerdo con el modelo TCP / IP ha sido ilustrado en el siguiente
diagrama en la Figura 1

Figura 1

Como muestra el diagrama de arriba, SSL se encuentra en la capa de aplicación del modelo TCP / IP. Dada
esta característica, SSL se puede implementar en casi cualquier sistema operativo que soporte TCP / IP, sin la
necesidad de modificar el núcleo del sistema o la pila TCP / IP. Esto le da una ventaja SSL muy fuerte sobre
otros protocolos como IPSec (IP Security Protocol), lo que requiere apoyo del núcleo y una modificada por
la pila TCP / IP. SSL también puede transmitirse fácilmente a través de firewalls y servidores proxy, así como
a través de NAT (Network Address Translation) sin problemas.

¿Cómo trabaja SSL?

En el siguiente diagrama, figura 2, se muestra proceso paso a paso de crear una nueva conexión SSL entre el
cliente (normalmente un navegador web) y el servidor (generalmente un servidor web SSL).
 Figura 2

1. Cliente: Quiero establecer una conexión segura. Soporto <esta> versión de SSL y <este> sistemas de
cifrado.
2. Servidor: Ok. Inicialmente acepto la solicitud. He escogido esta versión de SSL y este conjunto de
cifrado.
3. Servidor: Certificado del servidor (opcional) .
4. Servidor: Clave de servidor Exchange (opcional). Aquí está mi clave pública (si no tengo
certificado).
 5. Servidor: Solicitud de certificados de cliente (opcional). Quiero que se autentique. Deseo recibir el
certificado firmado la CA.
6. Servidor: Server Hello done.
7. Cliente: Certificado (opcional).
8. Cliente: Intercambio de claves. Te envío más parámetros. Voy a cifrar estos con tu clave pública.
9. Cliente: Certificate Verify: voy a firmar algo de información mediante el uso de la clave privada que
corresponda a mi certificado. Así, usted puede estar seguro de que soy el propietario del certificado.
10. Cliente: Cambio de especificaciones de cifrado: el siguiente mensaje de mi parte se enviará cifrado.
11. Cliente: Terminado.
12. Servidor: Cambio de especificaciones de cifrado: el siguiente mensaje de mi parte se enviará cifrado.
13. Servidor: Terminado.

Como se puede ver en la figura 2, el establecimiento de una nueva conexión SSL comienza con los
parámetros de encriptación de intercambio y luego opcionalmente la autenticación del servidor (utilizando el
SSL Handshake Protocol). Si el apretón de manos es exitosa y que ambas partes acuerden un conjunto de
cifrado común y claves de cifrado, los datos de aplicación (generalmente HTTP, pero puede ser otro
protocolo) se pueden enviar a través del túnel cifrado (utilizando el SSL Record Layer).

En realidad, el proceso anterior es en realidad un poco más complicado. Para evitar apretones de manos
innecesarios, algunos de los parámetros de encriptación se almacenan en caché. Sin embargo,
independientemente de los detalles especificación de SSL, la forma más común de este proceso funciona
realmente es muy similar a la anterior.

SSL, PCT, TLS y WTLS (pero no SSH)

A pesar de ser el más conocido y el más popular, SSL no es el único protocolo que se ha utilizado con el fin
de asegurar las transacciones web. Es importante saber que desde la invención de SSL v1.0 (que nunca ha
sido puesto en libertad, por cierto) se han producido al menos cinco protocolos que han desempeñado un
papel más o menos importante para asegurar el acceso a la World Wide Web, como vemos a continuación:

• SSL v2.0: liberado por Netscape Communications en 1994. El objetivo principal de este protocolo es
garantizar la seguridad de las operaciones de la World Wide Web. Por desgracia, muy rápidamente
una serie de deficiencias de seguridad se encontraron en esta primera versión del protocolo SSL, por
lo que es menos confiable para uso comercial.

• PCT v1.0: desarrollado en 1995 por Microsoft. Privacidad Tecnología de la Comunicación (PCT)
v1.0 se refirió a algunas debilidades de SSL v2.0, y tenía por objeto sustituir SSL. Sin embargo, este
protocolo no ha ganado en popularidad tanto como SSL v3.0

• SSL v3.0: lanzado en 1996 por Netscape Communications. SSL v3.0 ha resuelto la mayoría de los
problemas de SSL v2.0, e incorporó muchas de las características del PCT. Se ha convertido
rápidamente en el protocolo más popular para garantizar la comunicación a través de WWW.

• TLS v1.0 (también conocida como SSL v3.1): publicado por el IETF en 1999 (RFC 2246). Este
protocolo está basado en SSL v3.0 y el PCT y armoniza tanto tanto los enfoques de Netscape y los
de Microsoft. Es importante notar que aunque TLS está basado en SSL, no es 100% compatible con
su predecesor.

• WTLS: versión del protocolo TLS que utiliza el protocolo UDP como transportista. Se ha diseñado
y optimizado para el ancho de banda menor y menor capacidad de procesamiento de WAP habilitado
dispositivos móviles. WTLS se introdujo con el protocolo WAP 1.1, y fue lanzado por el Foro WAP.
Sin embargo, después de la introducción de la AMP 2,0 protocolo WTLS ha sido reemplazado por
una versión de perfil del protocolo TLS, que es mucho más seguro - sobre todo porque no es
necesario para el descifrado y re-codificación del tráfico en la puerta de enlace WAP .
¿Por qué el SSH (Secure Shell) protocolo no se ha utilizado con el fin de proporcionar un acceso seguro a la
World Wide Web? Hay algunas razones por qué no. En primer lugar, desde el inicio de TLS y SSL fueron
diseñados para asegurar web (HTTP) períodos de sesiones, mientras que el SSH se sangría para reemplazar a
Telnet y FTP. SSL no hace más que apretón de manos y se establece túnel cifrado, y al mismo tiempo que
ofrece la consola de acceso SSH, la transferencia segura de archivos, y soporte para múltiples esquemas de
autenticación (incluidas las contraseñas, claves públicas, Kerberos, y más). Por otra parte, SSL / TLS se basa
en los certificados X.509v3 y PKI, que hace que la distribución y la gestión de las credenciales de
autenticación mucho más fácil de realizar. Por lo tanto, estas y otras razones hacen SSL / TLS más adecuada
para garantizar acceso a la WWW y formas similares de comunicación, incluyendo SMTP, LDAP y otros -,
mientras que SSH es más conveniente para la gestión del

En resumen, aunque existen vario protocolos "seguros", sólo dos de ellos debe ser utilizado con el fin de
asegurar las transacciones web (al menos por el momento): TLS 1.0 y SSL v3.0. Ambos se denominarán
simplemente como SSL / TLS. Debido a las debilidades conocidas de SSL v2.0, y la famosa "brecha de
WAP" en caso de WTLS, el uso de estos protocolos otros deberían ser evitados o al menos minimizado.

Configuración Apache2 - SSL

En ésta sección veremos cómo configurar Apache 2.0 con SSL / TLS, utilizando el módulo mod_ssl. Como
primer paso, teniendo instalado el servidor web Apache2, deberemos instalar y habilitar el modulo ssl:

# apt-get install libapache-mod-ssl

# a2enmod ssl

Para poder publicar un sitio HTTPS deberemos de realizar los siguientes pasos:

1. Generar o importar un certificado.

2. Configurar un virtualhost para que utilice las opciones SSL.

Generar o importar un certificado

Creamos el directorio donde se alojarán los certificados:

# mkdir /etc/apache2/ssl

Configurar un virtualhost para que utilice las opciones SSL.

<VirtualHost *:443>
ServerName earth.my.flat

DocumentRoot /var/www/
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>