Un poco de contexto

Hace un tiempo atrás, Marissa Mayer, CEO de Yahoo!, indicó que todos los sitios de Yahoo! (y sus socios) correrían bajo HTTPS, como manera de proteger la privacidad de sus usuarios (leer comunicado). Dado que Autocosmos es un socio de Yahoo!, en su sección Autos para Hispanoamérica y el mercado hispano de Estados Unidos, debimos realizar las modificaciones necesarias a nuestras aplicaciones que corrieran bajo los dominios de Yahoo!. Este cambio involucraba la modificación de 3 aplicaciones, corriendo en 3 cloud services diferentes, sobre un total de 8 países, involucrando un total de 31 subdominios.

El desafío

La implementación fue un desafío por varios motivos:

1. Esta era la primera vez que los miembros de nuestro equipo hacían una implementación de HTTPS/SSL, por lo que tuvimos que buscar información sobre cómo hacerlo.
2. La implementación debía estar lista en menos de 30 días. Podíamos manejar los tiempos de la implementación, pero la creación del certificado y las validaciones dependían de Yahoo!, que sumado a nosotros, estaba haciendo lo mismo con todos sus otros socios de negocio.
3. Dada la estructura de subdominios utilizada por Autocosmos, no era posible utilizar un certificado de tipo wildcard *.autocosmos.yahoo.net.
4. Yahoo! validaría toda la seguridad (tanto de infraestructura como de la implementación) de todo el sitio, por lo que debíamos asegurarnos de no tener ningún otro tipo de problema de seguridad o sino la validación no sería satisfactoria.

Implementación

Paso 1: El certificado SSL

Características del certificado SSL

El certificado debe cumplir las siguientes caracterìsticas:

• El certificado debe contener una clave privada.
• El propósito del certificado debe ser Autenticación de servidor.
• El nombre de sujeto del certificado debe coincidir con el nombre de dominio utilizado para tener acceso al servicio.
• Requiere un tamaño mínimo de clave criptográfica de 2048 bits.

Obteniendo el certificado

Primera opción: certificado wildcard

Como mencioné anteriormente, por la estructura de subdominios de Autocosmos Yahoo, no es posible utilizar un certificado wildcard. Un certificado wildcard es aquel en cual se incluyen todos los subdominios de un dominio en particular dentro del mismo certificado, en la forma de *.autocosmos.yahoo.net. El problema es que los subdominios siguen el formato de:

• ar.autocosmos.yahoo.net
• ar.noticias.autocosmos.yahoo.net
• ar.galerias.autocosmos.yahoo.net
• ar.especiales.autocosmos.yahoo.net

Como se puede observar, estos subdominios pueden tener 2 niveles, y lamentablemente no se puede crear un certificado para *.*.autocosmos.yahoo.net, sólo se puede usar 1 nivel.

Segunda opción: certificado con múltiples SAN entries

Un certificado con múltiples SAN (Subject Alternative Name) entries es un certificado que incluye múltiples nombres alternativos dentro de un mismo certificado. Esto nos permite incluir los 31 subdominios en un único certificado.

Paso 2: La implementación en el cloud service

Para configurar HTTPS en un cloud service de Azure se deben modificar el archivo de definición del servicio (ServiceDefinition.csdef) y el archivo de configuración del servicio (ServiceConfiguration.cscfg): Configurar HTTPS/SSL en un cloud service de Azure.

Paso 3: Instalación del certificado en Azure

Para instalar el certificado en nuestro cloud service debemos primero exportarlo en formato PFX, y luego importarlo desde el portal de administración de Azure. Los pasos para realizarlo están explicados en este post: Subir un certificado SSL al portal de Azure para un Cloud Service.

Paso 4: Instalación del cloud service

Luego de haber configurado nuestro cloud service, y subido el certificado al portal, lo que imaginarán es que vamos a proceder a subir nuestro cloud service, pero lamentablemente este paso no es tan fácil como parece.

El problema está en que Azure no nos permite hacer un swap entre dos deployments que tengan diferente cantidad de endpoints (nuestro deployment de producción tiene solamente un endpoint HTTP, mientras que nuestro nuevo deployment, que iría en Staging, tiene 2: HTTP y HTTPS).

Entonces, ¿cómo solucionamos este problema? Lo que hicimos nosotros fue algo que normalmente no haríamos: hacer un deploy directo a producción. Al hacer un deployment directo a producción cada instancia es reemplazada, una a una, por la nueva instancia que contiene nuestros dos endpoints.

Igualmente, no queríamos arriesgarnos a poner todos los cambios que habíamos realizado directamente en producción, sin poder asegurarnos que todo funcionaba correctamente antes de afectar a nuestros usuarios, ya que si había que volver atrás los cambios, el tiempo para hacerlo sería muy alto. Gracias a que tenemos todo nuestro código versionado, lo que hicimos fue ir a la versión del código que estaba en ese momento en producción, agregar solamente el endpoint HTTPS, y ahí si reemplazar el código de producción.

Con este cambio realizado, pudimos llevar toda nuestra implementación a producción, pasando por una instancia de staging en la que comprobamos que todo funcionara correctamente antes de llevarla a nuestros usuarios.

Paso 5: Aumentando la seguridad del cloud service

Para asegurarnos de cumplir con todos los requisitos de seguridad exigidos por Yahoo! todavía nos faltaba un paso más: al correr el test del sitio de SSL Labs, la seguridad del certificado/configuración debía ser A, pero en el momento de la instalación, y siguiendo todos los pasos anteriores, el certificado daba un nivel A-. Esto se debía a que no se estaba usando forward secrecy, dado que, entre otras cosas, en ese momento Azure tenía habilitado SSL3, y estaba configurado para usarse antes que TLS 1.2.

Para solucionarlo, seguimos los pasos de este post (en inglés), y usamos la librería NWebsec, que nos provee de una serie de scripts PowerShell, que corren al crearse nuestras instancias, modificando parámetros de seguridad y dejando todo listo para que nuestro servicio funcione con los niveles más altos de seguridad.

SSL3 tiene vulnerabilidades conocidas, y actualmente está deshabilitado por defecto en Azure Websites, pero debe deshabilitarse a mano para cloud services y VMs. (En este post Microsoft explica cómo hacerlo si sólo nos interesa eso.)

Conclusión

Afortunadamente pudimos llevar toda la implementación a producción en tiempo y forma, siendo el primer partner de Latinoamérica en haber conseguido el objetivo.

Espero que les haya servido y los ayude a implementar HTTPS en sus cloud services!