Secure Hypertext Transfer Protocol

No confundir con Hypertext Transfer Protocol Secure (HTTPS) (HTTP sobre SSL o TLS).

El protocolo seguro de transferencia de hipertexto (S-HTTP, Secure HyperText Transfer Protocol) es el protocolo usado para transacciones seguras en la Web (WWW).

Introducción e Historia del SHTTP

El protocolo fue diseñado por E. Rescorla y A. Schiffman de Enterprise Integration Technologies (EIT). para obtener conexiones de HTTP. S-HTTP provee una variedad amplia de mecanismos para tener prevista confidencialidad, autenticación, e integridad, La separación de política de mecanismo fue un cometido explícito.

S-HTTP es un superconjunto de HTTP, el cual permite mensajes para ser narrado de forma resumida de forma muy diversa. Las encapsulaciones pueden incluir cifrado, firma, o una autenticación basada en MAC. Esta encapsulación puede ser recursiva, y un mensaje puede tener varias transformaciones de seguridad aplicadas.

S-HTTP también incluye definiciones de encabezado para proveer la transferencia de clave, dar un certificado a la transferencia, y las funciones administrativas similares. S-HTTP parece ser sumamente flexible, lo cual permitirá al programador desarrollar aplicaciones web sin temor a que la aplicación sea vulnerada. S-HTTP también ofrece el potencial para el desenvolvimiento sustancial del usuario dentro de él, y el descuido de la autenticación y las actividades de cifrado.

S-HTTP no confía en un esquema particular de certificación de clave. Incluye soporte para RSA, hacia dentro se agrupa, fuera de banda y el cambio de clave kerberos. Las claves para las certificaciones pueden ser provistas en un mensaje, u obtenido en otro sitio. Como en SSL, las llaves públicas del cliente no son requeridas.

El protocolo

Un mensaje seguro del HTTP es una línea de la petición o de estado, seguida por otros encabezados (RFC-822), y un cierto contenido. El contenido puede ser información irrelevante, un mensaje seguro del HTTP, o un mensaje del HTTP. Se define la línea de la petición como:

• Secure * Secure-HTTP/1.1 a cuál debe ser la respuesta:

• Secure-HTTP/1.1 200 OK

Estas líneas están definidas para imposibilitar a un atacante de considerar el éxito o el fracaso de una petición dada. El HTTP seguro lleva una actitud generalmente paranoica a toda información, filtrándose lo menos posible.

Las amenazas

Las amenazas del S-HTTP son similares a las existentes contra el SSL. Sin embargo, la naturaleza más general de S-HTTP hace difícil de determinar exactamente cuáles son posibles. En el caso de un hacker, o del looker, el ataque contra un CA puede ser más difícil, debido a la existencia de CAs múltiples. Una clave se podía verificar teóricamente por varios CAs, haciendo un ataque infeasible.

Las protecciones ofrecidas

El modo operacional por defecto de S-HTTP es substancialmente más resistente al ataque que el del SSL. Resiste el criptoanálisis claro de texto, hombre en el centro, y juega a nuevo ataques. Es más robusto que el SSL, porque se permite la renegociación y las recomprobaciones de la opción.

Además, el costo del texto claro del criptoanálisis DES es substancialmente más alto que el de RC4-40. (Recuerde que el DES cifra por defecto para S-HTTP, y RC4-40 cifra por defecto para el SSL). Para romper una clave RC4-40 en aproximación con respecto a costos al mes es en promedio de $125. Para romper una clave del DES en costos de un mes es un aproximado de $10.000 (extrapolado de Wiener, 1994).

Una clave DES de 56 bits cuesta un millón de dólares a la rotura sobre 7 horas. (Wiener, 1994) esta escala de costos va hacia arriba y hacia abajo en una forma lineal. (1/2 millón de dólares por máquina tomará 14 horas). Un mes tiene 720 horas (24 horas x 30 días), que es 102 períodos de 7 horas. El costo de romper el DES en un mes es casí cerca de $10 000, en comparación con $125 para 40 bits RC4.

Debilidades

El uso en el intercambio de la clave es potencialmente muy problemático; los autores no pasan bastante tiempo para asegurar que las claves se transfieren correctamente. Una transferencia incorrecta sería un esquema que envía B como Ea(B). Es decir, B dominante que substituye la clave A no se puede enviar usando la clave A para cifrarla. Si un atacante tiene llave quebrada A, entonces él tendrá B dominante, y el cambio de la llave es una pérdida de tiempo (con respecto a ese atacante). Esta equivocación fue incurrida a menudo por un japonés en la segunda guerra mundial. (Kahn) que esperaba que los programadores aprendan que de esto los errores de otros (especialmente los viejos errores de 50 años) son una apuesta pobre.

S-HTTP, es flexible, puede ofrecer a un programador bastantes variantes. Obviamente, no ofrece muchas opciones quebradas, sino que no parece hacer que cualquier cosa como los SSL con la actitud de "cifre todo y no lo que pueda". Un programador, especialmente uno no familiarizado con las aplicaciones de seguridad y criptografía, podría pensar que "usar S-HTTP me protegerá" y que no podrá proporcionar totalmente ninguna protección criptográfica para su información. La probabilidad de que esto suceda es discutible, pero es viable tener en consideración el problema.