Os URLs HTTPS são criptografados?

1020

Todos os URLs são criptografados ao usar a criptografia TLS / SSL (HTTPS)? Gostaria de saber porque quero que todos os dados de URL sejam ocultados ao usar TLS / SSL (HTTPS).

Se o TLS / SSL fornecer criptografia total de URL, não preciso me preocupar em esconder informações confidenciais dos URLs.

ssl  https  httprequest 
— Daniel Kivatinos
fonte
76
Provavelmente, é uma má idéia colocar dados confidenciais na URL de qualquer maneira. Ele também será exibido no endereço do navegador, lembra? As pessoas não gostam se a senha for visível para quem olha de relance para a tela. Por que você acha que precisa colocar dados confidenciais no URL?
— jalf
43
Os URLs também são armazenados no histórico do navegador e nos logs do servidor - se eu quisesse ter meu nome e senha armazenados em algum lugar, ele não estaria nesses dois lugares.
— Piskvor saiu do prédio
47
Por exemplo, suponha que eu a visite https://somewhere_i_trust/ways_to_protest_against_the_government/. Em seguida, o URL contém dados confidenciais, ou seja, a sugestão que estou pensando em protestar contra meu governo.
— 26611 Steve Jessop
42
Eu estava me perguntando essa pergunta ao fazer uma solicitação HTTP de um aplicativo nativo (não baseado em navegador). Suponho que isso possa interessar aos desenvolvedores de aplicativos para dispositivos móveis. Nesse caso, os comentários acima (embora verdadeiros) são irrelevantes (sem URL visível, sem histórico de navegação), tornando a resposta, para meu entendimento, simples: "Sim, está criptografado".
— dannyaName
23
Para aqueles que pensam que, uma vez que você é HTTPS, ninguém sabe para onde está indo, leia primeiro: O nome do host do servidor (por exemplo, example.com) ainda vazará devido ao SNI . Isso não tem absolutamente nada a ver com o DNS e o vazamento ocorrerá mesmo se você não usar o DNS ou usar o DNS criptografado.
— Pacerier 9/11

Respostas:

913

Sim, a conexão SSL está entre a camada TCP e a camada HTTP. O cliente e o servidor primeiro estabelecem uma conexão TCP criptografada segura (por meio do protocolo SSL / TLS) e, em seguida, o cliente envia a solicitação HTTP (GET, POST, DELETE ...) através dessa conexão TCP criptografada.

— Marc Novakowski
fonte
98
Ainda vale a pena notar a coisa mencionada por @Jalf no comentário sobre a própria pergunta. Os dados de URL também serão salvos no histórico do navegador, o que pode ser inseguro a longo prazo.
— 22630 Michael Ekstrand
20
Não apenas GET ou POST. Também pode ser DELETE, PUT, HEAD ou TRACE.
4
Sim, pode ser um problema de segurança para o histórico de um navegador. Mas, no meu caso, não estou usando o navegador (também a postagem original não mencionou um navegador). Usando uma chamada https personalizada nos bastidores de um aplicativo nativo. É uma solução simples para garantir que a conexão de servidor do seu aplicativo seja segura.
— Zingle-dingle
28
Observe, no entanto, que a resolução de DNS da URL provavelmente não está criptografada. Portanto, alguém que cheira seu tráfego provavelmente ainda pode ver o domínio que você está tentando acessar.
— ChewToy
21
O SNI quebra a parte 'host' da criptografia SSL dos URLs. Você pode testar isso com o wireshark. Há um seletor para SNI, ou você pode apenas revisar seus pacotes SSL quando se conectar ao host remoto.
— cmouse
654

Como ninguém forneceu uma captura por fio, aqui está uma.
O nome do servidor (a parte do domínio da URL) é apresentado no ClientHellopacote, em texto sem formatação .

A seguir, é exibida uma solicitação do navegador para:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Consulte esta resposta para obter mais informações sobre os campos de versão do TLS (existem três deles - não versões, campos que contêm um número de versão!)

Em https://www.ietf.org/rfc/rfc3546.txt :

3.1 Indicação do nome do servidor

