PDF de programación - Tutorial habilitar SSL en Tomcat para Linux

Tutorial habilitar SSL en Tomcat para Linux


Objetivos:


El objetivo del presente tutorial es el de explicar cómo habilitar exitosamente el
soporte para SSL de Apache-Tomcat-5.5.x sobre un entorno Linux (también
presenta una introducción al funcionamiento de la tecnología SSL) de manera
sencilla, actualizada y en español.


Licencia:


Copyright © 2006 Alejandro, Barturen. Se permite, distribución y/o modificación
del presente documento bajo los términos de la GNU Free Documentation
License, Versión 1.1 o cualquier otra versión publicada por la Free Software
Foundation, requiriendo permanecer invariante el titulo.


Control de Cambios:


Fecha

20-05-2006

Versión

0.1

Autor
Alejandro Barturen

Detalle del cambio

Versión inicial

Créditos:


Gran parte de este trabajo consiste en el hilado, traducción y actualización de
información existente en Internet. Las fuentes son las siguientes:



http://tomcat.apache.org/tomcat-4.0-doc/ssl-howto.html
http://www.securityfocus.com/infocus/1818
http://www.javahispano.org/articles.article.action?id=19
http://docs.pushtotest.com/soapdocs/install/FAQ_Tomcat_SOAP_SSL.html
http://wiki.osportfolio.org/confluence/display/Technical/Apache+Tomcat+
mod_jk+Integration

También quiero agradecer al Ing. Mariano Mattío por el espacio y la paciencia; y
al Piojo (Pablo Díaz) por su tiempo y ayuda (y por prestarme su PC).


Contenidos

Parte 1: Introducción a SSL

SSL (Secure Sockets Layer) es el protocolo más popular cuando se trata de ofrecer
privacidad y confiabilidad para comunicaciones cliente-servidor sobre Internet. Por sí
mismo, SSL es conceptualmente muy simple: negocia las claves y los algoritmos
criptográficos entre ambos 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 puede también autentificar ambos lados a través del uso de
certificados.

SSL es un protocolo en capas y consiste de cuatro sub-protocolos:

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

La posición de estos protocolos, de acuerdo al modelo TCP/IP se ilustra en la siguiente
figura:



SSL
Handshake
Protocol

SSL Change
Cipher Spec
Protocol

SSL Record Layer

TCP

IP

Acceso a Red

Protocolos
asegurados

con SSL

Alert

SSL
Protocol

HTTP

LDAP
etc…

HTTP

SMTP
etc…

Capa de
Aplicación

Capa de

Transporte

Capa de
Internet
Capa de

Red

Como se muestra, SSL se encuentra en la capa de Aplicación del modelo TCP/IP, lo
que significa que SSL puede implementarse en casi cualquier sistema operativo que
soporte TCP/IP, sin necesidad de modificar el kernel del sistema o la pila TCP/IP. Esta
característica, le da a SSL una ventaja muy fuerte sobre otros protocolos, como IPSec,
que requieren soporte de kernel y una pila TCP/IP modificada. SSL también puede
fácilmente pasarse a través de firewalls y proxies, e incluso NAT, sin complicaciones.

¿Y cómo funciona SSL? El siguiente diagrama muestra, paso a paso, el proceso
(simplificado) de establecimiento de una nueva conexión entre un cliente
(normalmente un navegador Web) y un servidor (normalmente un servidor Web SSL).

Cliente SSL



Servidor SSL



Client Hello
una

establecer

Quiero
conexión
segura. Soporto <esta> versión de
SSL y <estos> cifradores

…

…

…

…

�



…

Server Hello

OK, inicialmente acepto tu petición. He
elegido <esta> versión de SSL y
<este> cifrador

 Certificado del Server (opcional)


Esta es mi clave pública (si no tengo
un certificado)

Clave del Server (opcional)



Pedido de Certificado del Cliente

(opcional)

Quiero autentificarte. Envíame
certificado firmado por <este> CA

tu


Certificado del Cliente (opcional) �

…

Clave del Cliente

Voy a enviarte más parámetros. Los
encriptaré con tu clave pública.

�

Cambio de Cifrado

El próximo mensaje que envíe estará
encriptado.

�
He concluido (encriptado) �



…

…

Fin del Server Hello

…

…

…

…

Cambio de cifrado

El próximo mensaje que envíe estará
encriptado

He concluido (encriptado)

Datos de Aplicación (encriptados) Datos de Aplicación (encriptados)

Como se observa en la figura, el proceso de establecimiento de cada nueva conexión
SSL comienza con el
luego,
opcionalmente, la autentificación del servidor (usando el SSL Handshake Protocol). Si
el handshake tiene éxito y ambos lados acuerdan una suite de encriptación y claves,
los datos de aplicación (por lo general HTTP, pero puede ser otro protocolo) pueden ser
enviados a través del túnel encriptado (usando el SSL Record Layer).

