¿Podemos tener https sin certificados?

5

Pido disculpas por adelantado si estoy malinterpretando algo, pero ¿es posible tener protocolos de comunicación cifrados (https, supongo) sin recurrir a un sistema de certificación?

¡Esta pregunta viene con respecto a la iniciativa EFF / Mozilla para "cifrar en todas partes!" Entiendo que los certificados verifican / identifican / pero ¿es posible y / o razonable construir un protocolo https sin usar identidades verificadas? El ejemplo más obvio es comunicarse con sitios certificados autofirmados, pero ¿existen otras situaciones en las que podría valorar el cifrado de la comunicación más que la identidad de quién se está comunicando?

    
pregunta sharedphysics 20.11.2014 - 06:01
fuente

5 respuestas

6

Usted puede tener SSL / TLS sin certificados. Esto se admite en el TLS standard : las suites de cifrado "DH_anon" no implican ningún certificado. Pero debe recordar que un TLS no autenticado de este tipo es inherentemente débil contra los atacantes activos, ya que no pueden evitar la suplantación del cliente o servidor (o ambos al mismo tiempo, lo que se denomina a ataque Man-in-the-Middle ).

La mayoría de los navegadores web desactivan las suites de cifrado DH_anon debido a la vulnerabilidad inherente a MitM. Puede tener el mismo efecto conceptual con un certificado SSL autofirmado, que puede producir usted mismo sin hablar con ningún CA. Por supuesto, los mismos navegadores web mostrarán las "advertencias de miedo", casi por la misma razón.

Desde el punto de vista de la EFF, cuyo archienemigo es la NSA, las suites de cifrado generalizadas de DH_anon tendrían sentido, ya que se sabe que Evil Spy Agencies ™ prefiere las escuchas pasivas (ya que no deja huellas incriminatorias). Las escuchas pasivas son derrotadas por DH_anon. Sin embargo, para la mayoría de las otras personas, la mayor amenaza no es la intrusión gubernamental, sino los estafadores mundanos que intentan separarte de tu dinero, y estos no dudan en ejecutar ataques MitM completos, por ejemplo. con falsos puntos de acceso WiFi.

La iniciativa Let's Encrypt tiene como objetivo hacer que la emisión de certificados sea gratuita (como en "sin dinero") y automatizada, mientras se mantiene un poco de esfuerzo en "verificar" que quien obtenga el certificado tenga cierto grado de control sobre el dominio designado. Por su aspecto (merece una inspección más detallada), este sistema se basa en el DNS e implica que cualquier ataque de DNS (por ejemplo, spoofing de DNS ) podría aprovecharse para emitir certificados falsos, de forma totalmente automatizada, por lo que esta iniciativa sería un debilitamiento del modelo de certificado actual. Por otro lado, si convence a más personas para que usen SSL, contribuye a un "Mundo más seguro", al menos desde el punto de vista de NSA-is-the-Devil, donde lo que importa es derrotar a los intrusos pasivos.

De todos modos, sin el soporte de Microsoft y Google (es decir, la inclusión de la entidad emisora de certificados de Let's Encrypt en IE y Chrome), no hay forma de que la iniciativa se convierta en HTTPS generalizado. No mucha gente activaría SSL en su sitio web si eso significa que el 70% de los usuarios se sentirán insultados y asustados por sus navegadores. Si Microsoft y Google no saltan al carro (y no creo que lo hagan), entonces el sistema Let's Encrypt seguirá siendo un gesto político, pero no será generalizado (y en última instancia, Mozilla lo abandonará si alguien se molesta en hacerlo). montar un ataque automatizado basado en DNS).

Hay otro modo de certificado completamente diferente para SSL; se llama SRP . Ese es seguro, pero diferente de la navegación web normal. SRP garantiza la autenticación mutua cliente / servidor con respecto a un secreto compartido, y lo hace de una manera que protege el secreto compartido contra la fuerza bruta sin conexión, por lo que puede tolerar el uso de un secreto compartido de baja entropía, es decir, un contraseña . TLS-SRP tiene mucho sentido para acceder a recursos de red protegidos por contraseña, y no implica ningún certificado; y, sin embargo, es seguro contra MitM y las escuchas ilegales.

