Os dados GET também são criptografados em HTTPS?

127

Quando você OBTER

https://encrypted.google.com/search?q=%s

A %sconsulta está criptografada? Ou apenas a resposta? Caso contrário, por que o Google deve veicular seu conteúdo público também com criptografia?

https http-get

— Jader Dias
fonte

145

A solicitação inteira é criptografada, incluindo a URL e até o comando ( GET). A única coisa que uma parte interveniente, como um servidor proxy, pode recolher é o endereço e a porta de destino.

Observe, no entanto, que o pacote Client Hello de um handshake TLS pode anunciar o nome de domínio totalmente qualificado em texto sem formatação através da extensão SNI (obrigado @hafichuk), que é usado por todos os navegadores mainstream modernos, embora alguns apenas em sistemas operacionais mais recentes.

EDIT: (Como isso acabou de me dar um distintivo de "Boa resposta", acho que devo responder a pergunta inteira ...)

A resposta inteira também é criptografada; proxies não podem interceptar nenhuma parte dele.

O Google exibe pesquisas e outros conteúdos por https porque nem todo é público, e você também pode ocultar parte do conteúdo público de um MITM . De qualquer forma, é melhor deixar o Google responder por si próprio .

— Marcelo Cantos
fonte

2

Estou um pouco insatisfeito com a alegação de que o URL está criptografado. O nome do host não é considerado parte do URL? Nesse caso, a afirmação está errada. Não há como ocultar o nome do host / endereço IP do ISP / servidor proxy da mesma maneira que você não pode ocultar o endereço de destino ao enviar um email físico.

— Abhishek Anand

1

@Abhishek: O nome do host não está presente no cabeçalho TCP / IP. Cubro endereços IP na minha resposta.

— Marcelo Cantos

O domínio não está criptografado. Isso é para oferecer suporte a hosts virtuais baseados em nome (versus IP). @MarceloCantos está completamente correto de que o restante da URL (ou seja, o GETcomando) está criptografado. Isso é abordado na RFC 4366

— hafichuk

@hafichuk: Obrigado por isso. Eu não sabia que o TLS poderia anunciar o fqdn. A última vez que tentei configurar um multiserver https (há vários anos, admito), parecia impossível em um único ip.

— Marcelo Cantos

Adição realmente importante ao TLS que contém o nome do domínio: não esqueça a solicitação de DNS em texto sem formatação, incluindo também o nome do domínio. Provavelmente, alguém que pode ver seu tráfego HTTPS criptografado também pode assistir às suas solicitações de DNS.

— Tim G

63

A URL em si é criptografada, portanto, os parâmetros na cadeia de caracteres de consulta não trafegam de maneira simples pelo fio.

No entanto, lembre-se de que os URLs, incluindo os dados GET, geralmente são registrados pelo servidor da Web, enquanto os dados POST raramente o são. Então, se você planeja fazer algo assim /login/?username=john&password=doe, não faça; use um POST.

— Thomas
fonte

2

+1 obrigado. Ele está no meu próprio servidor físico, por isso não estou muito preocupado com logs, mas é uma boa consideração para quem considerar isso em um ambiente de hospedagem compartilhada. Também é importante a considerar, porque eu vou estar transferindo números de cartão de crédito dessa maneira, e definitivamente não vai querer registrá-los :)

— orokusaki

3

Realmente não importa que seja sua própria caixa. Você também não deseja que mais ninguém o possua (por exemplo, hackers do mal) que veja essas senhas em texto simples. Ou esses números CC (supondo que você não os esteja armazenando em outro lugar também).

— Thomas

1

Você deve colocá-los no corpo do POST, não na string de consulta da URL.

— Thomas

1

Você teme que o wbeserver tenha menos restrições no acesso aos seus logs do que no acesso aos dados do site (banco de dados, arquivo, etc.)? IMHO, desde que os dados acessem com segurança o servidor da web, tudo está bem. as únicas pessoas que têm acesso ao servidor da web devem ser consideradas confiáveis, porque, se não houver, não haverá como impedir que eles leiam os dados de uma maneira ou de outra.

— usar o seguinte código

1

