¿Puede HTTP trabajar sin un certificado?

Recientemente, nuestro equipo de infraestructura le dijo a nuestro equipo de desarrollo que no necesita un certificado para https. Mencionaron que el único beneficio de comprar un certificado era dar al consumidor la tranquilidad de que se están conectando al sitio web correcto.

Esto va en contra de todo lo que asumí sobre https.

Leí Wikipedia y menciona que necesitas un certificado de confianza o un certificado autofirmado para configurar https.

¿Es posible configurar IIS para responder a https sin ningún certificado?

— marca
fuente

Puede encontrar que esto es solo un problema de comunicación. Su servidor probablemente tenga certificados autofirmados listos para usar. Por cierto, es esta advertencia la que debe evitar utilizando un certificado público de confianza: m86security.com/kb/article.aspx?id=13446 ESO puede ser aceptable en su entorno o no. Yo diría que es más que tranquilidad: ¡en un sitio web público es una señal de profesionalismo!

— Dan

Los certificados autofirmados le brindan cifrado, pero no puede protegerlo de los ataques del hombre en el medio, ya que recibe las mismas advertencias sobre certificados inválidos o no verificados para los autofirmados que para un tipo que intercepta el tráfico, descifrándolo, robar los datos y volver a cifrarlos para volver al cliente.

— Bart Silverstrim

"Los certificados autofirmados le proporcionan cifrado, pero no puede protegerlo de los ataques del hombre en el medio [...]", a menos que el usuario pueda confiar en esos certificados autofirmados explícitamente mediante algún mecanismo fuera de banda, que es solo es realmente posible para una pequeña base de usuarios que lo conoce a través de un mecanismo fuera de banda. Improbable, de hecho.

— Bruno

O si confían en él la primera vez, recibirán una advertencia si cambia en el futuro. Al igual que las firmas SSH, de verdad.

— mfinni

Técnicamente, SSL / TLS no necesita certificados para asegurar un canal de comunicaciones. De hecho, SSL / TLS puede usar otro mecanismo para asegurar el canal: certificados pgp, nombre de usuario / contraseña, claves precompartidas o "anónimo" (sin autenticación). Del mismo modo, SSL / TLS no garantiza el cifrado, hay muchos cifrados diferentes que puede usar, incluido "nulo" (sin cifrado). Y hay opciones similares para la autenticación de resumen. Entonces, eso es genial, pero qué programas usan: básicamente ninguno, definitivamente ningún software importante de servidor o navegador (todos requieren certificados).

— Chris S

Respuestas:

No. Debes tener un certificado. Puede ser autofirmado, pero debe haber un par de claves pública / privada para intercambiar la clave simétrica de la sesión entre el servidor y el cliente para cifrar los datos.

— Driftpeasant
fuente

Anonymous Diffie-Hellman, como se señaló en otra respuesta, permitió una conexión sin un certificado, pero las versiones modernas de OpenSSL generalmente se compilan sin ningún soporte para ADH.

— Brandon Rhodes

En resumen, no, pero puede haber casos sutiles dependiendo de cómo desee implementar el sistema.

HTTPS es HTTP sobre SSL / TLS, y puede usar SSL / TLS sin certificado o con certificados de otros tipos que no sean X.509 .

Conjuntos de cifrado anónimos: pueden proporcionar cifrado, pero sin autenticación. Más bien inútil en lo que respecta a la seguridad ... Para citar RFC 4346 : " Diffie-Hellman anónimo está fuertemente desaconsejado porque no puede evitar ataques de hombre en el medio " .
Claves precompartidas : tiene su propio mecanismo para verificar la identidad remota, pero la naturaleza compartida de las claves trae su propio conjunto de problemas (en particular, implementación limitada).
Conjuntos de cifrado Kerberos : el cliente puede verificar la identidad del servidor con el nombre principal de Kerberos.

Estrictamente hablando, la especificación HTTP sobre TLS dice lo siguiente:

En general, las solicitudes HTTP / TLS se generan al desreferenciar un URI. Como consecuencia, el nombre de host para el servidor es conocido por el cliente. Si el nombre de host está disponible, el cliente DEBE verificarlo con la identidad del servidor tal como se presenta en el mensaje de Certificado del servidor, para evitar ataques de intermediario.

Si el cliente tiene información externa sobre la identidad esperada del servidor, la verificación del nombre de host PUEDE omitirse. (Por ejemplo, un cliente puede estar conectándose a una máquina cuya dirección y nombre de host son dinámicos pero el cliente conoce el certificado que presentará el servidor). En tales casos, es importante reducir el alcance de los certificados aceptables tanto como sea posible en para evitar ataques de hombre en el medio. En casos especiales, puede ser apropiado que el cliente simplemente ignore la identidad del servidor, pero debe entenderse que esto deja la conexión abierta al ataque activo.

En resumen, está claramente destinado al uso con un certificado X.509 (hace referencia claramente a RFC 2459, posteriormente reemplazado por RFC 3280 y 5280: PKI con certificados X.509).

Puede haber un caso extremo cuando está utilizando conjuntos de cifrado Kerberos. Puede tener sentido tratar el ticket de servicio Kerberos del servidor podría suponerse que tiene el mismo propósito que el certificado X.509 en HTTPS habitual, para la verificación de la identidad de la parte remota. No se ajusta completamente a las reglas de RFC 2818 (aunque podría caer en " Si el cliente tiene información externa sobre la identidad esperada del servidor, la verificación del nombre de host PUEDE ser omitida "), pero no sería completamente absurdo Dicho esto, no creo que los navegadores habituales admitan los conjuntos de cifrado TLS Kerberos en general (un número puede admitir Kerberos a través de la autenticación SPNEGO, pero eso no está relacionado). Además, esto también solo funcionaría en un entorno en el que sea adecuado usar Kerberos.

" [Darle al consumidor la tranquilidad de que se están conectando al sitio web correcto " es en realidad uno de los requisitos clave para asegurar la comunicación entre ellos y su servidor. Utilice un certificado que puedan verificar, con las convenciones de nomenclatura apropiadas (RFC 2818 o más recientemente RFC 6125).

— Bruno
fuente

NO PUEDE usar https sin ningún certificado. Necesita comprar un certificado de confianza o crear uno autofirmado para la prueba. Parte de la configuración de su servidor web para usar https es apuntarlo a los archivos clave correctos. Por supuesto, esto se aplica a todos los servidores web, no solo a iis.

— Khaled
fuente

Para probar si su OpenSSL puede admitir conexiones sin certificado, ejecute openssl ciphersy busque un ADHprotocolo como ADH-AES256-SHA: si ese protocolo está presente, técnicamente puede configurar una conexión sin ningún certificado involucrado.

— Brandon Rhodes