El Protocolo de transferencia segura de hipertexto ( S-HTTP ) es una alternativa obsoleta al protocolo HTTPS para cifrar las comunicaciones web que se transmiten por Internet. Fue desarrollado por Eric Rescorla y Allan M. Schiffman en EIT 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, y no modifica el inicio del protocolo. Por este motivo, S-HTTP se puede utilizar simultáneamente con HTTP (sin seguridad) en el mismo puerto, ya que el encabezado sin cifrar determinaría si el resto de la transmisión está cifrada.
Por el contrario, HTTP sobre TLS envuelve 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 crea un problema de "la gallina y el huevo" basado en nombres de alojamiento virtual a la hora de determinar qué nombre DNS estaba destinado a la solicitud.
Esto significa que las implementaciones de HTTPS sin soporte de Indicación de nombre de servidor (SNI) requieren una dirección IP separada por nombre DNS, y todas las implementaciones de HTTPS requieren un puerto separado (generalmente 443 frente al estándar 80 de HTTP) [2] para un uso inequívoco del cifrado (tratado en la mayoría de los navegadores como un esquema de URI separado , https:// ).
Como se documenta en RFC 2817, HTTP también se puede proteger implementando encabezados de actualización HTTP/1.1 y actualizando a TLS. La ejecución de HTTP sobre TLS negociado de esta manera no tiene las implicaciones de HTTPS con respecto al alojamiento virtual basado en nombres (sin 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 los encabezados de texto simple, sino que se deja en blanco; hay otro conjunto de encabezados dentro de la carga útil cifrada. En HTTP sobre TLS, todos los encabezados están dentro de la carga útil cifrada y la aplicación del servidor generalmente no tiene la oportunidad de recuperarse sin problemas de errores fatales de TLS (incluidos "el certificado del cliente no es confiable" y "el certificado del cliente ha expirado"). [2]