Existe un problema de base cuando se quieren disponer múltiples servicios web identificados por nombre desde un mismo servidor (virtual hosts) y se pretende dar acceso a los mismos a través del protocolo HTTPS, como se explica en name-based HTTPS servers.
El problema radica en que, para establecer la conexión SSL de base que requiere el protocolo HTTPS, se debe contar con el certificado del servidor. Pero, en el caso de poseer múltiples servicios web alojados en el mismo servidor, el servidor no sabría cuál certificado aportar hasta recibir el nombre de host que desea ser accedido lo que resulta imposible dado que la conexión SSL aún no está establecida.
Contenido
Server name indication
La situación planteada anteriormente posee una solución real que pasa por utilizar cifrado TLS y soportar la extensión Server Name Indication (RFC 6066), que actualmente se encuentra implementada en la mayoría de los servidores y navegadores actuales. Por lo que, de hecho, este problema ya estaría solucionado en la mayoría de los casos prácticos.
Pero existen condiciones en las cuales esta extensión no se encuentra implementada, como ser en servicios web que no son de navegación (particularmente se me ha presentado este problema con el cliente Web de Mercurial) o con firewalls y proxies que intervienen en tráficos cifrados pero que no son capaces de transportar esta extensión entre los clientes y los servicios a los que acceden (ver Defect Number 74969 de Release Notes for Cisco IronPort AsyncOS 7.7.0 for Web).
Para estos casos existen los siguientes workarounds que, si bien no son capaces de resolver la totalidad de la casuística, podrían llegar a satisfacer las necesidades específicas de algún problema en particular.
Workarounds
Certificados multi-dominio
Si todos los nombres de los servicios a ser prestados por el servidor pueden englobarse dentro de un dominio de nivel superior, puede obtenerse un certificado común para todos los sites contenidos en el servidor. Existen certificados certificados para una lista de dominios concreta o para un wildcard del tipo *.domain.org
.
- Ventajas
-
- Existiendo un único certificado común a todos servicios, este puede ser entregado directamente por el servidor ante cualquier acceso HTTPS sabiendo que es válido para todos los casos.
- Desventajas
-
- Los nombres de los servicios deben todos quedar incluidos dentro de un mismo dominio para poder ser incluidos dentro de un mismo certificado.
- Los certificados multidominio son más difíciles de obtener y más caros que los de dominios individuales.
- La administración de un certificado para un conjunto de dominios implica la obtención de un nuevo certificado cada vez que un dominio sea agregado o eliminado.
Múltiples direcciones IP
Si el servidor puede obtener una dirección IP distinta para cada servicio, resulta sencillo asociar cada certificado a una dirección (la dirección IP de destino se encuentra en la cabecera IP y por lo tanto fuera de los datos cifrados por SSL).
- Ventajas
-
- Esta es la solución más transparente posible ya que una vez configurado el servidor no requiere de ninguna característica especial por parte del cliente o la comunicación.
- Desventajas
-
- Las direcciones IP son un recurso escaso y costoso y obtener una dirección IP distinta para cada servicio seguro a implementar puede ser que no sea factible en todos los casos.
Redireccionamiento de puertos
Esta solución es una variante de la solución anterior para el caso en que no sea posible obtener más direcciones IP para el servidor. Montando cada site sobre un puerto TCP distinto, como el puerto de destino se encuentra en la cabecera IP y por lo tanto no está cifrada, resulta sencillo para el servidor discriminar el servicio que se desea alcanzar basándose en este dato.
- Ventajas
-
- Esta solución puede implementarse sin necesidad de ningún recurso especial en el servidor como ser direccionamiento múltiple o certificados multi-dominio.
- Desventajas
-
- Al tener que utilizarse puertos fuera del standard, las URLS deberán contemplar este parámetro (transformándose en
https://site.domain.org:port/path
) para acceder al servicio. - Existen instalaciones en las que los puertos fuera del standard se encuentran bloqueados por razones de seguridad impidiendo la comunicación.
- Al tener que utilizarse puertos fuera del standard, las URLS deberán contemplar este parámetro (transformándose en