Tutorial habilitar SSL en Tomcat para Linux

Objetivos:
El objetivo del presente tutorial es el de explicar cmo habilitar exitosamente el soporte para SSL de Apache-Tomcat-5.5.x sobre un entorno Linux (tambin presenta una introduccin al funcionamiento de la tecnologa SSL) de manera sencilla, actualizada y en espaol.

Licencia:
Copyright 2006 Alejandro, Barturen. Se permite, distribucin y/o modificacin del presente documento bajo los trminos de la GNU Free Documentation License, Versin 1.1 o cualquier otra versin publicada por la Free Software Foundation, requiriendo permanecer invariante el titulo.

Control de Cambios:
Fecha 20-05-2006 Versin Autor 0.1 Alejandro Barturen Detalle del cambio Versin inicial

Crditos:
Gran parte de este trabajo consiste en el hilado, traduccin y actualizacin de informacin 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

Tambin quiero agradecer al Ing. Mariano Matto por el espacio y la paciencia; y al Piojo (Pablo Daz) por su tiempo y ayuda (y por prestarme su PC).

Contenidos Parte 1: Introduccin a SSL

SSL (Secure Sockets Layer) es el protocolo ms 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 criptogrficos entre ambos lados de una comunicacin, y establece un tnel encriptado a travs del cual otros protocolos (como HTTP) pueden ser transportados.

Opcionalmente, SSL puede tambin autentificar ambos lados a travs del uso de certificados. SSL es un protocolo en capas y consiste de cuatro sub-protocolos:

SSL SSL SSL SSL

Handshake Protocol Change Cipher Spec Protocol Alert Protocol Record Layer

La posicin 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 SMTP etc

HTTP

Capa de Aplicacin Capa de Transporte Capa de Internet Capa de Red

SSL Record Layer TCP IP Acceso a Red

Como se muestra, SSL se encuentra en la capa de Aplicacin 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 caracterstica, 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 tambin puede fcilmente pasarse a travs de firewalls y proxies, e incluso NAT, sin complicaciones. Y cmo funciona SSL? El siguiente diagrama muestra, paso a paso, el proceso (simplificado) de establecimiento de una nueva conexin entre un cliente (normalmente un navegador Web) y un servidor (normalmente un servidor Web SSL).

Cliente SSL Client Hello Quiero establecer una conexin segura. Soporto <esta> versin de SSL y <estos> cifradores

Servidor SSL

Server Hello OK, inicialmente acepto tu peticin. He elegido <esta> versin de SSL y <este> cifrador Certificado del Server (opcional) Clave del Server (opcional) Esta es mi clave pblica (si no tengo un certificado) Pedido de Certificado del Cliente (opcional) Quiero autentificarte. Envame tu certificado firmado por <este> CA Fin del Server Hello Cambio de cifrado El prximo mensaje que enve estar encriptado He concluido (encriptado)

Certificado del Cliente (opcional) Clave del Cliente Voy a enviarte ms parmetros. Los encriptar con tu clave pblica. Cambio de Cifrado El prximo mensaje que enve estar encriptado. He concluido (encriptado)

Datos de Aplicacin (encriptados)

Datos de Aplicacin (encriptados)

