Directorio de artículos
- 1. Construcción del entorno previo
- 2. Pruebe las condiciones efectivas de SNI (tiempo)
- 3. El impacto de los certificados en el SNI
- 4. Prueba de discriminación de número de puerto
- 5. Resumir el mecanismo de funcionamiento del SNI
- 6. El mecanismo SNI pasa por alto la exploración del encabezado del host
En el artículo anterior , a través de una serie de análisis, descubrimos una vulnerabilidad de inyección SQL basada en la inyección de campo de host en un sistema de clúster bajo la arquitectura LNMP. Al resolver el problema de derivación de HOST, ofrecemos tres soluciones. Separe por dos puntos, escriba dos veces el campo de host y use el mecanismo SNI.
Después de la prueba, la división de dos puntos es factible, y una versión superior de nginx devuelve el campo de host escrito dos veces como 400, que no se puede usar. El último es el mecanismo SNI.
SNI (Indicación de nombre de servidor), definida en RFC 4366, es una tecnología para mejorar SSL/TLS y está habilitada en SSLv3/TLSv1. Permite que el cliente envíe la información del Host solicitada cuando inicia una solicitud de protocolo de enlace SSL (específicamente, la fase ClientHello en la solicitud SSL del cliente), para que el servidor pueda cambiar al dominio correcto y devolver el certificado correspondiente.
Sabemos que el mecanismo de certificado existe para cifrar el tráfico de comunicaciones y evitar las escuchas de terceros. Al configurar varios sitios web en el mismo host, se utilizará la tecnología de host virtual y los certificados correspondientes a cada sitio web también son diferentes. Entonces, ¿qué certificado se utilizará para comunicarse cuando el usuario establezca una conexión con el servidor por primera vez? Al principio, se utilizó el certificado predeterminado, y luego, para satisfacer tales necesidades, RFC introdujo el mecanismo SNI.En la etapa inicial del protocolo TLS, es decir, cuando el cliente envía su propio mensaje de saludo al cliente, el campo de host es agregado a él para que el servidor distinga los propósitos del sitio web. Seleccione el certificado correspondiente.
Luego, el certificado encripta la comunicación tanto para el cliente como para el servidor, es decir. Una vez que la comunicación posterior se encuentra descifrada con un certificado determinado. No hay necesidad de hacer más juicios, y el paquete de datos se puede enviar directamente al sitio web correspondiente. Es decir, después de que se establezca una comunicación https estable, el middleware del servidor no necesitará analizar el encabezado del host e implementar directamente el análisis direccional a través del certificado.
Entonces, tendremos una serie de pensamientos.
Primero: ¿Se activará el mecanismo SNI todo el tiempo? Host virtual https único -> múltiples hosts virtuales https
Segundo: ¿Controlar el certificado como una variable y probar el impacto del certificado en el análisis de tráfico? —> Demostrar que la clave privada del certificado se utiliza para distinguir el tráfico
Tercero: ¿Controlar el número de puerto como una variable y probar el impacto del número de puerto en el análisis del tráfico?
1. Construcción del entorno previo
En este caso, debemos preparar dos conjuntos completos de hosts virtuales https de análisis nginx para la prueba. y un certificado de servidor y clave privada.
#1.双证书准备
#1.创建证书目录
[root@blackstone nginx]# mkdir certificate
[root@blackstone nginx]# cd certificate/
#2.生成私钥 - 要求你输入这个key文件的密码。给nginx使用。每次reload nginx配置时候都要验证这个PAM密码。
openssl genrsa -des3 -out ssl.key 4096
openssl genrsa -des3 -out sslb.key 4096
#3.生成CA证书文件 -- 此处为了区分证书，我们只好开两份CA证书相当于两个机构的认证
openssl req -new -key ssl.key -out aaa.csr
openssl req -new -key sslb.key -out bbb.csr
#4.利用CA证书签名生成服务器身份证书 - 证书签发有效期365天
openssl x509 -req -days 365 -in aaa.csr -signkey ssl.key -out aaa.crt
openssl x509 -req -days 365 -in bbb.csr -signkey sslb.key -out bbb.crt
#5.检查生成情况 - 此时包含我们自己的私钥，自己的证书.crt文件，以及csrCA证书
[root@blackstone certificate]# ll
total 32
-rw-r--r-- 1 root root 1895 Feb 10 23:34 aaa.crt
-rw-r--r-- 1 root root 1724 Feb 10 23:32 aaa.csr
-rw-r--r-- 1 root root 1907 Feb 11 00:52 bbb.crt
-rw-r--r-- 1 root root 1728 Feb 11 00:51 bbb.csr
-rw-r--r-- 1 root root 3311 Feb 11 00:50 sslb.key
-rw-r--r-- 1 root root 3311 Jan 11 21:24 ssl.key
implementación web
[root@blackstone www]# mkdir -p /var/www/aaa
[root@blackstone www]# mkdir -p /var/www/bbb
[root@blackstone www]# echo 'this is aaa.com' > /var/www/aaa/index.html
[root@blackstone www]# echo 'this is bbb.com' > /var/www/bbb/index.html
Recuerde modificar el archivo host de esta máquina: C:\Windows\System32\drivers\etc
192.168.2.169 www.bbb.com
192.168.2.169 www.aaa.com
2. Pruebe las condiciones efectivas de SNI (tiempo)
1. Host virtual https único
server {
listen 443 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
}
Reinicie nginx, use un navegador para acceder y realice un análisis de captura de paquetes.
#后面的所有重启都建议直接把nginx关闭，彻底重启
[root@blackstone www]# /usr/local/nginx/sbin/nginx -s quit
Enter PEM pass phrase:
[root@blackstone www]# /usr/local/nginx/sbin/nginx
Enter PEM pass phrase:
Se puede ver que el nombre de host se envía al servidor dentro del mensaje de saludo del cliente.
Por lo tanto, enviar el nombre de host es un comportamiento espontáneo del navegador de versión superior y no requiere ninguna condición de activación. El navegador enviará activamente el nombre del servidor para admitir el mecanismo SNI. Es decir, no es necesario configurar el mecanismo SNI, siempre que el servidor lo admita, se puede utilizar.
3. El impacto de los certificados en el SNI
3.1 Ambas partes utilizan el mismo certificado:
server {
listen 443 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
}
server {
listen 443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
Prueba de acceso:
Se puede lograr el desvío.
3.2 Ambas partes utilizan certificados y claves privadas diferentes
En este momento, tratamos de distinguir entre certificados y claves privadas:
server {
listen 443 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
}
server {
listen 443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/bbb.crt;
ssl_certificate_key /usr/local/nginx/certificate/sslb.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
Pruebe el efecto de acceso de nuevo:
[root@blackstone certificate]# /usr/local/nginx/sbin/nginx -s reload
Enter PEM pass phrase:
Enter PEM pass phrase:
Cada uno puede recibir su propio certificado y establecer su propia comunicación.
4. Prueba de discriminación de número de puerto
4.1 Distinción de número de puerto, distinción de certificado:
server {
listen 8443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/bbb.crt;
ssl_certificate_key /usr/local/nginx/certificate/sslb.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
server {
listen 8444 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
Resultados de la prueba:
[root@blackstone certificate]# vim ../conf/nginx.conf
[root@blackstone certificate]# /usr/local/nginx/sbin/nginx -s reload
Enter PEM pass phrase:
Enter PEM pass phrase:
Se puede ver que los certificados se enviaron a los dos clientes de host virtual respectivamente. Realice la diferenciación del tráfico
4.2 Se distingue el número de puerto, pero no se distingue el certificado:
server {
listen 8443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
server {
listen 8444 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
Si el efecto no es obvio en el medio, puede reiniciar el servicio nginx, porque puede haber archivos de caché cuando el servicio está siempre activo.
[root@blackstone nginx]# /usr/local/nginx/sbin/nginx -s quit
Enter PEM pass phrase:
Enter PEM pass phrase:
[root@blackstone nginx]# /usr/local/nginx/sbin/nginx
Enter PEM pass phrase:
Enter PEM pass phrase:
Prueba de nuevo para ver el efecto:
El servidor pasa el mismo certificado dos veces para realizar la comunicación. Logre un acceso completo de descarga de alojamiento virtual.
5. Resumir el mecanismo de funcionamiento del SNI
A través de las pruebas anteriores, encontramos que independientemente del mismo número de puerto, los certificados son diferentes. Lograr el efecto de transferencia diferenciada de certificados. O el certificado es diferente, el número de puerto también es diferente para realizar la configuración del host virtual en el entorno de prueba. SNI siempre puede encontrar el host de destino con precisión, incluso cuando nuestros certificados son los mismos.
De hecho, esto no es enigmático en absoluto. Repasemos el proceso de comunicación TSL que hemos aprendido antes:
El primer protocolo de enlace: el cliente envía el número de versión del protocolo, el número aleatorio y el paquete de soporte El
segundo protocolo de enlace: el servidor envía el número aleatorio, el número de versión y confirma el paquete de soporte. Al mismo tiempo, envía el certificado del servidor para indicar tu identidad (equivale a enviar un DNI).
El tercer protocolo de enlace: el cliente recibe el certificado, realiza la verificación de identidad y utiliza la clave pública extraída del certificado para cifrar y transmitir una nueva cadena de números aleatorios pre_master al servidor después de la verificación. En este momento, el cliente y el servidor comparten tres números aleatorios, el número aleatorio del cliente, el número aleatorio del servidor y pre_master. Por lo tanto, según los tres números aleatorios, ambas partes pueden calcular una clave simétrica cifrada común para la comunicación. Una vez que se genera la clave de sesión, el cliente envía un "Cambiar especificación de cifrado" para indicarle al servidor que comience a usar el cifrado para enviar mensajes. Envíe otro mensaje de "Mensaje de protocolo de enlace cifrado (finalizado)", haga un resumen de todos los datos enviados anteriormente y luego cífrelo con la clave de sesión (secreto maestro), deje que el servidor haga una verificación para verificar si la comunicación cifrada está disponible y la información previa del apretón de manos Si se ha manipulado a la mitad.
El cuarto protocolo de enlace: el servidor realiza la misma operación, enviando mensajes de "Cambiar especificación de cifrado" y "Mensaje de protocolo de enlace cifrado". Si ambas partes verifican que el cifrado y el descifrado están bien, el protocolo de enlace se completa oficialmente.
El último es usar la clave de sesión para comunicarse entre las dos partes.
Es decir, la clave en el proceso de comunicación cliente-servidor está recién negociada. Tal clave con identificación única. Luego, a través del mecanismo SNI, el nombre del servidor enviado cuando el cliente envía el paquete de saludo del cliente por primera vez determina qué host virtual visitar. En la comunicación posterior, el host virtual correspondiente se puede encontrar naturalmente a través de la clave de descifrado. Esto completa el mecanismo SNI completo.
Se comprende que este certificado de servidor diferente se puede configurar para diferentes servidores virtuales.
6. El mecanismo SNI pasa por alto la exploración del encabezado del host
El entorno en el que se produce dicha omisión es obvio, debe ser un servidor nginx configurado con SSL.
Algunos estudiantes han planteado preguntas antes, pensando que solo se configura un host SSL virtual con el puerto 443. ¿Es difícil distinguir si se debe a que nuestra solicitud se transfiere al host virtual de procesamiento de puerto 443 predeterminado o si hemos evitado con éxito dicho mecanismo de detección? Siguiendo el entorno 3.2, realizamos más pruebas en él:
Host virtual 6.1 SSL con el mismo puerto
#注意那个server在上面，在配置文件里就默认的是默认虚拟主机
server {
listen 443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
server {
listen 443 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
}
Bajo el mismo número de puerto y diferentes condiciones de certificado, después de modificar el archivo de host, salta al host virtual predeterminado de bbb.com. Fallo de derivación
6.2 Hosts virtuales SSL con diferentes puertos
server {
listen 443 ssl;
server_name www.bbb.com;
ssl_certificate /usr/local/nginx/certificate/bbb.crt;
ssl_certificate_key /usr/local/nginx/certificate/sslb.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/bbb;
index index.html index.htm;
}
}
server {
listen 8443 ssl;
server_name www.aaa.com;
ssl_certificate /usr/local/nginx/certificate/aaa.crt;
ssl_certificate_key /usr/local/nginx/certificate/ssl.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root /var/www/aaa;
index index.html index.htm;
}
}
Efecto de acceso:
probar de nuevo:
esta vez no hay salto al valor predeterminado, lo que indica que es factible.
6.3 Resumen
La condición para que SNI pase por alto el host para que surta efecto es vincular solo un host virtual SSL en un solo puerto. Porque vimos en 6.1 que cuando varios hosts SSL están vinculados al mismo servidor con el mismo puerto, todas las solicitudes se enviarán a la página predeterminada. Si la vulnerabilidad está en la página predeterminada, está bien, si no. No se puede omitir mediante SNI.
Pero al mismo tiempo, si el servidor es un único host virtual SSL configurado con el puerto 443, entonces se puede omitir el encabezado HOST del mecanismo SNI.