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 HTTP . Fue desarrollado por Eric Rescorla y Allan M. Schiffman, y publicado en 1999 como RFC 2660.
Los navegadores web suelen utilizar HTTP para comunicarse con los servidores web , enviando y recibiendo información sin cifrarla. Para transacciones sensibles, como comercio electrónico por Internet o acceso en línea a cuentas financieras, el navegador y el servidor deben cifrar esta información. HTTPS y S-HTTP se definieron a mediados de la década de 1990 para abordar esta necesidad. El servidor web de Spyglass utilizó S-HTTP , [1] mientras que Netscape y Microsoft admitieron HTTPS en lugar de S-HTTP, lo que llevó a que HTTPS se convirtiera en el mecanismo estándar de facto para proteger las comunicaciones web.
Comparación con HTTP sobre TLS
S-HTTP cifra solo los datos de la página servida y los datos enviados, como los campos POST, sin modificar el inicio del protocolo. Debido a esto, S-HTTP podría usarse simultáneamente con HTTP (no seguro) en el mismo puerto, ya que el encabezado no cifrado 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 "huevo y gallina" de alojamiento virtual basado en nombres al determinar qué nombre DNS estaba destinado a la solicitud.
Esto significa que las implementaciones HTTPS sin soporte de Indicación de nombre de servidor (SNI) requieren una dirección IP separada por nombre DNS, y todas las implementaciones 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 independiente , https: // ).
Como se documenta en RFC 2817, HTTP también se puede proteger mediante la implementación de encabezados de actualización HTTP / 1.1 y la actualización 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 o 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 sin cifrar, sino que se deja en blanco; otro conjunto de encabezados está presente 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 correctamente de los errores fatales de TLS (incluido "el certificado del cliente no es de confianza" y "el certificado del cliente ha caducado"). [ cita requerida ]
Referencias
- ↑ Booker, Ellis (27 de marzo de 1995). "Los servidores web se mueven en diferentes direcciones" . Computerworld .
- ^ Tom Sheldon (2001). "S-HTTP (Protocolo seguro de transferencia de hipertexto)" . Consultado el 1 de enero de 2016 .