Lamentablemente, los navegadores web actualmente no admiten SRP.

    
respondido por el Tom Leek 20.11.2014 - 14:40
fuente
4

SSL / TLS (el protocolo subyacente para HTTPS) proporciona dos características:

  • Encriptación, para que nadie pueda escuchar pasivamente los datos. El cifrado se realiza mediante una clave que de alguna manera se comparte entre los pares.
  • Identificación, para que pueda estar seguro de con quién está hablando. Esto generalmente se hace con certificados.

Si bien puede tener encriptación sin identificación, su conexión estaría abierta a ataques activos, donde en lugar del interlocutor esperado usted habla con otra persona, como un hombre en el medio que luego puede descifrar y manipular los datos y enviar los datos a el par original después de volver a cifrar.

Sin identificación no significa solo sin certificados, sino también cuando confía en cualquier certificado que obtenga, generalmente certificados autofirmados.

Por lo tanto, mientras que TLS podría realizar el cifrado sin certificados, HTTPS requiere certificados porque esta es la única forma de identificación adecuada en este caso de uso.

    
respondido por el Steffen Ullrich 20.11.2014 - 06:50
fuente
0

No, no puede tener HTTPS sin el uso del Certificado SSL / clave pública.

Con el certificado SSL, el servidor se identifica al cliente.

Si tiene un certificado autofirmado, tendrá HTTPS, pero los navegadores modernos no confían en el certificado autofirmado.

    
respondido por el Jake Adley 20.11.2014 - 06:18
fuente
0

Los datos a través de la conexión https se cifran mediante una clave privada, que tanto el remitente como el receptor conocen. El remitente cifra los datos utilizando la clave privada y el receptor utiliza la misma clave para descifrar los datos.

La misma clave no se reutiliza de nuevo para evitar los ataques de reproducción. Por lo tanto, se debe usar una clave única en cada sesión.

Ahora, la pregunta es quién genera la clave única y cómo compartimos esta clave única en cada sesión. Este es un problema, ¿verdad? Esta clave privada única se comparte mediante una infraestructura de clave pública y el certificado es parte integral de ella. Generalmente, la solicitud es iniciada por el cliente (en este caso el navegador). El certificado incluye la información sobre la clave pública del servidor que se utiliza para cifrar una clave privada aleatoria generada por el cliente. Estos datos solo se pueden descifrar mediante la clave privada del servidor, que solo es conocida por el servidor. Una vez que se establece la clave privada entre el cliente y el servidor, pueden comenzar a comunicarse de forma segura, que es esencialmente el https.

    
respondido por el Curious 20.11.2014 - 06:23
fuente
0

Con respecto a las alternativas al cifrado basado en certificados (asimétrico) para los protocolos de comunicación, el cifrado simétrico es una posibilidad, como una clave compartida conocida por ambas partes.

Teniendo en cuenta las alternativas a SSL y en particular a los certificados, considere encriptar los datos antes de colocarlos en el cable. Esto le permitiría usar cualquier número de protocolos como transporte mientras se asegura que los datos no se puedan ver. El desencriptado exitoso significaría que los datos llegaron con éxito a su destino y no fueron manipulados.

Técnicamente, no puede tener https sin SSL debido al esquema URI. Este artículo de wikipedia hace un gran trabajo explicando esto e incluye enlaces a artículos de RFC si buscas algo más técnico. En resumen, la especificación establece que el esquema https corresponde con SSL / TLS. Tenga en cuenta que este excluye escenarios en los que uno renuncia a las especificaciones RFC a favor de su propia solución (ejemplo: haga rodar su propio cifrado ) donde creará su propia especificación para https. Cualquier persona que consuma ese servicio deberá comprender la especificación personalizada.

    
respondido por el user2320464 20.11.2014 - 07:00
fuente

Lea otras preguntas en las etiquetas