Ataque man-in-the-middle no cenário SSL

Question

Estou tentando entender como um ataque man-in-the-middle afetaria meu servidor web.

Eu tenho um certificado autoassinado. Este certificado pode ser falsificado através do ataque man-in-the-middle, o que significa que tudo o que eu enviar do navegador será interceptado e modificado?

Se a solicitação for modificada, ela não será descriptografada pelo servidor web, pois o certificado no servidor é diferente. Isso está correto?

A solicitação enviada pelo navegador pode ser interceptada e redirecionada, mas os dados do meu servidor não serão afetados, correto?

Estou começando a entender a teoria por trás dos certificados, mas seria ótimo se alguém pudesse fornecer um exemplo do mundo real do ataque man-in-the-middle e ver quais problemas ele causou.

Obrigado

Answer 1

Como afirmei na minha resposta anterior asua pergunta, os ataques man-in-the-middle (se bem-sucedidos) podem possuir todos os dados transmitidos para um canal criptografado.

Certificados, tanto autoassinados quanto emitidos a partir de uma raiz confiável, podem ser falsificados, portanto, não se deixe levar por uma falsa sensação de segurança se emitir um para seus usuários a partir de uma raiz confiável. O único problema que tenho que superar com um emitido por uma raiz confiável éfazer com que seu usuário aceite o meu quando eu envenenar o computador dele. Se você pensar na maioria dos usuários finais, quão fácil isso seria?

Você consegue ver os problemas agora?

Depois que o usuário final aceita MEU certificado, eu possuo a conexão desse ponto em diante e todos os dados passam pela minha máquina.

Answer 2

Basicamente, o que acontece é que você autoassinou seu certificado e não tem como provar que ele é válido. Portanto, ele criptografa o tráfego perfeitamente, mas você não pode provar que é seu. Se um hacker conseguir se colocar entre o seu site e o computador do usuário e interceptar o tráfego, ele poderá descriptografar o tráfego e ler o que está acontecendo. (Ele também pode fazer isso registrando um nome de domínio semelhante ao seu e aguardando um erro de digitação ou enviando um e-mail que os direcione para o site dele e não para o seu)

User ****** Hacker **** Your website

A razão pela qual ele pode fazer isso é que também pode apresentar um certificado autoassinado. Então o usuário está realmente em comunicação com o hacker e não com você. O usuário não consegue perceber a diferença. Na verdade, se ele quiser, o Hacker pode criptografar novamente o tráfego e enviá-lo de volta ao seu site e iniciar seu próprio fluxo de comunicação com o seu site usando as credenciais do usuário. Ou apenas observe o tráfego claramente enquanto ele se move para frente e para trás.

Answer 3

Não é que ele possa modificar o tráfego. É que o handshake SSL começa sem criptografia e o servidor envia um certificado SSL para o cliente usar a partir desse ponto. Se o invasor estiver lá desde o início, ele poderá substituir esse certificado inicial pelo seu próprio e, em seguida, usar aquele que o servidor enviou para criptografar/descriptografar o tráfego de/para o servidor, usando seu próprio certificado para enviá-lo a você.
Se o certificado for assinado por uma autoridade de certificação, será um pouco mais difícil substituí-lo por um falso que também seja assinado por uma CA. O invasor pode facilmente substituir este certificado por um autoassinado, daí o aviso.

Answer 4

Há dois pontos a serem considerados ao verificar um certificado:

• verificar se foi emitido por uma entidade em que você confia, e
• verificando se corresponde à identidade do servidor que você está tentando contatar.

Certificados emitidos por CA

OInfraestrutura de chave pública usando certificado X.509. especificaçãodefine a estrutura a implementar para isso. É um modelo hierárquico onde você obtém uma árvore, cuja raiz são as Autoridades de Certificação (CA) e suas folhas são os certificados da entidade final (em particular certificados de servidor).

Os certificados de CA raiz tendem a ser autoassinados. Vários deles estão incluídos por padrão em seu sistema operacional ou navegador. Essa é a parte do "salto de fé", em que você confia no fornecedor do sistema operacional/navegador para verificar se as CAs fazem seu trabalho corretamente. Algumas das grandes CAs comerciais são Verisign, Thawte, ...

