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 Versión Autor Detalle del cambio 20-05-2006 0.1 Alejandro Barturen 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:

Protocolos asegurados

con SSL

SSL Handshake Protocol

SSL Change Cipher Spec Protocol

SSL Alert Protocol

HTTP LDAP etc…

SSL Record Layer

HTTP SMTP etc…

Capa de Aplicación

TCP Capa de

Transporte

IP Capa de Internet

Acceso a Red 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 Quiero establecer una 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)

… Clave del Server (opcional)

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

… Pedido de Certificado del Cliente

(opcional) Quiero autentificarte. Envíame tu certificado firmado por <este> CA

… Fin del Server Hello

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) � …

… 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 intercambio de parámetros de encriptación y 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).

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 transacciones sobre 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:

o Construcción MAC débil o Posibilidad de forzar a las partes a usar un cifrado más débil o Falta de protección para los handshakes o 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 Certificado para cada interfaz externa (dirección IP) que acepte conexiones seguras. La teoría detrás de esto indica que un servidor debe proveer algún tipo de seguridad, razonablemente suficiente, sobre el hecho de que su dueño es quien uno piensa que es, particularmente antes de recibir algún tipo de información sensible. Una explicación más profunda de los Certificados escapa a este documento, pero podemos pensar en ellos como “Documentos de Identidad Digitales” para una dirección de Internet, donde consta con qué empresa está asociada el sitio, así como información básica de contacto del dueño o administrador del sitio en cuestión.

Este “Documento de Identidad Digital” está criptográficamente firmado por su dueño, lo cual lo vuelve particularmente difícil de falsificar. Para sitios involucrados en e-

commerce, o cualquier otro tipo de transacción en la que la autentificación sea importante, por lo general se compran certificados de algún CA (Certificate Authority) que sea bien conocido (es decir, confiable) como VeriSign o Thawte. Estos certificados pueden verificarse computacionalmente, de hecho, el CA responderá por la autenticidad de los certificados que emita, de manera tal que uno confíe en la validez de un certificado porque confía en el CA que lo emitió.

Veamos algunos campos incluidos en los certificados:

Versión Se utiliza para distinguir entre las diferentes versiones de certificado, actualmente existe la 1, 2 y 3.

Número de Serie Un valor único que emite el CA, asociado a un certificado sin ambigüedad (es el número de serie!).

Algoritmo de la firma El algoritmo de encriptación (RSA, AES, etc.) utilizado para firmar el certificado, junto con sus parámetros.

Nombre del emisor El nombre X.509 del CA.

Período de validez Fechas “desde - hasta” que indican el lapso de tiempo durante el cual el certificado es válido.

Nombre del sujeto Identifica el usuario a quién se remite el certificado.

Información de la clave pública del sujeto

La clave pública del sujeto y un identificador de algoritmo utilizado, junto con sus parámetros.

Extensiones Campos de extensión. Sirven para añadir funcionalidad extra, fueron incluidos en la versión 3.

Firma

Abarca todos los demás campos del certificado. Contiene el código hash de los otros campos, cifrados con la clave privada del CA. Incluye el identificador del algoritmo de la firma.

Certificados Auto-firmados

En algunos casos, la autentificación no es tan importante. Un administrador puede desear, simplemente, estar seguro de que los datos transmitidos y recibidos por el servidor son privados y que no pueden ser comprometidos por alguien que estuviera escuchando el tráfico, por ejemplo.

En una situación como la anterior, comprar un certificado de un CA puede resultar oneroso, afectando la relación costo-beneficio de usar SSL. Afortunadamente, Java nos provee de una herramienta por línea de comando relativamente simple, llamada keytool, la cual nos permite crear certificados “auto-firmados”, existen otras herramientas gratuitas que también nos permiten hacer esto, como OpenSSL.

Los certificados auto-firmados son certificados generados por cualquiera y que no han sido oficialmente registrados por algún CA bien conocido y que, por lo tanto, no proveen garantías sobre su autenticidad. De nuevo, esto puede o no ser importante, depende de las necesidades de cada uno.

SSL y Tomcat

Es importante resaltar que configurar Tomcat para sacar ventaja de SSL es necesario, generalmente, sólo cuando se lo utiliza en un servidor Web stand-alone. Si usamos Tomcat principalmente como un contenedor Servlet/JSP detrás de otro servidor Web, como Apache o Microsoft IIS, por lo general es preferible configurar el servidor Web primario para manejar las conexiones SSL de los clientes. Típicamente, este servidor negociará toda la funcionalidad relacionada con SSL, y luego pasará los requerimientos destinados al contenedor Tomcat sólo después de haber desencriptado estos requerimientos. De la misma forma, Tomcat devolverá respuestas en texto claro, las cuales serán encriptadas antes de retornarlas al navegador Web del usuario. En este entorno, Tomcat sabe que las comunicaciones entre el servidor Web primario y el cliente ocurren sobre un medio seguro (porque la aplicación necesita poder preguntar sobre esto), pero no participa en el encriptado-desencriptado propiamente dicho.

Parte 2: Habilitar SSL en Tomcat