O [TLS] não fornece um mecanismo para um cliente informar ao servidor o nome do servidor que está entrando em contato. Pode ser desejável que os clientes forneçam essas informações para facilitar conexões seguras a servidores que hospedam vários servidores 'virtuais' em um único endereço de rede subjacente.

A fim de fornecer o nome do servidor, os clientes podem incluir uma extensão do tipo "server_name" no (estendido) cliente Olá.


Em resumo:

  • O FQDN (parte do domínio da URL) PODE ser transmitido de forma clara dentro do ClientHellopacote se a extensão SNI for usada

  • O restante da URL ( /path/?some=parameters&go=here) não tem negócios, ClientHellopois a URL de solicitação é uma coisa HTTP (OSI Layer 7); portanto, nunca será exibida em um handshake TLS (Layer 4 ou 5). Isso virá posteriormente em uma GET /path/?some=parameters&go=here HTTP/1.1solicitação HTTP, APÓS o canal TLS seguro ser estabelecido.


SUMÁRIO EXECUTIVO

O nome de domínio PODE ser transmitido de forma clara (se a extensão SNI for usada no handshake TLS), mas o URL (caminho e parâmetros) é sempre criptografado.


ATUALIZAÇÃO DE MARÇO DE 2019

Obrigado carlin.scott por trazer este aqui.

A carga útil na extensão SNI agora pode ser criptografada por meio desta proposta preliminar de RFC . Esse recurso existe apenas no TLS 1.3 (como uma opção e cabe aos dois lados implementá-lo) e não há compatibilidade com o TLS 1.2 e versões anteriores.

O CloudFlare está fazendo isso e você pode ler mais sobre os internos aqui - Se o frango deve vir antes do ovo, onde você coloca o frango?

Na prática, isso significa que, em vez de transmitir o FQDN em texto sem formatação (como mostra a captura do Wireshark), ele agora está criptografado.

NOTA: Isso aborda o aspecto de privacidade mais do que o de segurança, uma vez que uma pesquisa reversa no DNS PODE revelar o host de destino desejado.

— evilSnobu
fonte
37
Resposta perfeita, com uma explicação completa de A a Z. Adoro o resumo executivo. Fez o meu dia @evilSnobu
— oscaroscar
4
Resposta perfeita, voto positivo! Ainda considere a parte do cliente, pois o histórico do navegador pode estar vazando. No entanto, em relação à camada de transporte, os parâmetros de URL são criptografados.
— Jens Kreidler
2
Você pode atualizar esta resposta com o fato de que o TLS 1.3 criptografa a extensão SNI, e a maior CDN está fazendo exatamente isso: blog.cloudflare.com/encrypted-sni É claro que um sniffer de pacote poderia fazer uma pesquisa de DNS reverso para os endereços IP aos quais você está se conectando.
— Carlin.scott 21/03/19
@evilSnobu, mas nome de usuário: senha parte do nome de usuário: password@domain.com está criptografada, certo? Portanto, é seguro transmitir dados confidenciais em url usando https.
— Maksim Shamihulau 11/11/19
1
Eles são criptografados na conexão (no transporte), mas se o final (usuário ou servidor) registra o URL em um arquivo de texto sem formatação e não limpa as credenciais ... agora essa é uma conversa diferente.
— evilSnobu
159

Como as outras respostas já apontaram, os "URLs" https são realmente criptografados. No entanto, sua solicitação / resposta de DNS ao resolver o nome de domínio provavelmente não é e, é claro, se você estiver usando um navegador, seus URLs também poderão ser registrados.

