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.

1. 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.

2. 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.

3. 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?

4. 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)?

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.

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

Corrigir.

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.

Não.

O servidor faz isso

Não.

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?

Corrigir.

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?

Não.

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.

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.

1. Corrigir
2. 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.
3. poderia estar correto
4. Se você tiver certeza de que a conexão segura é confiável, será seguro enviar o nome de usuário / senha.

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.