Como se observa en la figura, el proceso de establecimiento de cada nueva conexin SSL comienza con el intercambio de parmetros de encriptacin y luego, opcionalmente, la autentificacin del servidor (usando el SSL Handshake Protocol). Si el handshake tiene xito y ambos lados acuerdan una suite de encriptacin y claves, los datos de aplicacin (por lo general HTTP, pero puede ser otro protocolo) pueden ser enviados a travs del tnel encriptado (usando el SSL Record Layer). En realidad, el proceso es un poco ms complicado. Para evitar handshakes innecesarios, algunos de los parmetros de encriptacin se guardan en cach. Tambin puede ocurrir que se enven mensajes de alerta, y adems las suites de encriptacin pueden ser cambiadas. De todas formas, haciendo a un lado los detalles de la especificacin SSL, la forma ms comn 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 ms popular, no es el nico protocolo que ha sido usado con el propsito de asegurar transacciones Web. Es importante saber que desde la invencin del SSL v1.0 (el cual nunca fue implementado) ha habido al menos cinco protocolos que han jugado un rol ms o menos importante asegurando el acceso a la WWW, como vemos a continuacin: SSLv2.0 Lanzado por Netscape Communications en 1994. El propsito principal de este protocolo era proveer seguridad para transacciones sobre la WWW. Desafortunadamente, rpidamente se encontraron una serie de debilidades en la versin inicial del protocolo SSL, lo que lo volvi poco confiable para su uso comercial: o Construccin MAC dbil o Posibilidad de forzar a las partes a usar un cifrado ms dbil o Falta de proteccin 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 mayora de los problemas del SSL v2.0, e incorpor muchas caractersticas del PCT. Rpidamente se convirti en el protocolo ms popular para asegurar comunicaciones sobre la WWW. TLSv1.0 Tambin 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 cdigos de alerta adicionales, quitar el soporte para la suite de encriptacin Fortezza, y otros ms. Como resultado de estas mejoras, los protocolos no pueden interoperar por completo, pero TLS tiene tambin un modo para operar como SSL v3.0. WTLS Versin "Mobile and wireless" del protocolo TLS que usa UDP como medio de transporte. Est diseado y optimizado para las capacidades de procesamiento y anchos de banda menores de los dispositivos mviles con capacidad WAP. WTLS fue introducido junto con el protocolo WAP v1.1, y fue desarrollado por el WAP Forum. De todas formas, despus de la introduccin del protocolo WAP v2.0, WTLS ha sido reemplazado por una versin modificada del protocolo TLS, la cual es mucho ms segura, principalmente porque no requiere desencriptado y reencriptado del trfico en el gateway WAP.

Y por qu el protocolo SSH (Secure Shell) no ha sido usado con el propsito de proveer accesos seguros a la WWW? Hay algunas razones. En primer lugar, desde el mismo comienzo TLS y SSL fueron diseados para asegurar sesiones Web (HTTP), mientras que SSH fue desarrollado para reemplazar a Telnet y FTP. SSL no hace ms que un handshake y luego establecer un tnel de encriptacin, y SSH ofrece login de consola, transferencia de archivos segura y soporte para mltiples esquemas de autenticacin (incluyendo passwords, claves pblicas, Kerberos y ms). Por otro lado, SSL/TLS est basado en X.509v3 y certificados PKI (Public Key Infrastructure), lo cual vuelve la distribucin y gestin de credenciales de autenticacin ms fcil de llevar a cabo. Para finalizar, estas y otras razones hacen a SSL/TLS ms apropiado para asegurar acceso a la WWW y formas similares de comunicacin, incluyendo SMTP, LDAP y otros, mientras que SSH es ms conveniente para administracin remota de sistemas. Para resumir, si bien varios protocolos seguros existen, de hecho, slo dos de ellos deberan usarse con le propsito 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 autentificacin SSL, un servidor Web debe tener asociado un Certificado para cada interfaz externa (direccin IP) que acepte conexiones seguras. La teora detrs de esto indica que un servidor debe proveer algn tipo de seguridad, razonablemente suficiente, sobre el hecho de que su dueo es quien uno piensa que es, particularmente antes de recibir algn tipo de informacin sensible. Una explicacin ms profunda de los Certificados escapa a este documento, pero podemos pensar en ellos como Documentos de Identidad Digitales para una direccin de Internet, donde consta con qu empresa est asociada el sitio, as como informacin bsica de contacto del dueo o administrador del sitio en cuestin. Este Documento de Identidad Digital est criptogrficamente firmado por su dueo, lo cual lo vuelve particularmente difcil de falsificar. Para sitios involucrados en e-

