Protocolo seguro de transferencia de hipertexto

El Protocolo de Transferencia de Hipertexto Seguro ( S-HTTP ) es una alternativa obsoleta al protocolo HTTPS para cifrar las comunicaciones web transmitidas a través de Internet. Fue desarrollado por Eric Rescorla y Allan M. Schiffman en Enterprise Integration Technologies en 1994 ^{[ 1 ]} y publicado en 1999 como RFC 2660. El dominio de Netscape en el mercado de navegadores llevó a que HTTPS se convirtiera en el método de facto para proteger las comunicaciones web. 

S-HTTP cifra únicamente los datos de la página servida y los datos enviados, como los campos POST, sin modificar el inicio del protocolo. Por ello, S-HTTP puede utilizarse simultáneamente con HTTP (sin cifrar) en el mismo puerto, ya que la cabecera sin cifrar determinaría si el resto de la transmisión está cifrada.

En cambio, HTTP sobre TLS encapsula toda la comunicación dentro de Transport Layer Security (TLS; anteriormente SSL), por lo que el cifrado comienza antes de que se envíen los datos del protocolo. Esto genera un problema de dependencia circular en el alojamiento virtual basado en nombres, que dificulta determinar qué nombre DNS se utilizó para la solicitud.

Esto significa que las implementaciones HTTPS sin soporte para Server Name Indication (SNI) requieren una dirección IP separada por nombre DNS, y todas las implementaciones HTTPS requieren un puerto separado (normalmente 443 frente al estándar 80 de HTTP) ^{[ 2 ]} para el uso inequívoco del cifrado (tratado en la mayoría de los navegadores como un esquema URI separado , https:// ).

Como se documenta en la RFC 2817 , HTTP también puede protegerse implementando encabezados HTTP/1.1 Upgrade y actualizando a TLS. Ejecutar HTTP sobre TLS negociado de esta manera no tiene las implicaciones de HTTPS en lo que respecta al alojamiento virtual basado en nombres (no requiere direcciones IP, puertos ni espacio URI adicionales). Sin embargo, pocas implementaciones admiten este método. 

En S-HTTP, la URL deseada no se transmite en las cabeceras de texto plano, sino que se deja en blanco; otro conjunto de cabeceras se encuentra dentro de la carga útil cifrada. En HTTP sobre TLS, todas las cabeceras están dentro de la carga útil cifrada y la aplicación del servidor generalmente no tiene la oportunidad de recuperarse adecuadamente de los errores fatales de TLS (incluidos "el certificado del cliente no es de confianza" y "el certificado del cliente ha caducado"). ^{[ 2 ]}

• RFC 2660 Protocolo seguro de transferencia de hipertexto