Escenario: HTTPs e SNI - Historial de revisiones

Joselv: /* Fortificando HTTPS */

2026-02-09T11:10:29Z

Fortificando HTTPS

Joselv: /* Conclusión */

2026-02-09T11:08:11Z

Conclusión

Mostrar los cambios

Joselv: /* Apache con https e SNI */

2026-02-09T10:58:49Z

Apache con https e SNI

Joselv: /* Apache con https e SNI */

2026-02-09T10:58:26Z

Apache con https e SNI

Joselv: /* SNI */

2026-02-09T10:57:11Z

SNI

Joselv: /* SNI */

2026-02-09T10:56:36Z

SNI

Mostrar los cambios

Joselv en 10:48 9 feb 2026

2026-02-09T10:48:48Z

Joselv: Página creada con « = 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…»

2026-02-09T10:47:34Z

Página creada con « = 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…»

Página nueva

= 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
<pre>
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
</pre>

== 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:
<pre>
$ 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
</pre>

@@ Línea 521: / Línea 521: @@
 = Fortificando HTTPS =
-Os últimos anos foron un desastre para os protocolos SSL/TLS ó aparecer varias vulnerabilidades que fixeron que a gran maioría das versións e implementacións destes protocolos estén consideradas a día de hoxe como 'mortas'. BEAST, CRIME, Heartbleed, Reverse Heartbleed, POODLE, FREAK e Logjam son algunhas das vulnerabilidades máis salientables dende o ano 2011 e lograron que a día de hoxe unicamente sexa considerado seguro TLS. No sitio web de seguridade security by default hai un interesante artigo onde se fala destas vulnerabilidades e do estado do SSL nos concellos, onde revisaban varias webs empregando a solución online SSL Server Test de Qualys SSL Labs.
+Os últimos anos foron un desastre para os protocolos SSL/TLS ó aparecer varias vulnerabilidades que fixeron que a gran maioría das versións e implementacións destes protocolos estén consideradas a día de hoxe como 'mortas'.
 Debido a todos os problemas indicados, novas vulnerabilidades que aparecen e a unha maior concienciación en materia de seguridade, a día de hoxe as configuracións SSL/TLS dos servidores web empezan a vir con valores por defecto seguros, e en moitos casos pouco ou nada hai que retocar. A pesar disto, é unha boa práctica revisar o estado da configuración e modificala para fortificala. Para axudarnos nesta tarefa existen ferramentas que automatizan a análise e proporcionan indicacións das accións a levar:

@@ Línea 101: / Línea 101: @@
 Non todos, pero a gran maioría dos navegadores, servidores e proxys web soportan SNI e na [https://en.wikipedia.org/wiki/Server_Name_Indication seguinte URL] pode verse unha listaxe listaxe concreta.
-= Apache con https e SNI =
+= Apache con HTTPS e SNI =
 == Sitio por defecto ==

@@ Línea 180: / Línea 180: @@
 Fig. Acceso por http e https ó sitio por defecto
-Sitio www.probas1.example
+==Sitio www.probas1.example ==
 Segundo o enunciado, o acceso ó dominio www.probas1.example é unicamente a través de http; polo tanto, creamos un arquivo de configuración para acceder por http a www.probas1.example:
@@ Línea 246: / Línea 247: @@
 Fig. Acceso por https ó sitio www.probas1.example
-Sitio www.probas2.example
+== Sitio www.probas2.example ==
 Segundo o enunciado, o acceso ó dominio www.probas2.example será tanto de http coma de https; polo tanto teremos que crear dous arquivos de configuración, un para acceder por http e outro para acceder por https. Ademais, o acceso á carpeta segredo do sitio web ten que ser por https, bloqueándose o acceso no caso de facelo por http. Obrigar a usar https para acceder a un recurso pode facerse a través da directiva de configuración SSLRequireSSL.
@@ Línea 395: / Línea 396: @@
 Fig. Acceso autorizado por https á carpeta segredo do sitio www.probas2.example
-Sitio www.probas3.example
+== Sitio www.probas3.example ==
 Creación do arquivo de configuración para http. Emprégase a directiva Redirect para reenviar ós clientes que acceden por http a unha conexión segura https:

@@ Línea 507: / Línea 507: @@
 Fig. Acceso por https ó sitio www.probas3.example
-= SNI =
+= Conclusión =
-Como conclusión, vemos que é posible acceder a diferentes sitios correndo no mesmo socket (IP-porto) por https grazas a SNI e o envío por parte do cliente do nome de dominio na extensión SNI do TLS. Na seguinte imaxe podemos ver o paquete Client Hello durante o establecemento da canle cifrada para https://www.probas2.example
+Vemos que é posible acceder a diferentes sitios correndo no mesmo socket (IP-porto) por https grazas a SNI e o envío por parte do cliente do nome de dominio na extensión SNI do TLS.
 SNI probas2.example

← Revisión anterior		Revisión del 10:48 9 feb 2026
Línea 60:		Línea 60:
	ff02::2 ip6-allrouters		ff02::2 ip6-allrouters
	</pre>		</pre>
		+
		+	= 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 [https://en.wikipedia.org/wiki/Server_Name_Indication seguinte URL] pode verse unha listaxe listaxe concreta.