¿Admite HTTP el cifrado sin https (como STARTTLS)?

Question

¿Admite HTTP el cifrado sin https (como STARTTLS)?

#1 de Tom Leek (12 votos)
#2 de tylerl (3 votos)
#3 de Steffen Ullrich (1 votos)
#4 de cnst (-1 votos)

4

¿ http admite el cifrado sin https , similar a STARTTLS en smtp ?

Esto puede sonar como una pregunta estúpida, pero solo piénsalo.

Los bancos requieren un cifrado sólido y no pueden hacer negocios sin él.

Sin embargo, los sitios web normales no necesariamente lo hacen, pero se beneficiarían de un cifrado informal, previniendo muchos tipos de ataques, como es el caso con STARTTLS en smtp .

Como tal, para un sitio web normal, si el navegador tiene algún problema con ssl (ya sea por la incompatibilidad del protocolo, un dispositivo móvil de baja potencia o una preferencia explícita del usuario), debería continuar de forma segura sin cifrado sin demasiada molestia extra.

¿Existe alguna extensión del protocolo HTTP que permita el cifrado sin el uso explícito de https ? P.ej. algo akin Accept-Encoding: gzip y Content-Encoding: gzip ? ¿O STARTTLS en smtp ? ¿Si no, porque no? Incluso WPA2 de WiFi viene a la mente, lo que hace el cifrado, pero no se molesta con los certificados o las autoridades de certificación.

Básicamente, estoy pensando en algo como la extensión HTTPS-Everywhere, pero que funciona automáticamente sin la propaganda viral del esquema de dirección https:// , sin forzar a las personas que no quieren ser parte de él. sea parte de él, como lo hace el esquema de dirección https:// , sin dividir el esquema de dirección, y sin requerir que el proveedor de contenido se comprometa a respaldar siempre a https:// desde allí.

tls certificates http certificate-authority

pregunta cnst 01.04.2014 - 21:48

fuente

4 respuestas

Lea otras preguntas en las etiquetas tls certificates http certificate-authority

¿En qué medida es mejor el software antivirus GRATUITO de terceros que el defensor de Windows 8 (si existe)? sobre CSRF en el formulario enviar [duplicar]

score 12 · Answer 1

Hay un estándar para STARTTLS en HTTP simple. Tenga en cuenta que "STARTTLS" sigue siendo SSL; simplemente modifica la dinámica , pero no se evita la complejidad de la implementación de esa manera.

En términos generales, nadie usa STARTTLS para HTTP, principalmente porque es menos seguro . De hecho, una parte muy importante de los navegadores SSL para web son los comentarios visuales, que permiten al usuario conocer el cifrado (el famoso "icono del candado"). Sin él, el usuario no tendría forma de saber si realmente obtiene SSL o si está navegando en un sitio falso que saquea sus contraseñas y cuentas bancarias.

"Incompatibilidad de protocolo" y "dispositivo de baja potencia" son mitos. Cualquier dispositivo con capacidad de navegación actualmente en ejecución sabe al menos cómo hacer SSL 3.0, y eso es suficiente para una seguridad decente. En cuanto al poder, personalmente he implementado y ejecutado SSL en una CPU ARM integrada de 33 MHz; ese es el tipo de dispositivo que no consideraría digno de un reloj de pulsera. Incluso una tarjeta inteligente de banco básica, el pequeño chip incrustado en un rectángulo de plástico, tiene más poder que eso. Cuando las personas dicen que no admiten SSL debido a la falta de poder, esto es una mentira; lo que deberían decir es que no admiten SSL porque son perezosos.

En cuanto a la "preferencia del usuario": bueno, esa es algo intangible. Sin embargo, los cinturones de seguridad son obligatorios en los automóviles, y por buenas razones. De hecho, la Sociedad en su conjunto tiene derecho a hacer cumplir los cinturones de seguridad independientemente de las "preferencias del usuario", porque la misma Sociedad en su conjunto tendrá que soportar las consecuencias de un conductor descuidado que tiene un accidente leve y se convirtió en una discapacidad dramática porque No tenía su cinturón. El mismo razonamiento se aplica a SSL: no quiero permitir que los usuarios "desactiven" a SSL cuando dicha exclusión es estúpido.

score 3 · Answer 2

Usted no debería .

La razón es que, el esquema https:// URI señala tanto al usuario como al navegador que está actuando en un entorno seguro, y se deben tomar precauciones para evitar que la información segura se filtre a un entorno inseguro. Esto es bien entendido y un sistema bastante fuerte. El mecanismo que un servidor usaría para cambiar de una conexión insegura a una segura es un redireccionamiento a la URL segura. El mecanismo que un cliente usaría es solicitar la URL usando https en lugar de http. Como regla, todo esto funciona .

Pero para responder a su pregunta con mayor precisión, sí tal cosa existe. Es el encabezado de actualización de HTTP / 1.1 . Esto permite que el cliente y el servidor negocien directamente un protocolo. La actualización a TLS se describe en RFC 2817 .

Un cliente puede enviar un mensaje como este para averiguar si el servidor admite la actualización (ejemplo tomado de la RFC):

   OPTIONS * HTTP/1.1
   Host: example.bank.com
   Upgrade: TLS/1.0
   Connection: Upgrade

Si bien una respuesta del servidor que indica que una actualización es requerida para ver el recurso solicitado se vería así (nuevamente, desde el RFC):

   HTTP/1.1 426 Upgrade Required
   Upgrade: TLS/1.0, HTTP/1.1
   Connection: Upgrade

Estos están casi totalmente sin uso por las razones mencionadas anteriormente; debería utilizar el URI de HTTPS. El mecanismo de "actualización" es una opción inferior en interés de la seguridad.

No obstante, el mecanismo de "actualización" se usa para otros fines: específicamente, es cómo se inician sockets web , y también una de las maneras en que un cliente y un servidor pueden cambiar al protocolo SPDY .

score 1 · Answer 3

Creo que no entendiste STARTTLS. Este comando simplemente le dice al otro servidor, que los clientes quieren hacer TLS y después de que el servidor acordó que se iniciará el protocolo de enlace TLS normal, por ejemplo. Con certificados y todo eso, igual que con https. La principal diferencia es que no se compromete con TLS justo después de la conexión TCP, sino solo después de intercambiar algunos datos de texto sin formato (mensaje de bienvenida, EHLO ...). Y que la URL no le dice si se usa TLS, lo cual puede ser bueno o malo.

Pero sí, HTTP tiene un mecanismo similar que también se usa ampliamente: la solicitud CONECTAR cuando se canaliza a través de proxies. Esto se define en RFC2818 y en el mismo RFC también se define otro mecanismo para la actualización, utilizando el encabezado "Actualizar". Esta actualización puede ser opcional (el cliente desea pero acepta si el servidor no lo admite) u obligatorio (el servidor requiere https).

Si bien el encabezado de actualización se usa hoy para crear una conexión de WebSockets, nunca lo he visto para la actualización de SSL y dudo que algún navegador lo admita.

score -1 · Answer 4

Sí, actualmente está en camino de ser definido como una extensión de HTTP / 2 por enlace , y el soporte real del navegador se está escrito / confirmado / soportado (bmo # 1003448) y habilitado (bmo # 1113790) a finales de 2014 y principios de 2015, según enlace , que señala que la próxima Mozilla Firefox 37 puede ser el primer envío de productos con Oportunidad de cifrado (OE).