Certificado autofirmado para el servidor VPN SSTP

Navega tus respuestas
1

Estoy desarrollando una solución VPN personalizada que debe ser compatible con SSTP para clientes de Windows. Para esto, mi servidor necesita autenticarse usando un certificado durante el protocolo de enlace SSL. Como es habitual, Windows examinará su conjunto local de certificados de confianza y decidirá si acepta o rechaza la conexión.

Dado que este proyecto actualmente no tiene el presupuesto para pagar un certificado oficial (de Verisign o quien sea), me gustaría usar uno autofirmado por ahora. Desafortunadamente, esto significa que tendré que pedir a mis usuarios que instalen este certificado para que Windows pueda autenticar correctamente mi servidor.

Tengo dos preguntas específicas sobre este escenario:

  • Si les pido a los usuarios que instalen este certificado autofirmado en su tienda de "Autoridades de Certificación de Raíces Confiables", ¿esto representa un riesgo de seguridad (de CUALQUIER tipo) para ellos? Por ejemplo, si alguien tuviera que retener la clave privada de mi certificado, ¿podría usarla para hacerse pasar por otra entidad (como Google o Facebook o un banco) simplemente firmando su propio certificado para esos nombres y haciendo que apunte a mi certificado raíz, ¿o solo pueden hacerse pasar por mi servidor?

  • Si es así, ¿hay alguna manera de decirle a Windows que solo use mi certificado para autenticar mi servidor SSTP, pero no para autenticar ningún otro https u otras conexiones? Preferiblemente, esta sería una acción que los usuarios pueden realizar o verificar fácilmente en lugar de solo una configuración dentro del certificado.

pregunta Markus A. 29.07.2017 - 01:23
fuente

2 respuestas

1

No desea crear un certificado de CA de distribución. Esto haría que asumiera demasiada responsabilidad, ya que cualquiera que controle su clave privada de CA estará en medida de interceptar la mayoría de las comunicaciones TLS de todos sus clientes al falsificar certificados de terceros sobre la marcha.

Lo que desea distribuir es solo un certificado de usuario final autofirmado con el nombre común que coincide con su nombre de host como lo ven los clientes. Dicho certificado será seguro de distribuir ya que solo se podrá utilizar para asegurar la comunicación con su servidor.

Obviamente, solo distribuya su certificado público (por lo general, este es un archivo .pem o .crt ), mantenga privadas sus claves privadas.

    
respondido por el WhiteWinterWolf 29.07.2017 - 11:50
fuente
1

A menos que incluya su clave privada o algo como parte del paquete de certificado para un certificado de CA raíz confiable que implemente en los hosts de Windows; la clave privada probablemente se comprometa de alguna otra manera.

Dicho esto, si se trata de un certificado de firma intermedio o interno basado en CA; alguien que capture un certificado de firma podría usarlo y realizar un "intermediario" para realizar el descifrado ssl 'de confianza' en la red de la víctima o crear sitios de phishing falsificados u otro contenido malicioso para el navegador para sus usuarios.

Si su certificado autofirmado es puramente un certificado público solo para autenticación de confianza; en general, debería estar bien siempre que un atacante decida no tomarlo y falsificar su servidor web.

En cualquiera de los casos, si esto sucede en un entorno de prueba / desarrollo como prueba de concepto, es probable que tenga más problemas de qué preocuparse con respecto a su seguridad cibernética.

Si estás realmente paranoico acerca de la autenticación alternativa; puede agregar requisitos para que los clientes tengan un certificado del lado del cliente que su servidor conoce (autenticación mutua) a través de TLS. También hay controles de compensación donde tal vez su infraestructura de seguridad de red solo permita el acceso al tráfico SSTP a través de SSL / TLS en una VLAN específica o una asociación de IP / MAC estática.

    
respondido por el SCIS Security 29.07.2017 - 06:59
fuente

Lea otras preguntas en las etiquetas

Autenticación del cliente durante TLS / SSL y ataques de reproducción Nombre del archivo de enlace simbólico: ¿posible aprovechamiento?