commerce, o cualquier otro tipo de transaccin en la que la autentificacin sea importante, por lo general se compran certificados de algn 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 confe en la validez de un certificado porque confa en el CA que lo emiti. Veamos algunos campos incluidos en los certificados: Versin Nmero de Serie Algoritmo de la firma Nombre del emisor Perodo de validez Nombre del sujeto Informacin de la clave pblica del sujeto Extensiones Se utiliza para distinguir entre las diferentes versiones de certificado, actualmente existe la 1, 2 y 3. Un valor nico que emite el CA, asociado a un certificado sin ambigedad (es el nmero de serie!). El algoritmo de encriptacin (RSA, AES, etc.) utilizado para firmar el certificado, junto con sus parmetros. El nombre X.509 del CA. Fechas desde - hasta que indican el lapso de tiempo durante el cual el certificado es vlido. Identifica el usuario a quin se remite el certificado. La clave pblica del sujeto y un identificador de algoritmo utilizado, junto con sus parmetros. Campos de extensin. Sirven para aadir funcionalidad extra, fueron incluidos en la versin 3. Abarca todos los dems campos del certificado. Contiene el cdigo hash de los otros campos, cifrados con la clave privada del CA. Incluye el identificador del algoritmo de la firma.

Firma

Certificados Auto-firmados
En algunos casos, la autentificacin 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 trfico, por ejemplo. En una situacin como la anterior, comprar un certificado de un CA puede resultar oneroso, afectando la relacin costo-beneficio de usar SSL. Afortunadamente, Java nos provee de una herramienta por lnea de comando relativamente simple, llamada keytool, la cual nos permite crear certificados auto-firmados, existen otras herramientas gratuitas que tambin nos permiten hacer esto, como OpenSSL. Los certificados auto-firmados son certificados generados por cualquiera y que no han sido oficialmente registrados por algn CA bien conocido y que, por lo tanto, no proveen garantas 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, slo cuando se lo utiliza en un servidor Web stand-alone. Si usamos Tomcat principalmente como un contenedor Servlet/JSP detrs 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. Tpicamente, este servidor negociar toda la funcionalidad relacionada con SSL, y luego pasar los requerimientos destinados al contenedor Tomcat slo despus de haber desencriptado estos requerimientos. De la misma forma, Tomcat devolver respuestas en texto claro, las cuales sern 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 aplicacin 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 instalacin 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 propsito, tambin es interesante notar que no es necesario descargar ningn paquete adicional para que Tomcat soporte SSL, ya que esta funcionalidad viene incluida en la versin que instalamos con anterioridad.

Paso 1: Instalacin de OpenSSL

El proceso a seguir para instalar OpenSSL en su sistema, puede variar ligeramente de acuerdo a la distribucin que utilice. En nuestro caso (Ubuntu Linux v5.10), lo hicimos de la siguiente manera: apt-get install openssl

De todas formas, no debera presentar ninguna dificultad. La ltima versin, 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, debera 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 continuacin, deber generar una clave para firmar el certificado, indicando el algoritmo de encriptacin a utilizar, el nombre del archivo en el que se guardar la clave y el nivel de encriptacin. 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 especificacin (X.509) y el tiempo de validez del certificado (un ao 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 organizacin, su pas, 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, debera 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 seccin 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 dems parmetros como le resulte conveniente. keystoreType debe ser igual a PKCS12.

La etiqueta

Paso 4: Comprobacin
Inicie Tomcat. Luego, apunte su browser a la direccin: https://localhost:6443 Note la s despus 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 autofirmado. Si lo desea, puede examinar el certificado. Ver algo parecido a esto:

Note cmo la clave pblica del servidor se enva en el certificado. Para establecer una conexin, el cliente elegir una clave de sesin (esto se hace automticamente), luego la encriptar con la clave pblica que estamos viendo y la enviar al servidor. A partir de ese momento, tanto cliente como servidor comparten una clave de sesin, la cul se utilizar para abrir el tnel encriptado que es el fundamento de SSL. Habiendo examinado el certificado, resta aceptarlo para ver una pantalla como sta:

Este error tambin 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 informacin de contacto. Aceptando una vez ms, ahora s, debera poder acceder al sitio:

Por fin! Note el cono del candado, ste indica que la conexin con el sitio es segura. Si lo desea, puede hacer doble click sobre l para obtener un poco ms de informacin, debera ver una pantalla como esta:

Donde podr confirmar que la autentificacin ha sido exitosa, con lo cual se da por finalizada esta seccin.

Conclusin:
En este tutorial, se ha cubierto, paso a paso, una forma de activar el soporte SSL en Apache-Tomcat-5.5. Tambin se ha presentado una manera sencilla de generar certificados y se ha presentado una introduccin a SSL; todo esto en espaol 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).