Com HTTPS, o URL e os headers de solicitação são protegidos como o corpo da solicitação?

Só quero verificar, ao fazer uma conexão SSL (http post) para dizer:

https://www.example.com/some/path?customer_key=123123123 

Se você não quer que ninguém saiba sobre customer_key, essa abordagem não funcionará mesmo se eu estiver fazendo uma conexão https correta?

Todos os dados que eu quero protegidos tem que estar no corpo da solicitação, certo?

Citando o RFC HTTPS :

Quando o handshake TLS terminar. O cliente pode então iniciar a primeira solicitação HTTP. Todos os dados HTTP DEVEM ser enviados como “dados de aplicação” do TLS.

Essencialmente, o canal SSL / TLS seguro é estabelecido primeiro. Só então o protocolo HTTP é usado. Isso protegerá todo o tráfego HTTP com SSL, incluindo os headers HTTP (que contêm o URL e os cookies).

O que pode ser visível no handshake é o próprio nome do host, já que ele está contido no certificado do servidor, que ficará visível no clear handshake (e geralmente é fácil adivinhar o nome do host olhando para o endereço IP de destino).

Ao usar a Indicação do nome do servidor, o nome do host solicitado também deve estar visível na extensão server_name na mensagem ClientHello . Caso contrário, pode haver um pouco de ambiguidade (para o interceptador) adivinhar o nome do host do certificado se o certificado for válido para vários nomes de host (por exemplo, vários Assunto Alt. Nomes ou curingas). Nesse caso, espionar a solicitação de DNS do cliente pode dar ao invasor uma pista.

Lendo respostas e comentários de outras pessoas, alguns mencionam questões sobre Referer (perdeu um r na especificação) e logs.

  • Os referenciadores não devem ser enviados quando vão de HTTPS para HTTP (mas geralmente são enviados quando vão de um site HTTPS para outro site HTTPS) .
  • Sobre o histórico: você terá que confiar em quem pode potencialmente obter essa chave legitimamente (ou seja, seus usuários) para não espalhá-la. Se necessário, tenha uma estratégia para alterá-lo de vez em quando.
  • Sobre os logs: Eu estava assumindo que você estava atrás de proteção na rede . O URL (incluindo a consulta) estará nos registros de fato, mas se alguém puder atacar sua máquina para obter os registros, você terá mais que se preocupar com as chaves do aplicativo.

Um dos pontos fracos potenciais restantes é como você dá esse link para o usuário. Se ele estiver embutido em uma página da Web com HTTP simples, qualquer pessoa que conseguir ler essa página poderá visualizá-la. Você também deve veicular essa página por HTTPS. Se você enviar esse link por email, eu diria que todas as apostas estão desativadas, já que os servidores de email raramente criptografam as conexões entre eles e os usuários com frequência para acessar sua conta de email sem qualquer criptografia.

EDITAR:

Além disso, se você estiver usando a autenticação de certificado de cliente, o certificado do cliente ficará visível se for negociado durante o handshake inicial. Isso pode vazar o nome do usuário que acessa o site (geralmente os DNs de Assunto contêm o nome de usuário). O certificado do cliente não estará visível se for enviado durante um handshake renegociado.

Apenas www.example.com ficará visível para os bisbilhoteiros. A seção de caminho da solicitação é protegida por SSL / TLS.

Obviamente, você precisa ter enviado o hiperlink original por HTTPS também.

Os dados da solicitação serão enviados depois de estabelecer a conexão segura, por isso não se preocupe com o URL acima, mas lembre-se de que seus dados não são criptografados, somente o canal entre o servidor e o cliente é criptografado, se é possível desvendar este canal e visualizar seus dados.

SSL é um canal criptografado por wrapper sobre seus dados. Se os dados estiverem claros, qualquer um que consiga decifrar o SSL poderá ver seus dados com clareza.

Revisando minha resposta para NÃO! Aparentemente, apenas o nome do host é enviado em texto não criptografado antes que a conexão SSL seja estabelecida.

http://answers.google.com/answers/threadview/id/758002.html

Depende..

Se você usar um sniffer de pacotes, não poderá ver os dados enviados pela rede. O principal problema com essa abordagem é que o URL de solicitação geralmente é salvo no log do servidor em texto simples, o histórico do navegador mantém o URL, as URLs são passadas nos headers do Referer e talvez sejam persistidas por serviços de terceiros (google analytics).