SSL e mal-entendido man-in-the-middle
Eu li muita documentação relacionada a esse problema, mas ainda não consigo juntar todas as peças, então gostaria de fazer algumas perguntas.
Em primeiro lugar, descreverei brevemente o procedimento de autenticação como o entendo, pois posso estar enganado a esse respeito: Um cliente inicia uma conexão, à qual um servidor responde com uma combinação de chave pública, alguns metadados e assinatura digital de um autoridade confiável. Então o cliente toma a decisão se confia no servidor, criptografa alguma chave de sessão aleatória com a chave pública e a envia de volta. Esta chave de sessão pode ser descriptografada apenas com a chave privada armazenada no servidor. O servidor faz isso e a sessão HTTPS é iniciada.
Então, se eu estiver correto acima, a questão é como o ataque man-in-the-middle pode ocorrer em tal cenário? Quero dizer, mesmo se alguém interceptar a resposta do servidor (por exemplo, www.server.com) com a chave pública e tiver algum meio de me fazer pensar que ele é www.server.com, ele ainda não será capaz de descriptografar minha chave de sessão sem a chave privada.
Falando sobre autenticação mútua, é tudo sobre a confiança do servidor sobre a identidade do cliente? Quer dizer, o cliente já pode ter certeza de que está se comunicando com o servidor certo, mas agora o servidor quer saber quem é o cliente, certo?
E a última pergunta é sobre a alternativa à autenticação mútua. Se eu atuar como cliente na situação descrita, e se eu enviar um login / senha no cabeçalho HTTP após o estabelecimento da sessão SSL? A meu ver, essas informações não podem ser interceptadas porque a conexão já está segura e o servidor pode confiar nela para minha identificação. Estou errado? Quais são as desvantagens de tal abordagem em comparação com a autenticação mútua (apenas questões de segurança são importantes, não a complexidade da implementação)?
— Vadim Chekry
Ataques man-in-the-middle em SSL são realmente possíveis apenas se uma das pré-condições do SSL for quebrada, aqui estão alguns exemplos;
A chave do servidor foi roubado - significa que o atacante pode aparecer para ser o servidor, e não há nenhuma maneira para que o cliente sabe.
O cliente confia em uma CA não confiável (ou uma que teve sua chave raiz roubada) - quem quer que tenha uma chave CA confiável pode gerar um certificado fingindo ser o servidor e o cliente confiará nele. Com o número de CAs pré-existentes nos navegadores hoje, isso pode ser um problema real. Isso significa que o certificado do servidor parece mudar para outro válido, o que a maioria dos clientes esconderá de você.
O cliente não se preocupa em validar o certificado corretamente em sua lista de CAs confiáveis ​​- qualquer pessoa pode criar uma CA. Sem validação, "Carros e certificados da Ben" parecerão tão válidos quanto a Verisign.
O cliente foi atacado e uma CA falsa foi injetada em suas autoridades raiz confiáveis ​​- permite que o invasor gere qualquer certificado de sua preferência e o cliente confiará nele. O malware tende a fazer isso para, por exemplo, redirecioná-lo para sites bancários falsos.
Especialmente o # 2 é bastante desagradável, mesmo se você pagar por um certificado altamente confiável, seu site não será de forma alguma bloqueado por esse certificado, você deve confiar em todas as CAs no navegador do cliente, pois qualquer uma delas pode gerar um certificado falso para seu site é tão válido. Também não requer acesso ao servidor ou ao cliente.
Existem também ferramentas como sslstrip , que tentam reescrever links https em links http de forma transparente.
— mpontillo de
Outro ponto sobre a verificação de certificado é que o cliente precisa verificar o nome do host. Não é bom o suficiente para verificar se o certificado é genuíno, tem que ser emitido para a entidade com a qual você deseja falar (veja aqui e aqui ). Quanto ao sslstrip, em última análise, cabe ao usuário verificar se deseja usar SSL / TLS, infelizmente (embora o HSTS possa ajudar).
Eu poderia escrever um plugin do Chrome (ou qualquer outro navegador) que intercepte os dados ANTES do navegador criptografá-los?
Outro motivo é o "abuso de confiança", como no caso da TürkTrust.
— cerimônia de
@Remover Na verdade não ... # 1 é a chave privada no servidor, emparelhada com a chave pública genuína. Nesse cenário, você falaria com o servidor real, mas outra pessoa poderia descriptografar o tráfego ficando no meio. Eles não podem modificar o certificado. # 2 envolve o envio de um certificado totalmente diferente, emitido por uma CA "confiável" que parecerá ser legítima para o cliente. O invasor pode então fazer solicitações de proxy em seu nome e ver as mensagens dessa maneira. Ambos resultam em um compromisso, mas o nº 1 está sob seu controle. # 2, infelizmente, não é.
Em primeiro lugar, descreverei brevemente o procedimento de autenticação como o entendo, talvez eu esteja errado nessa etapa. Assim, um cliente inicia uma conexão e um servidor responde com uma combinação de chave pública, alguns metadados e assinatura digital de uma autoridade confiável.
O servidor responde com uma cadeia de certificados X.509 e uma assinatura digital assinada com sua própria chave privada.
Então o cliente toma a decisão se ela confia no servidor
criptografa alguma chave de sessão aleatória com a chave pública e a envia de volta.
Não. O cliente e o servidor se envolvem em um processo de geração de chave de sessão mútua, pelo qual a chave de sessão em si nunca é transmitida.
Esta chave de sessão pode ser descriptografada apenas com a chave privada armazenada no servidor.
O servidor faz isso
e então a sessão HTTPS começa.
A sessão TLS / SSL começa, mas há mais etapas primeiro.
Então, se eu estiver correto acima, a questão é como o ataque man-in-the-middle pode ocorrer em tal cenário?
Fazendo-se passar por servidor e agindo como ponto de extremidade SSL. O cliente teria que omitir qualquer etapa de autorização. Infelizmente, a única etapa de autorização na maioria das sessões HTTPS é a verificação do nome do host.
Quero dizer que mesmo se alguém interceptar a resposta do servidor (por exemplo, www.server.com) com a chave pública e, em seguida, com alguns meios, deixe-me pensar que ele é www.server.com, ele ainda não será capaz de descriptografar minha chave de sessão sem a chave privada.
Veja acima. Não há chave de sessão para descriptografar. A conexão SSL em si é segura; é com quem você está falando que pode não ser seguro.
Falando sobre autenticação mútua, é tudo sobre a confiança do servidor sobre a identidade do cliente? Quer dizer, que a cliente já pode ter certeza que está se comunicando com o servidor certo, mas agora o servidor quer saber quem é o cliente, certo?
E a última pergunta é sobre a alternativa à autenticação mútua. Se eu atuar como cliente na situação descrita, e se eu enviar um login / senha no cabeçalho HTTP após o estabelecimento da sessão SSL? A meu ver, essas informações não podem ser interceptadas porque a conexão já está protegida e o servidor pode confiar nela para minha identificação. Estou errado?
Quais são as desvantagens dessa abordagem em comparação com a autenticação mútua (apenas as questões de segurança são importantes, não a complexidade da implementação)?
É tão seguro quanto o nome de usuário / senha, que são muito mais fáceis de vazar do que uma chave privada.
Obrigado pela sua explicação. A única coisa que não entendi é por que você disse que um cliente não envia uma chave de sessão para um servidor. Bem, talvez eu tenha usado uma terminologia errada, aqui esse dado é chamado de "segredo pré-mestre", mas de qualquer forma, ele não é enviado pelo cliente e é descriptografado com a chave privada do servidor?
@VadimChekry O segredo pré-mestre não é a chave de sessão. É um dos vários dados usados ​​para gerar a chave de sessão, independentemente em ambas as extremidades. O processo é descrito em RFC 2246.
@Chris Você é muito menos vulnerável, no entanto, a falsificação de endereço IP é possível. Não há substituto para verificar a identidade do par no certificado por conta própria.
— Marquês de Lorne,
+1 Esta é uma resposta muito boa, na maior parte. No entanto, alguns pontos carecem de explicação com respostas de uma palavra. Você poderia torná-la uma resposta definitiva se expandir e / ou elaborar os referidos pontos (isto é, em vez de "não", você poderia mencionar brevemente o que realmente acontece.) No corpo principal. Isso realmente esclareceria algumas coisas. Obrigado.
— vozes de
@ tjt263 O primeiro 'não' fornece uma explicação do que realmente acontece. Os próximos dois 'não' referem-se ao mesmo equívoco que produziu o primeiro 'não' e têm a mesma explicação. O próximo e final 'não' refere-se a 'estou errado' e refere-se às informações recém-citadas do OP. É difícil, portanto, entender o que você acha que realmente está faltando aqui.
Qualquer pessoa na estrada entre o cliente e o servidor pode encenar um ataque man in the middle ao https. Se você acha que isso é improvável ou raro, considere que existem produtos comerciais que sistematicamente descriptografam, fazem a varredura e criptografam novamente todo o tráfego SSL em um gateway de internet. Eles trabalham enviando ao cliente um certificado SSL criado em tempo real com os detalhes copiados do certificado SSL "real", mas assinado com uma cadeia de certificados diferente. Se esta cadeia terminar com qualquer uma das CAs confiáveis ​​do navegador, este MITM ficará invisível para o usuário. Esses produtos são vendidos principalmente a empresas para "proteger" (policiar) redes corporativas e devem ser usados ​​com o conhecimento e consentimento dos usuários. Porém, tecnicamente, não há nada que impeça seu uso por ISPs ou qualquer outra operadora de rede. (Seria seguro presumir que o NSAcom pelo menos uma chave de assinatura de CA raiz confiável ).
Se estiver servindo uma página, você pode incluir um cabeçalho HTTP indicando com qual chave pública a página deve ser assinada. Isso pode ajudar a alertar os usuários sobre o MITM de sua conexão "segura", mas é uma técnica de confiança no primeiro uso. Se Bob ainda não tiver um registro do pino da chave pública "real", Mallory apenas reescreve o cabeçalho pkp no documento. A lista de sites que usam essa tecnologia (HPKP) é deprimente. Inclui google e dropbox, para seu crédito. Normalmente, um gateway de interceptação de https percorrerá as páginas dos poucos grandes sites confiáveis ​​que usam HPKP. Se você vir um erro de HPKP quando não o esperava, tenha cuidado.
Em relação às senhas, tudo em uma conexão https é protegido por https, exceto o nome de domínio, que precisa estar em aberto para que a solicitação possa ser encaminhada. Em geral, é recomendado não colocar senhas na string de consulta, onde elas podem ficar em logs, favoritos, etc. Mas a string de consulta não é visível a menos que https esteja comprometido.
Mas isso significa que esse equipamento MITM (aquele que descriptografa / verifica e criptografa novamente o tráfego) precisa ter acesso a um dos CA confiáveis, certo? (para "falsificar" o certificado do servidor). Vamos dizer que isso aconteça. Então alguém interrompe isso, a informação se torna pública, e haverá um escândalo no presencial e o certificado de CA será removido de todos os navegadores, certo? Quer dizer, idealmente ...
Não não. A "Inspeção SSL" no gateway precisa criar e assinar certificados dinamicamente, mas não precisa de um certificado raiz para fazer isso. Tem algum certificado intermediário, que tem uma corrente. Se o seu navegador confia na raiz da cadeia ou não, determina se você verá um erro de certificado. No trabalho, fomos solicitados a instalar o fortinet root cert para que nossos navegadores não apresentassem erros de certificado. Mas se a cadeia terminou com um certificado já confiável, é transparente.
Um colega de trabalho estava usando uma compreensão limitada de por que essas técnicas de MITM de rede corporativa são uma má ideia para o Google forçar SSL - ele poderia realmente ter um pouco de correção?
— EmSixTeen
Desculpe, não entendi a pergunta!
Não tão correto. Nesse tipo de ataque, o servidor itermediário obtém sua solicitação e a envia para o destino em seu nome. e então responder a você com o resultado. Na verdade, é um servidor man-in-the-middle que torna a conexão segura com você, e não com o servidor real que você pretende comunicar. é por isso que você DEVE sempre verificar se o certificado é válido e confiável.
poderia estar correto
Se você tiver certeza de que a conexão segura é confiável, será seguro enviar o nome de usuário / senha.
— Boynux
Sobre 2 - Estou assumindo que o cliente está verificando minuciosamente os metadados enviados pelo servidor durante o procedimento de estabelecimento da conexão e que o cliente não confia em TODOS os certificados. Portanto, tal cenário não seria possível se - a) um cliente não estivesse fazendo o que eu disse acima, ou b) um intermediário tenha em algum lugar um certificado assinado por uma CA confiável?
— Vadim Chekry de
Acontece muito raro que o servidor intermediário envie certificado válido, no ano passado aconteceu com o Comodo CA se bem me lembro. Mas normalmente, se for uma conexão confiável, é totalmente segura.
Tudo o que você disse está correto, exceto a parte sobre a chave de sessão. O objetivo das CAs é derrotar um ataque man-in-the-middle - todo o resto é feito pelo próprio SSL. A autenticação do cliente é uma alternativa ao esquema de nome de usuário e senha.