Obtención y luego distribución de un certificado SSL con comodín, ¿está bien?

Question

Obtención y luego distribución de un certificado SSL con comodín, ¿está bien?

#1 de Xander (2 votos)

2

Tengo una idea estúpida / loca sobre la que quería preguntar aquí. Probablemente no va a funcionar, pero tengo curiosidad.

La seguridad del navegador no permitirá sockets web inseguros (ws: //) desde páginas seguras (https: //) por varias razones. Me gustaría crear una aplicación que permita a los sitios web seguros acceder a muchas cosas diferentes a través de WS, y no quiero tener que crear certificados SSL para todo.

Entonces ...

Crazy hack: obtenga un certificado comodín para un dominio (por ejemplo, insecureashell.net) y configure los servidores DNS para que sirvan IP codificadas en nombres de host bajo ese dominio. Entonces, por ejemplo, 1.1.1.1.insecureashell.net se resolvería en 1.1.1.1.

Luego distribuya la clave privada para este certificado de comodín en todas partes, permitiendo que todas las aplicaciones se muestren como "seguras" desde los navegadores haciendo wss: //1.1.1.1.insecureashell.net/ connections.

Supongo que asumiendo esto viola algún tipo de política de manejo de certificados en las reglas https CA y obtendría este certificado revocado, pero no puedo encontrar nada al respecto. Tampoco puedo pensar en una razón por la que esto sea intrínsecamente malo, ya que solo se aplicaría a este dominio "falso SSL" específico y en ningún otro lugar de la red. Los encabezados CORS podrían usarse para permitir o denegar esto, etc.

Entonces, ¿por qué no funciona esto? :)

Editar: tal vez lo hará. Al parecer, existen certificados SSL privados para dominios que se resuelven a 127.0.0.1 en GitHub: enlace

tls web websocket

pregunta Adam Ierymenko 21.01.2017 - 00:00

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls web websocket

¿El software de las placas base UEFI es flasheable? Si es así, ¿hay alguna manera de prevenirlo? SSL benchmarking para Openssl [cerrado]

score 2 · Answer 1

El ejemplo específico que use no funcionará, ya que contiene múltiples niveles de subdominios, y los certificados de comodines solo son válidos para un solo nivel. Por lo tanto, un certificado para *.insecureshell.net funcionará para 1.insecureshell.net y 2.insecureshell.net , pero no para 1.1.insecureshell.net , y ciertamente no para 1.1.1.1.insecureshell.net . Sin embargo, eso no significa que una variación en esto no funcione, al menos suponiendo que usted realmente controle 1.1.1.1 y diga, 4.3.2.1 como ejemplos.

A los HTTPS y los certificados no les importa la dirección IP subyacente, solo les importa que el nombre del sujeto o un nombre alternativo del sujeto en el certificado coincidan con el nombre de host del sitio al que intenta conectarse. Para un certificado comodín, esto significa cualquier subdominio de un solo nivel. Por lo tanto, si controla esas dos direcciones IP y allí es donde está hospedando sus servicios, podría usar los siguientes subdominios: 1-1-1-1.insecureshell.net y 4-3-2-1.insecureshell.net para hacer referencia a ellos. Luego, simplemente tiene entradas de DNS para esos dos subdominios que apuntan a las direcciones IP 1.1.1.1 y 4.3.2.1 respectivamente, e instale su certificado de Wildcare en ambas máquinas. Realmente no hay razón para hacer esto, en general hablando. En su lugar, utiliza service1.insecureshell.net y service2.insecureshell.net , y tiene entradas de DSN para esos nombres apuntados a 1.1.1.1 y 4.3.2.1 , y una vez más, instale su certificado de comodín en ambas casillas, y eres bueno para ir