Escenario: HTTPs e SNI

Introdución

Esquema de rede do escenario.

Configuración do escenario

Configuración do server

Tómase como punto de partida o servidor web ó remate do escenario anterior. Un punto a ter en conta á hora de implantar esta práctica é que van convivir no mesmo servidor sitios web https cun socket propio e sitios web https compartindo o mesmo socket grazas a SNI.

Se vos resulta complicado ou con vistas a montalo en prácticas co alumnado e para distinguir as dúas técnicas preferides que non convivan no mesmo server, o único que habería que facer é eliminar as IPs adicionais e deshabilitar os sitios web de www.tenda1.example e www.tenda2.example co comando a2dissite.

Para deshabilitar os sitios tendaprobas, tanto por http como por https:

$ sudo a2dissite www.tenda1.example.conf
$ sudo a2dissite www.tenda1.example-ssl.conf 
$ sudo a2dissite www.tenda2.example.conf
$ sudo a2dissite www.tenda2.example-ssl.conf 
$ sudo systemctl reload apache2
$ sudo apache2ctl -S

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:80                   127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex watchdog-callback: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

Configurar a resolución DNS dende os clientes

Para poder acceder ós sitios web dende os clientes hai que configurar a resolución dns. Igual que no escenario anterior hai dúas solucións:

• Instalar un servidor dns cunha zona para cada un dos dominios probas1.example, probas2.example e probas3.example
• Nos equipos cliente poden engadirse as entradas correspondentes ós hosts www.probas1.example, www.probas2.example e www.probas3.example no arquivo hosts.

Aínda que non é a mellor solución, por ser un escenario de probas escolleuse a segunda por ser a máis rápida e sinxela.

A modo de exemplo así quedaría o arquivo hosts dun cliente linux:

$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       lxd
192.0.2.11      www.tenda1.example
192.0.2.12      www.tenda2.example
192.0.2.13      www.probas1.example www.probas2.example www.probas3.example

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

SNI

No escenario anterior cada dominio accesible por https tiña un socket (IP/porto) adicado. As razóns hai que buscalas no funcionamento do protocolo http e na forma de establecemento da canle cifrada SSL/TLS. Supoñamos por un momento que un servidor web teña unha única IP para todos os dominios aloxados; por exemplo, www.tendaprobas1.com e www.tendaprobas2.com. Nesta situación, cando o servidor web Apache recibe unha solicitude http dun cliente, revisa a cabeceira Host da solicitude para ver cal dos dominios aloxados (virtualhosts baseados en nome) é o que lle interesa ó cliente. Desta forma, pode consultar o arquivo de configuración correcto e recuperar a información pedida polo cliente. Na seguinte imaxe pode observarse unha solicitude http onde na cabeceira Host especifícase que o dominio de interese é www.tendaprobas1.com:

Mensaxe http coa cabeceira Host especificando o dominio www.tendaprobas1.com

Fig. Cabeceira HTTP coa cabeceira Host indicando o sitio web de interese

Se usamos https é de supoñer que o cliente debería recibir o certificado asociado ó dominio polo que pregunta cando se vaia a establecer a canle SSL/TLS. Pero aquí é onde aparece o problema; xa que durante as mensaxes intercambiadas para crear a canle SSL/TLS, non se especifica o dominio e a canle cifrada crease antes de que o cliente envíe a solicitude http coa cabeceira Host. Polo tanto, o servidor Apache non sabe que certificado usar por que non sabe que dominio concreto quere visitar o cliente:

SSL/TLS sen SNI

Fig. Establecemento dunha canle SSL/TLS e a problemática do certificado a usar

Se cada dominio está nunha IP (ou socket) diferente, este problema desaparece ó non poder equivocarse o servidor, xa que o único que ten que facer o servidor é usar o certificado do sitio web asociado á IP onde contacta o cliente:

SSL/TLS sen SNI pero con varias IPs

Fig. Establecemento de canles SSL/TLS usando sockets adicados a cada sitio web

A solución un dominio-unha IP funciona, pero desaproveita direccións. Para superar esta limitación creouse unha extensión de TLS chamada SNI (Server Name Indication), onde o cliente durante o establecemento da canle TLS indica o dominio ó que se quere conectar; permitindo desta forma que o servidor web seleccione o certificado axeitado.

SSL/TLS con SNI

Fig. Establecemento da canles SSL/TLS usando SNI

A continuación pode verse nos seguintes paquetes capturados co sniffer Wireshark o establecemento da conexión entre o cliente e o servidor. No primeiro podemos ver como o cliente envía o nome de dominio na extensión SNI do TLS e no segundo a resposta do servidor enviando o certificado correspondente:

Establecemento SSL/TLS con extensisón SNI

Fig. O cliente establece a conexión e indica o dominio de interese (www.tendaprobas1.com) na extensión SNI

Establecemento SSL/TLS con extensisón SNI - resposta do servidor

Fig. Resposta do servidor enviando o certificado axeitado para www.tendaprobas1.com

SNI fai que un servidor poida utilizar múltiples certificados nunha mesma dirección IP e número de porto, permitindo que múltiples sitios web seguros (https) poidan ser servidos nunha mesma IP sen que todos os sitios compartan un certificado común. Este concepto é equivalente ó concepto de host virtuais baseados en nome de http/1.1 pero para https. SNI non está limitado a https, estando dispoñible para calquera outro servizo que funcione sobre TLS.

Non todos, pero a gran maioría dos navegadores, servidores e proxys web soportan SNI e na seguinte URL pode verse unha listaxe listaxe concreta.