Anteriormente, hemos publicado un tutorial sobre la instalación de Tomcat y su Administration Tool sobre Linux. Retomaremos el proceso a partir del punto en el que terminó el documento antes mencionado. Cabe destacar que si bien podemos generar certificados auto-firmados con el keytool de java, preferimos utilizar OpenSSL con este propósito, también es interesante notar que no es necesario descargar ningún paquete adicional para que Tomcat soporte SSL, ya que esta funcionalidad viene incluida en la versión que instalamos con anterioridad.

Paso 1: Instalación de OpenSSL

El proceso a seguir para instalar OpenSSL en su sistema, puede variar ligeramente de acuerdo a la distribución que utilice. En nuestro caso (Ubuntu Linux v5.10), lo hicimos de la siguiente manera:

apt-get install openssl

De todas formas, no debería presentar ninguna dificultad. La última versión, a la fecha, es OpenSSL v0.9.7i. Puede encontrar ayuda en los siguientes sitios:

• http://linux.wku.edu/~lamonml/web/apache/apachessl/chap3.html • http://www.ibrtses.com/linux/openssl.html • http://helpdesk.umd.edu/topics/security/156/

Paso 2: Habilitar Tomcat para SSL (con OpenSSL)

En primer lugar, debería crear una carpeta dentro de CATALINAHOME (variable de entorno que indica el directorio en donde esta instalado Tomcat) en la cual guardar los

certificados y claves que genere (nosotros la llamamos keyContainer) y posicionarse en ella, recuerde que deberá ser root para realizar este procedimiento.

A continuación, deberá generar una clave para firmar el certificado, indicando el algoritmo de encriptación a utilizar, el nombre del archivo en el que se guardará la clave y el nivel de encriptación. En nuestro caso, elegimos RSA, miclave.pem y 2048 bits, respectivamente:

openssl genrsa -out miclave.pem 2048

Luego, necesitará crear un certificado firmado con la clave, indicando la especificación (X.509) y el tiempo de validez del certificado (un año a partir de la fecha actual, por ejemplo):

openssl req -new -x509 -key miclave.pem -out micert.pem -days 365

La consola le solicitará que ingrese su nombre, el de su organización, su país, etc. Complete con los datos que correspondan.

A esta altura, habrá creado una clave (miclave.pem) y un certificado auto-firmado (micert.pem).

Como el certificado está en formato PEM, necesitará convertirlo a PKCS12 para que se ajuste a Tomcat, indicando el nombre final (micert.p12):

openssl pkcs12 -export -in micert.pem -inkey miclave.pem -out micert.p12 -name tomcat

Recuerde que deberá introducir un keystore password, ya que Tomcat lo espera. En nuestro caso, será “miclavesecreta”.

Si todo ha salido bien, debería ver una pantalla parecida a esta:

Paso 3: Configurar el conector SSL

Este paso es el último, pero es muy importante. Deberá editar el archivo $CATALINAHOME/conf/server.xml, y configurar el conector SSL. Busque la sección “Connector” y verifique que quede parecida a lo siguiente:

<Connector port="6443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" debug="0" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreType="PKCS12" keystoreFile="/usr/apache-tomcat-5.5.17/keyContainer/micert.p12" keystorePass="miclavesecreta"/>

Defina el puerto y demás parámetros como le resulte conveniente. La etiqueta “keystoreType” debe ser igual a PKCS12.

Paso 4: Comprobación

Inicie Tomcat. Luego, apunte su browser a la dirección:

https://localhost:6443

Note la “s” después de http, indica que estará accediendo a un servidor seguro. El puerto puede ser 6443, o el que usted haya elegido, el puerto en el cual Tomcat escuchará peticiones SSL.

Si todo esta en orden, verá una pantalla parecida a la siguiente:

Este error es perfectamente normal, recuerde que el certificado en uso es auto-firmado. Si lo desea, puede examinar el certificado. Verá algo parecido a esto:

Note cómo la clave pública del servidor se envía en el certificado. Para establecer una conexión, el cliente elegirá una clave de sesión (esto se hace automáticamente), luego la encriptará con la clave pública que estamos viendo y la enviará al servidor. A partir de ese momento, tanto cliente como servidor comparten una clave de sesión, la cuál se utilizará para abrir el túnel encriptado que es el fundamento de SSL.

Habiendo examinado el certificado, resta aceptarlo para ver una pantalla como ésta:

Este error también es esperable, ya que el nombre de dominio en el certificado (“ale”) no coincide con el del sitio que intenta autentificar (“localhost”), esto es importante para prevenir los ataques de “phishing”. Note de qué manera el browser insta al usuario a comunicarse con el administrador, esto es posible porque en el certificado se incluye información de contacto. Aceptando una vez más, ahora sí, debería poder acceder al sitio:

Por fin! Note el ícono del candado, éste indica que la conexión con el sitio es segura. Si lo desea, puede hacer doble click sobre él para obtener un poco más de información, debería ver una pantalla como esta:

Donde podrá confirmar que la autentificación ha sido exitosa, con lo cual se da por finalizada esta sección.

Conclusión: En este tutorial, se ha cubierto, paso a paso, una forma de activar el soporte SSL en Apache-Tomcat-5.5. También se ha presentado una manera sencilla de generar certificados y se ha presentado una introducción a SSL; todo esto en español y con versiones actuales de los productos involucrados. Espero haber cubierto los objetivos planteados, y que alguien encuentre este tutorial de utilidad. Saludos, Alejandro Barturen (ale.barturen@gmail.com).