— Zach Scrivena
fonte
21
E a gravação de URLs é importante, pois existem hacks Javascript que permitem que um site completamente independente teste se um URL específico está no seu histórico ou não. Você pode tornar um URL indesejável incluindo uma sequência aleatória longa, mas se for um URL público, o invasor poderá dizer que foi visitado e, se houver um pequeno segredo, um invasor poderá fazer força bruta que a uma velocidade razoável.
— 26611 Steve Jessop
8
@SteveJessop, por favor fornecer um link para "hacks Javascript que permitem que um site completamente alheios para testar se uma determinada URL está na sua história ou não"
— Pacerier
6
@ Pacerier: data dos hacks, é claro, mas o que eu estava falando na época eram coisas como stackoverflow.com/questions/2394890/… . Foi um grande negócio em 2010 que esses problemas estavam sendo investigados e os ataques refinados, mas não estou realmente seguindo no momento.
— Steve Jessop
2
@Pacerier: mais exemplos: webdevwonders.com/… , webdevwonders.com/…
— Steve Jessop
1
Você pode usar o OpenDNS com seu serviço DNS criptografado. Eu o uso no meu Mac, mas achei a versão do Windows não funcionando corretamente. Isso foi há um tempo atrás, então pode funcionar bem agora. Para Linux nada ainda. opendns.com/about/innovations/dnscrypt
— SPRBRN
101

Solicitação e resposta inteiras são criptografadas, incluindo URL.

Observe que quando você usa um proxy HTTP, ele conhece o endereço (domínio) do servidor de destino, mas não conhece o caminho solicitado nesse servidor (ou seja, solicitação e resposta são sempre criptografadas).

— Peter Štibraný
fonte
1
A totalidade da solicitação. O nome do host é enviado em claro. Todo o resto é criptografado.
— Sam Sirry 21/07/19
98

Eu concordo com as respostas anteriores:

Para ser explícito:

Com o TLS, a primeira parte do URL ( https://www.example.com/ ) ainda é visível à medida que cria a conexão. A segunda parte (/ herearemygetparameters / 1/2/3/4) é protegida por TLS.

No entanto, existem várias razões pelas quais você não deve colocar parâmetros na solicitação GET.

Primeiro, como já mencionado por outros: - vazamento na barra de endereços do navegador - vazamento no histórico

Além disso, há vazamento de URL através do referenciador http: o usuário vê o site A no TLS e clica em um link para o site B. Se os dois sites estiverem no TLS, a solicitação para o site B conterá o URL completo do site A em o parâmetro referenciador da solicitação. E o administrador do site B pode recuperá-lo dos arquivos de log do servidor B.)

— Tobias
fonte
3
@EJP Você não entendeu o que Tobias está dizendo. Ele está dizendo que se você clicar em um link no site A que o levará ao site B, o site B obterá o URL do referenciador. Por exemplo, se você estiver no siteA.com?u=username&pw=123123 , o siteB.com (que está vinculado na página do siteA.com) receberá " siteA.com?u=username&pw=123123 " como referência URL, enviado para o siteB.com dentro do HTTPS pelo navegador. Se isso é verdade, isso é muito ruim. Isso é verdade, Tobias?
— trusktr
9
@EJP, o domínio é visível por causa do SNI usado por todos os navegadores modernos. Veja também este diagrama do EFF, mostrando que qualquer pessoa pode ver o domínio do site que você está visitando. Não se trata de visibilidade do navegador. É sobre o que é visível para os bisbilhoteiros.
— Buge
10
@trusktr: os navegadores não devem enviar um cabeçalho de referenciador das páginas HTTPS. Isso faz parte da especificação HTTP .
— Martin Geisler
8
@MartinGeisler, a palavra-chave é "deveria". Os navegadores não se preocupam muito com o "deveria" (ao contrário de "deve"). No seu próprio link: "é altamente recomendável que o usuário possa selecionar se o campo Referer é ou não enviado. Por exemplo, um cliente de navegador pode ter uma opção de alternar para navegar de forma aberta / anônima, o que ativaria / desativaria o envio de Referer e De informações " . Ops, exatamente o que o Chrome fez. Exceto que o Chrome vaza o Referrer, mesmo se você estiver no modo de navegação anônima .
— Pacerier
48

Além da resposta útil de Marc Novakowski - o URL é armazenado nos logs do servidor (por exemplo, em / etc / httpd / logs / ssl_access_log), portanto, se você não deseja que o servidor mantenha as informações por mais tempo termo, não o coloque no URL.

— Rhodri Cusack
fonte
34

Sim e não.

A parte do endereço do servidor NÃO é criptografada, pois é usada para configurar a conexão.