Uma CA pode então assinar outros certificados. Você pode verificar um certificado que nunca viu antes, verificando se ele foi assinado por uma CA em que você confia. Também pode haver CAs intermediárias. Por exemplo, o certificado https://www.google.com/foi assinado por "Thawte SGC CA", que foi assinado por"VeriSign, Inc./Autoridade de Certificação Primária Pública Classe 3"(Estou abreviando os nomes aqui para simplificar). O trabalho da CA é verificar (por meios externos à PKI) se a pessoa/instituição para a qual emite o certificado é o proprietário legítimo desse nome de host (por exemplo, www.google.comaqui). A forma como essa verificação fora de banda varia, para certificados não EV, isso geralmente é feito simplesmente enviando um e-mail para o endereço que registrou o nome de domínio (disponível no site).quem édiretório).

Feito isso, suponha que você não saiba se deve confiar https://www.google.com/, o cliente verifica esse certificado em relação às âncoras de confiança que possui (as CAs, geralmente pré-importadas por fornecedores de sistema operacional/navegador). Se você se conectar www.google.com, o navegador obterá o certificado e poderá trabalhar a cadeia até o emissor principal (há uma entrada de emissor em cada certificado), até encontrar um em que confie (neste caso, o da Verisign). Até agora tudo bem, o certificado é confiável. O segundo passo consiste em verificar se este certificado é mesmo para esta máquina. Para HTTPS, isso é feito verificando se o nome do host está na extensão de nome alternativo da entidade do certificado ou, como substituto, se está na entrada "Nome Comum" (CN) no nome distinto da entidade. Isto é explicado emRFC 2818 (identidade do servidor).

Aqui as possíveis tentativas de ataque são as seguintes:

• Os invasores falsificam um certificado (para esse nome de host ou não), com sua própria CA. Como a CA não é reconhecida pelo seu navegador, o certificado não será verificado. Mesmo que falsificassem o nome do emissor, não seriam capazes de falsificar a assinatura (porque você verifica usando a chave pública usando os certificados CA em que já confia). Um dos maiores problemas aqui estava na força da assinatura: ataques de colisão foram demonstrados usando o algoritmo de digestão MD5, então as CAs agora usam SHA-1, que é considerado mais robusto. Se você considera RSAwithSHA1 ou DSAwithSHA1 suficientemente robusto, não deverá ter problemas nisso.
• Os invasores obtêm um certificado legítimo de uma CA conhecida, mas para um nome de host diferente (já que uma CA não deve emitir para outra pessoa). Digamos que eles consigam www.example.com. Você está tentando se conectar www.google.com, eles redirecionam o tráfego para sua caixa, que mostrará um certificado que será verificável por uma CA em que você confia, mas para www.example.com. É aqui que a verificação do nome do host é importante. Seu navegador irá avisá-lo de que você não está conectado ao host pretendido.

Este sistema foi projetado para garantir que, se um MITM redirecionar o tráfego para sua máquina, o cliente não aceitará a conexão. É claro que isso só é válido se o usuário não ignorar os avisos mostrados pelo navegador.

Certificados autoassinados

É o mesmo princípio, exceto que você é a CA, e esse certificado autoassinado também pode ser diretamente o certificado do servidor. Se você criar seu próprio certificado autoassinado e colocá-lo em sua máquina, também poderá importá-lo em seu navegador como uma autoridade confiável, caso em que seguirá o mesmo procedimento descrito acima.

Alguns navegadores, como o Firefox, permitem adicionar exceções permanentes a essas regras. Se você souber, por algum outro meio (por exemplo, o administrador lhe deu o certificado pessoalmente), qual é o certificado da máquina à qual deseja se conectar, você pode optar por confiar neles explicitamente, mesmo que não tenham sido assinados por uma CA em que você confia ou se o nome não corresponder. É claro que, para isso, você precisa saber a priori e explicitamente o que deve ser esse certificado específico.

Se em ambos os casos o usuário optar por ignorar os avisos e aceitar ser redirecionado para uma conexão com um certificado não confiável, então o MITM (com esse certificado não confiável) poderá ver/redirecionar/alterar o tráfego.