intercambio de parámetros de encriptación y

En realidad, el proceso es un poco más complicado. Para evitar handshakes
innecesarios, algunos de los parámetros de encriptación se guardan en caché. También
puede ocurrir que se envíen mensajes de alerta, y además las suites de encriptación
pueden ser cambiadas. De todas formas, haciendo a un lado los detalles de la
especificación SSL, la forma más común de llevar a cabo el proceso es bastante similar
a la presentada.

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

Aunque SSL es el mejor conocido y más popular, no es el único protocolo que ha sido
usado con el propósito de asegurar transacciones Web. Es importante saber que desde
la invención del SSL v1.0 (el cual nunca fue implementado) ha habido al menos cinco
protocolos que han jugado un rol más o menos importante asegurando el acceso a la
WWW, como vemos a continuación:

SSLv2.0

Lanzado por Netscape Communications en 1994. El propósito principal de este
protocolo era proveer seguridad para
la WWW.
Desafortunadamente, rápidamente se encontraron una serie de debilidades en
la versión inicial del protocolo SSL, lo que lo volvió poco confiable para su uso
comercial:

transacciones sobre

o Construcción MAC débil
o
o
o

Posibilidad de forzar a las partes a usar un cifrado más débil
Falta de protección para los handshakes
Posibilidad de efectuar ataques de truncado de paquetes

PCTv1.0

Desarrollado en 1995 por Microsoft. El Privacy Communication Technology
(PCT) v1.0 solucionaba algunas debilidades del SSL v2.0, y apuntaba a
reemplazar al SSL. De todas formas, este protocolo nunca alcanzó tanta
popularidad como el SSL v3.0.

SSLv3.0

Lanzado en 1996 por Netscape Communications. SSL v3.0 resolvió la mayoría
de los problemas del SSL v2.0, e incorporó muchas características del PCT.
Rápidamente se convirtió en el protocolo más popular para asegurar
comunicaciones sobre la WWW.

TLSv1.0

También conocido como SSLv3.1, fue publicado por la IETF en 1999. Este
protocolo está basado en SSL v3.0 y armoniza los enfoque de Netscape y
Microsoft. Es importante notar que aunque TLS está basado en SSL, no es
100% compatible con su predecesor. IETF realizó varios avances en la
seguridad, como usar HMAC en vez de MAC, usar una forma diferente de

calcular el “secreto compartido” y material de claves, agregar códigos de alerta
adicionales, quitar el soporte para la suite de encriptación Fortezza, y otros
más. Como resultado de estas mejoras, los protocolos no pueden interoperar
por completo, pero TLS tiene también un modo para operar como SSL v3.0.

WTLS

Versión "Mobile and wireless" del protocolo TLS que usa UDP como medio de
transporte. Está diseñado y optimizado para las capacidades de procesamiento
y anchos de banda menores de los dispositivos móviles con capacidad WAP.
WTLS fue introducido junto con el protocolo WAP v1.1, y fue desarrollado por el
WAP Forum. De todas formas, después de la introducción del protocolo WAP
v2.0, WTLS ha sido reemplazado por una versión modificada del protocolo TLS,
la cual es mucho más segura, principalmente porque no requiere desencriptado
y reencriptado del tráfico en el gateway WAP.

¿Y por qué el protocolo SSH (Secure Shell) no ha sido usado con el propósito de
proveer accesos seguros a la WWW? Hay algunas razones. En primer lugar, desde el
mismo comienzo TLS y SSL fueron diseñados para asegurar sesiones Web (HTTP),
mientras que SSH fue desarrollado para reemplazar a Telnet y FTP. SSL no hace más
que un handshake y luego establecer un túnel de encriptación, y SSH ofrece login de
consola, transferencia de archivos segura y soporte para múltiples esquemas de
autenticación (incluyendo passwords, claves públicas, Kerberos y más). Por otro lado,
SSL/TLS está basado en X.509v3 y certificados PKI (Public Key Infrastructure), lo cual
vuelve la distribución y gestión de credenciales de autenticación más fácil de llevar a
cabo. Para finalizar, estas y otras razones hacen a SSL/TLS más apropiado para
asegurar acceso a la WWW y formas similares de comunicación, incluyendo SMTP,
LDAP y otros, mientras que SSH es más conveniente para administración remota de
sistemas.

Para resumir, si bien varios protocolos “seguros” existen, de hecho, sólo dos de ellos
deberían usarse con le propósito de asegurar transacciones Web (al menos por ahora):
TLS v1.0 y SSL v3.0. Debido a debilidades conocidas en SSL v2.0 y al famoso “WAP
gap” en el caso de WTLS, el uso particular de estos protocolos no es recomendado.

Certificados

Para poder implementar autentificación SSL, un servidor Web debe tener asociado un
Certi