Isso pode mudar no futuro com SNI e DNS criptografados, mas a partir de 2018 ambas as tecnologias não estarão mais em uso.

O caminho, a string de consulta etc. são criptografados.

Nota para solicitações GET, o usuário ainda poderá recortar e colar o URL na barra de localização, e você provavelmente não desejará inserir informações confidenciais que possam ser vistas por qualquer pessoa que esteja olhando para a tela.

— SoapBox
fonte
8
Gostaria de marcar com +1 isso, mas acho que o "sim e não" é enganoso - você deve alterar isso para indicar que o nome do servidor será resolvido usando o DNS sem criptografia.
— 3111 Lawrence Dol
7
No meu entender, o OP usa a palavra URL no sentido correto. Acho que essa resposta é mais enganosa, pois não faz claramente a diferença entre o nome do host na URL e o nome do host na resolução do DNS.
— Guillaume
4
O URL está criptografado. Todos os aspectos da transação HTTP são criptografados. Não apenas 'tudo o resto'. Período. -1.
— Marquês de Lorne
4
@EJP mas a pesquisa de DNS faz uso o que está em um ponto parte da URL, por isso a pessoa não técnica, toda a URL não é criptografada. A pessoa não técnica que está apenas usando o Google.com para pesquisar coisas não técnicas não sabe onde os dados residem ou como são tratados. O domínio, que faz parte da URL que o usuário está visitando, não é 100% criptografado porque eu, como invasor, posso cheirar o site que ele está visitando. Somente o caminho / de uma URL é inerentemente criptografado para o leigo (não importa como).
— trusktr
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Todos vocês estão enganados. Isso não tem nada a ver com o DNS. O SNI " envia o nome do domínio virtual como parte da negociação do TLS "; portanto, mesmo se você não usar DNS ou se o seu DNS estiver criptografado, um sniffer ainda poderá ver o nome do host de suas solicitações.
— Pacerier 9/11
9

Um terceiro que está monitorando o tráfego também pode determinar a página visitada examinando seu tráfego e comparando-o com o tráfego que outro usuário possui ao visitar o site. Por exemplo, se houvesse duas páginas apenas em um site, uma muito maior que a outra, a comparação do tamanho da transferência de dados diria qual página você visitou. Há maneiras de ocultar esses terceiros, mas eles não são um comportamento normal do servidor ou do navegador. Veja, por exemplo, este artigo do SciRate, https://scirate.com/arxiv/1403.0297 .

Em geral, outras respostas estão corretas, na prática, embora este artigo mostre que as páginas visitadas (por exemplo, URL) podem ser determinadas com bastante eficácia.

— pbhj
fonte
Isso seria realmente viável apenas em sites muito pequenos e, nesses casos, o tema / tom / natureza do site provavelmente ainda seria o mesmo em cada página.
— Cameron
5
Pela citação que apresentei: "Apresentamos um ataque de análise de tráfego contra mais de 6000 páginas da Web, abrangendo as implantações HTTPS de 10 sites líderes do setor amplamente usados ​​em áreas como assistência médica, finanças, serviços jurídicos e streaming de vídeo. Nosso ataque identifica páginas individuais em o mesmo site com 89% de precisão [...] ". Parece que sua conclusão quanto à viabilidade está errada.
— Pbhj #
2
Para qualquer pessoa interessada em ler mais sobre esse tipo de vulnerabilidade, esses tipos de ataques geralmente são chamados de ataques de canal lateral .
— 22816 Dan Bechard
7

Você nem sempre pode contar com a privacidade do URL completo. Por exemplo, como às vezes é o caso nas redes corporativas, os dispositivos fornecidos, como o PC da sua empresa, são configurados com um certificado raiz "confiável" extra, para que o seu navegador possa confiar silenciosamente em uma inspeção proxy (intermediária) do tráfego https . Isso significa que o URL completo é exposto para inspeção. Isso geralmente é salvo em um log.

Além disso, suas senhas também são expostas e provavelmente registradas, e esse é outro motivo para usar senhas únicas ou alterar suas senhas com freqüência.