Quando as senhas são enviadas por GET e são registradas no log de acesso, elas NÃO são hash. Eu acredito que esse é o maior problema. Ter senhas com hash no banco de dados não importa se você pode apenas procurá-las no log de acesso do servidor web. Eles devem ser divididos em hash no banco de dados; caso contrário, corrija-o.

— Steen Schütt

21

HTTPS Estabelece uma conexão SSL subjacente antes que qualquer dado HTTP seja transferido. Isso garante que todos os dados da URL (com exceção do nome do host, usado para estabelecer a conexão) sejam transportados apenas dentro dessa conexão criptografada e protegidos contra ataques do tipo intermediário da mesma maneira que qualquer dado HTTPS.

O texto acima faz parte de uma resposta MUITO abrangente do Google Answers, localizada aqui:

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

— DVK
fonte

17

A parte da URL após o nome do host ser enviado com segurança.

Por exemplo, https://somewhere.com/index.php?NAME=FIELD

A /index.php?NAME=FIELDpeça está criptografada. O somewhere.comnão é.

— levis501
fonte

6

Tudo é criptografado, mas você precisa se lembrar de que sua consulta permanecerá nos logs do servidor e estará acessível a vários analisadores de logs etc. (o que geralmente não é o caso da solicitação POST).

— Callback de Eugene Mayevski
fonte

1

quais servidores? acessível a quem?

— Jader Dias

2

@Jader para administradores desses servidores pelo menos e para hackers. Com a solicitação POST, as informações não permanecem nos logs; portanto, a menos que sejam registradas explicitamente, não há problema com os logs. As consultas GET permanecem nos logs e se o que acontecer com o log (ou o administrador decidir usá-los para qualquer atividade incorreta), você estará com problemas.

— Eugene Mayevski 'Callback

4

A conexão é criptografada antes da transmissão da solicitação. Então, sim, a solicitação também é criptografada, incluindo a string de consulta.

— cHao
fonte

4

Sim, é seguro. O SSL criptografa tudo.

Trecho da solicitação POST:

POST /foo HTTP/1.1
... some other headers

Trecho da solicitação GET:

GET /foo?a=b HTTP/1.1
... some other headers

Nos dois casos, tudo o que é enviado no soquete é criptografado. O fato de o cliente ver parâmetros em seu navegador durante uma solicitação GET não significa que um homem no meio verá o mesmo.

— Darin Dimitrov
fonte

4

Acabei de conectar via HTTPS a um site e passei vários parâmetros GET. Eu usei o wireshark para cheirar a rede. Usando HTTP, o URL é enviado sem criptografia, o que significa que posso ver facilmente todos os parâmetros GET no URL. Usando HTTPS, tudo é criptografado e não consigo nem ver qual pacote é o comando GET, quanto mais seu conteúdo!

— Jeff Lamb
fonte

3

O SSL ocorre antes da análise do cabeçalho, isto significa:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Uma solicitação é mais ou menos assim (não consigo lembrar a sintaxe exata, mas isso deve estar próximo o suficiente):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

É também por isso que ter Certificados SSL diferentes para vários hosts no mesmo IP é problemático, o Nome do host solicitado não é conhecido até a descriptografia.

— Morfildur
fonte

1

O HTTP/1.1vem no final da primeira linha.

— Marcelo Cantos

@ Marcelos Cantos: Obrigado, já faz um tempo desde que eu tive que escrever solicitações HTTP manualmente.

— Morfildur 10/11/2010

0

A solicitação GET é criptografada ao usar HTTPS - na verdade, é por isso que sites seguros precisam ter um endereço IP exclusivo - não há como obter o nome do host (ou diretório virtual) desejado a partir da solicitação até que ela seja descriptografada.

— Michael Burr
fonte

JFYI: Há uma extensão TLS que permite ao cliente especificar o nome do host e, assim, o servidor pode escolher o certificado correspondente.

— Eugene Mayevski 'Callback

@Eugene: Obrigado - estou ciente da extensão TLS, mas apenas no sentido mais amplo de conscientização - não sei nada sobre os detalhes ou quão amplamente pode (ou não) estar em uso real.

— Michael Burr