Resumo

  • O RFC 2817 desenhou uma passagem de HTTP/1.1 para TLS na mesma conexão TCP. A porta 80 poderia receber tráfego aberto e protegido, e o campo Host chegaria antes da escolha do certificado.
  • O documento manteve https como espaço de endereços distinto e registrou pouco interesse em substituir a porta 443 na navegação Web comum. O RFC 2818 descreveu essa porta como entrada padrão para TLS antes do HTTP.

A Web tinha duas campainhas. Na porta 80, HTTP entregava a requisição de cara limpa. Num endereço https, a ligação padrão ia à porta 443 e começava pelo aperto de mãos TLS. Em dezembro de 1997, dirigentes da área de aplicações do IETF reafirmaram uma preferência: novos protocolos não deveriam colecionar uma porta comum e outra segura como quem compra sapatos aos pares. A solução publicada em maio de 2000 parecia razoável. Por que não instalar a fechadura na entrada existente?

O RFC 2817 ofereceu o mecanismo Upgrade do HTTP/1.1 para TLS/1.0. O cliente iniciava uma conversa HTTP e pedia a troca de protocolo na conexão aberta. A proposta também enfrentava um problema dos servidores virtuais. Vários nomes podiam compartilhar um endereço IP graças ao campo Host da requisição HTTP. No percurso TLS que começava antes do HTTP, o servidor precisava escolher o certificado sem ter recebido esse campo. Um começo aberto permitiria conhecer o nome primeiro e escolher o certificado correspondente. A recepcionista perguntaria para quem era a visita antes de fechar a porta.

O RFC 2616 definia Upgrade como uma negociação entre vizinhos imediatos da conexão. O cliente podia incluir Upgrade: TLS/1.0 e Connection: Upgrade numa requisição comum quando aceitasse uma resposta aberta. Para uma operação que exigisse proteção, o RFC 2817 prescrevia primeiro OPTIONS *. Era uma sondagem sem o conteúdo delicado, dando ao servidor a chance de concordar com a mudança antes da requisição importante.

Ao concordar, o servidor respondia 101 Switching Protocols, anunciava a pilha TLS/1.0, HTTP/1.1 e passava ao TLS logo após os cabeçalhos. O aperto de mãos vinha então; a continuação HTTP seguia dentro do canal protegido. Outra resposta, 426 Upgrade Required, informava que o recurso exigia uma mudança específica. Esse aviso não girava a chave sozinho. O cliente precisava realizar a negociação. Uma placa na porta e uma porta trancada são coisas diferentes.

Os intermediários acrescentavam corredores. Upgrade era uma operação salto a salto: uma mudança entre cliente e proxy não trocava automaticamente a ligação entre proxy e origem. Para chegar ao servidor de origem através de um proxy, o RFC 2817 descrevia CONNECT formando um túnel, inclusive para a porta 80. Depois de uma resposta 2xx, o cliente podia negociar o Upgrade com o servidor pelo túnel. O sonho de uma porta só dependia de cada trecho do caminho.

Havia ainda o endereço impresso no convite. O RFC 2817 preservou a distinção entre os espaços de URI http:// e https://. O RFC 2818, publicado no mesmo mês, registrou o arranjo do https: conexão padrão à porta 443, ClientHello TLS primeiro e HTTP depois, dentro do TLS. A proposta de uma entrada compartilhada podia mudar a sequência da conexão. O nome público do destino continuava a orientar cliente e leitor.

Os autores do RFC 2817 registraram ampla aceitação da ideia geral e pouco interesse em alternativas à porta 443 para a navegação Web comum. Viram mais espaço para a técnica em novos protocolos construídos sobre HTTP, como a impressão pela Internet. A frase traz a resistência do uso cotidiano para dentro de um texto de engenharia. A solução cuidava de portas paralelas, hospedagem virtual e exigências explícitas de proteção; precisava também conversar com proxies e com endereços já espalhados pela Web. O TLS bateu na 80. O convite seguro já vinha escrito com 443.