Por fim, o conteúdo da solicitação e resposta também é exposto se não for criptografado.

Um exemplo da configuração da inspeção é descrito pelo ponto de verificação aqui . Um "internet café" antigo, usando os PCs fornecidos, também pode ser configurado dessa maneira.

— Don Gillis
fonte
6

Link para a minha resposta em uma pergunta duplicada . Não apenas a URL está disponível no histórico dos navegadores, os logs do lado do servidor, mas também é enviado como o cabeçalho HTTP Referer que, se você usar conteúdo de terceiros, expõe a URL a fontes fora do seu controle.

— JoshBerke
fonte
Fornecer chamadas de terceiros também é HTTPS, embora isso não seja um problema, certo?
— Liam
3
Ele ia ser criptografados com o certificado de terceiros para que eles pudessem ver a URL
— JoshBerke
5

Agora é 2019 e o TLS v1.3 foi lançado. De acordo com o Cloudflare, o SNI pode ser criptografado graças ao TLS v1.3. Então, eu me disse ótimo! vamos ver como fica dentro dos pacotes TCP do cloudflare.com Então, peguei um pacote de handshake "client hello" em uma resposta do servidor cloudflare usando o Google Chrome como navegador e wireshark como sniffer de pacotes. Ainda consigo ler o nome do servidor em texto sem formatação no pacote Olá do cliente.

insira a descrição da imagem aqui

Portanto, cuidado com o que você pode ler, porque ainda não é uma conexão anônima. Um middleware entre o cliente e o servidor pode registrar todos os domínios solicitados por um cliente.

Portanto, parece que a criptografia do SNI exige implementações adicionais para trabalhar com o TLSv1.3

O artigo a seguir descreve a criptografia do SNI fornecido pelo Cloudflare como parte do TLSv1.3. No entanto, todos os URLs HTTP de cloudflare.com estão em texto sem formatação no pacote TCP sob TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/[[3]

— Nicolas Guérinet
fonte
"o SNI pode ser criptografado" - esse é o ponto principal. A verificação de cloudflare.com/ssl/encrypted-sni com o Google Chrome atual indica "O seu navegador não criptografou o SNI ao visitar esta página". São necessários dois para
— dançar o
Aparentemente, o Firefox atual pode executar ESNI, mas está desativado por padrão: você precisa habilitar network.security.esni.enabled, defina network.trr.mode2 (que atualmente define seu resolvedor de DoH como CloudFlare) e reinicie o navegador (sic!); depois, ele usará o ESNI - onde é suportado pela infraestrutura do domínio. Consulte blog.mozilla.org/security/2018/10/18/… para obter detalhes.
— Piskvor saiu do prédio
2

Embora já existam boas respostas aqui, a maioria delas está focada na navegação do navegador. Estou escrevendo isso em 2018 e provavelmente alguém quer saber sobre a segurança de aplicativos móveis.

Para aplicativos móveis , se você controlar as duas extremidades do aplicativo (servidor e aplicativo), desde que você use HTTPS, estará seguro . O iOS ou Android verificará o certificado e mitigará possíveis ataques MiM (esse seria o único ponto fraco disso tudo). Você pode enviar dados confidenciais por meio de conexões HTTPS que serão criptografadas durante o transporte . Apenas seu aplicativo e o servidor conhecerão todos os parâmetros enviados por https.

O único "talvez" aqui seria se o cliente ou servidor estivesse infectado com software malicioso que pode ver os dados antes de serem agrupados em https. Mas se alguém estiver infectado com esse tipo de software, ele terá acesso aos dados, não importa o que você use para transportá-los.

— Ricardo BRGWeb
fonte
1

Além disso, se você estiver criando uma API do ReSTful, os problemas de vazamento do navegador e de referenciador http são mitigados, pois o cliente pode não ser um navegador e você pode não ter pessoas clicando em links.

Se for esse o caso, recomendo o login no oAuth2 para obter um token de portador. Nesse caso, os únicos dados confidenciais seriam as credenciais iniciais ... que provavelmente deveriam estar em uma solicitação posterior de qualquer maneira

— Chris Rutledge
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.