Resumen
- RFC 2817 propuso subir una conexión HTTP/1.1 a TLS sin cambiar de puerto: el 80 podía recibir tráfico normal y protegido, y el campo inicial
Hostservía para escoger un sitio virtual. - El mismo documento dejó intactas las direcciones
httpsy reconoció en 2000 el escaso interés en sustituir el puerto 443 para la navegación web general.
El problema parecía de carpintería. Si HTTP entraba por el 80 y HTTP protegido por el 443, cada protocolo nuevo que pidiera protección reclamaba una segunda puerta. Los responsables del área de aplicaciones de la IETF habían expresado en diciembre de 1997 su preferencia por dejar de repartir pares de puertos «normales» y «seguros». La solución que llegó en 2000 consistía en recibir al visitante por la puerta habitual y colocar el cerrojo durante la conversación.
El RFC 2817, publicado en mayo de 2000, describió Upgrade: TLS/1.0 dentro de HTTP/1.1. La conexión TCP ya abierta en el puerto 80 podía pasar de HTTP en claro a HTTP sobre TLS. El diseño resolvía otra dificultad práctica: varios nombres de sitio podían compartir una dirección IP gracias al campo HTTP Host, pero una negociación TLS iniciada antes de HTTP carecía de ese dato para escoger entre certificados de sitios virtuales. Un primer mensaje HTTP en claro entregaba el nombre antes de empezar TLS.
El mecanismo tenía reglas para evitar que una petición sensible saliera por la puerta equivocada. RFC 2616 había definido Upgrade como una negociación entre vecinos de una conexión HTTP. Si el cliente aceptaba una respuesta sin cifrar, podía proponer el cambio en una petición ordinaria; el servidor conservaba la opción de responder en claro. Cuando la respuesta en claro era inaceptable, RFC 2817 mandaba enviar primero OPTIONS *. El cliente probaba el cerrojo antes de entregar el contenido que quería proteger.
La aceptación llegaba con 101 Switching Protocols y la pila TLS/1.0, HTTP/1.1. El cambio comenzaba tras los encabezados de esa respuesta, seguía la negociación TLS y luego continuaba la conversación HTTP. 426 Upgrade Required daba al servidor una forma de exigir el cambio para una operación concreta. Ese 426 avisaba; el cliente todavía debía ejecutar el intercambio de Upgrade. Un portero puede pedir una llave sin haber cerrado la puerta.
Los intermediarios complicaban la mudanza. Upgrade era salto por salto: si respondía un proxy, cambiaba su conversación con el cliente; si respondía el servidor de origen al proxy, cambiaba la otra. Para establecer TLS hasta el origen, RFC 2817 empleaba CONNECT y un túnel, incluso cuando el destino seguía siendo el puerto 80. Una respuesta 2xx confirmaba que el túnel existía. Dentro de él podía ocurrir el Upgrade con el servidor final. Un puerto compartido no borraba las distintas conexiones que había que atravesar.
Quedaba la dirección escrita en los enlaces. RFC 2817 preservó la diferencia entre http:// y https://. RFC 2818, aparecido el mismo mes, documentó el camino ya familiar del segundo: puerto 443 por defecto, TLS ClientHello antes de la primera petición HTTP y comprobación del nombre del sitio frente al certificado. Compartir un puerto para dos modos de transporte no cambiaba automáticamente el nombre con que el usuario pedía el recurso.
El propio RFC 2817 evaluó el ambiente en el que nacía. Dijo que el concepto gozaba de amplia aceptación, pero que había poco interés en implementar alternativas al 443 para la navegación web corriente. Señaló aplicaciones nuevas montadas sobre HTTP, como la impresión por Internet, donde la negociación podía resultar útil. La introducción del documento ya retrataba dos velocidades: la del diseño que abría una ruta y la de los enlaces que llevaban años señalando otra.
Poner TLS en la puerta 80 tenía ventajas concretas: menos pares de puertos, el nombre Host disponible para escoger certificado y una señal 426 para exigir seguridad. El trayecto todavía necesitaba un saludo en claro, aceptación explícita, túneles cuando había proxies y respeto por las dos familias de direcciones. El visitante podía entrar por una puerta nueva; su invitación https seguía nombrando la antigua.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance





