Apache: Validar a cadeia de confiança SSL para impedir ataques MITM?

11

Acabei de perceber que os ataques man-in-the-middle SSL são muito mais comuns do que eu pensava, especialmente em ambientes corporativos. Eu já ouvi falar e vi várias empresas que possuem um servidor proxy SSL transparente. Todos os clientes estão configurados para confiar neste certificado do proxy. Basicamente, isso significa que o empregador pode, teoricamente, interceptar até mesmo o tráfego criptografado SSL sem nenhum aviso no navegador. Como mencionado acima, os clientes vêm com o certificado confiável. Isso só pode ser revelado pela validação manual do certificado que está sendo usado.

Para mim, parece que o empregador utiliza sua posição superior para espionar o tráfego SSL do funcionário. Para mim, isso torna todo o conceito de SSL não confiável. Eu mesmo testei uma configuração semelhante usando o mitmproxy e consegui ler a comunicação entre o cliente e meu servidor de banco eletrônico. Esta é uma informação que não deve ser revelada a ninguém.

Portanto, minha pergunta é bastante simples: como posso validar a cadeia de confiança no servidor? Quero garantir que o cliente use o certificado do meu servidor e apenas uma cadeia de confiança. Gostaria de saber se isso pode ser alcançado pela configuração SSL do Apache? Isso seria conveniente, pois poderia ser aplicado a muitos aplicativos facilmente. Se isso não for possível, alguém sabe como fazer isso em PHP? Ou você tem outras sugestões?

— Aileron79
fonte

1

Tudo bem se o empregador vê o tráfego dos funcionários. Você está usando os recursos do empregador (computador, conexões de rede etc.), eles não são seus. E se você teme que o emplyer possa ver os dados que você transmite para sua conta bancária - faça-o em casa, não no trabalho. E as tentativas de violar a política de segurança corporativa podem ser objeto de um processo contra você.

— precisa saber é o seguinte

2

Em muitas empresas europeias, o uso privado de equipamentos de escritório é regulamentado no contrato de trabalho. Na empresa em que trabalho, posso navegar em particular, isso não é um problema. Há exceções como pornografia, compartilhamento de arquivos etc. Ao mesmo tempo, existem leis que proíbem as empresas de espionar seus funcionários. Assim, para mim - e muitos outros - NÃO é bom quando os empregadores interceptam o tráfego dos funcionários, pois isso é claramente proibido enquanto a navegação privada é tolerada em muitas empresas.

— Aileron79

2

A maioria (na minha experiência) das estações de trabalho pertencentes ao governo dos EUA inclui esses dois avisos a cada login: "As comunicações usando ou dados armazenados neste IS não são particulares, estão sujeitas a monitoramento, interceptação e pesquisa de rotina, e podem ser divulgadas ou usadas para qualquer finalidade autorizada pelo USG. Este IS inclui medidas de segurança (por exemplo, controles de autenticação e acesso) para proteger os interesses do USG - não para seu benefício pessoal ou privacidade ". O uso desses sistemas geralmente é coberto por um contrato assinado estipulando o mesmo. O detalhe principal é que o proprietário do sistema está se protegendo contra você.

— Randall

Essa é uma das muitas diferenças entre os EUA e a Europa. Os termos @Randall citados acima são ilegais na maioria dos países europeus.

— Aileron79

Os termos que citei estão incompletos, outros termos listam atividades que explicitamente não devem ser monitoradas. Não consigo encontrar nenhuma referência de que os empregadores europeus afirmam que essas condições prévias não podem condicionar o uso de seus computadores (trabalho para uma empresa que opera na Europa, configurando esses processos de monitoramento, embora trabalhe para uma divisão que não está fazendo negócios no mundo inteiro. Europa), mas pode encontrar referências que sugerem que esses termos não são ilegais, desde que explícitos e transparentes.

— Randall

9

Eu acho que essa pergunta seria mais apropriada para security.stackexchange.com, onde o tópico do MITM é discutido em muitas questões. Mas mesmo assim:

A validação do certificado do servidor é feita apenas no cliente e não pode ser movida de alguma forma para o servidor, pois o ponto de validação do certificado no cliente é que os clientes precisam ter certeza de que estão falando com o servidor correto e não podem confiar no servidor (não confiável) para tomar essa decisão para o cliente.

No caso de interceptação SSL, o cliente TLS, da perspectiva do servidor, é o firewall / AV interceptador SSL. Portanto, o problema no lado do servidor é detectar se está falando com o cliente esperado (o navegador) ou não (o firewall / AV). A maneira mais segura de fazer isso é usar certificados de cliente para autenticar o cliente - e, de fato, a intercepção de SSL não funcionará se a autenticação do cliente for usada, ou seja, o handshake do TLS falhará, pois o MITM não pode fornecer o certificado de cliente esperado.

Somente certificados de cliente raramente são usados. Além disso, um handshake TLS com falha não significaria que o cliente pode se comunicar com o servidor sem interceptação SSL, mas que o cliente não pode se comunicar com o servidor. Uma maneira alternativa seria usar algumas heurísticas para detectar o tipo de cliente TLS com base na impressão digital do handshake TLS, ou seja, tipo e ordem das cifras, uso de extensões específicas ... Embora um proxy de interceptação SSL possa, em teoria, emular o original Olá, perfeitamente, a maioria não. Consulte também Detectar man-in-the-middle no lado do servidor para HTTPS ou a seção III Heurísticas de implementação do TLS em O impacto na segurança da interceptação HTTPS .

— Steffen Ullrich
fonte

14

Para mim, parece que o empregador utiliza sua posição superior para espionar o tráfego SSL do funcionário. Para mim, isso torna todo o conceito de SSL não confiável

O problema não está no conceito de SSL nem na implementação técnica, mas antes que outra pessoa tenha controle total sobre um ponto final da conexão, ou seja, sua estação de trabalho.
Essa é a raiz do risco de segurança real ...

De uma perspectiva de segurança, é a sua estação de trabalho comprometida que quebra a cadeia de confiança que, em circunstâncias normais, impede que um MITM seja bem-sucedido.

Como posso validar a cadeia de confiança no lado do servidor?

Você não pode. Isso é feito no lado do cliente.

Dependendo do seu caso de uso, o que você pode fazer é a Fixação de Chave Pública HTTP RFC 7469, na qual você enviou um cabeçalho adicional ao cliente com uma lista (hashes) de seus certificados SSL reais ou das CAs que você usa.

— HBruijn
fonte

4

O HPKP não ajudará, pois será ignorado pelos navegadores se o certificado for assinado por uma CA explicitamente adicionada. Isso é feito especificamente para permitir a interceptação de SSL por uma parte confiável, ou seja, um firewall corporativo ou um AV de desktop local (muitos fazem interceptação de SSL para).

— Steffen Ullrich

2

Você está absolutamente correto: §2.6 da RFC: "É aceitável permitir que a Validação de PIN seja desativada para alguns hosts de acordo com a política local. Por exemplo, um UA pode desativar a Validação de PIN para hosts fixos cuja cadeia de certificados validada termina em uma âncora de confiança definida pelo usuário, em vez de uma âncora de confiança incorporada ao UA (ou plataforma subjacente). "

— precisa saber é o seguinte

3

Esse é o caminho errado. O servidor não verifica a cadeia de confiança. É o cliente. Portanto, a razão pela qual a empresa usa dessa maneira é proteger o ambiente da empresa e verificar o que o funcionário está fazendo no seu horário de trabalho.

— beli3ver
fonte

Bem, sim, eu sei que isso provavelmente não pode ser evitado apenas no servidor. No entanto, algumas JS do lado do cliente também podem ser enganadas. Aliás, espionar funcionários é ilegal na maioria dos países europeus. Como operador de site, quero evitar que meus clientes sejam enganados; assim, me pergunto se há alguma maneira de validar a cadeia de confiança de maneira segura.

— Aileron79

Talvez não seja permitido. Mas a maioria das empresas não espiona os funcionários, que querem apenas proteger a rede da empresa, e a maioria dos filtros ou scanners da web deve interromper a conexão SSL para verificar isso. Portanto, este é um homem legal no meio ataque

— beli3ver

Eu entendo o seu ponto. No entanto, esta pergunta é sobre como posso garantir que uma conexão HTTPS seja criptografada de ponta a ponta. A configuração que descrevi acima é muito comum em ambientes corporativos, mas o mesmo tipo de ataque pode ser usado por garotos ciumentos para espionar suas namoradas ou por proprietários que interceptam o tráfego de inquilinos. Essas pessoas ainda precisam ser induzidas a instalar um certificado, mas essa é a parte mais fácil. No entanto, isso é ilegal - e ainda me pergunto se há alguma maneira de garantir que uma conexão HTTPS seja realmente criptografada e2e.

— Aileron79

3

Isso não é possível. Quando o certificado raiz foi alterado no cliente, você não tem como verificar. O servidor não faz a verificação, o cliente faz a verificação.

— precisa saber é

3

Você poderia (mais ou menos), mas a verdadeira questão é se você DEVE .

Mas cuidado, não é tão simples quanto mudar uma bandeira no apache.conf.

Além disso, como o "invasor" (por exemplo, empregador) controla o computador cliente, ele sempre pode frustrar suas tentativas, se estiver inclinado a investir esforço suficiente (pelo lado positivo, a menos que você seja um peixe muito grande, provavelmente não o é). inclinado, para que você cumpra sua meta de que seus usuários não possam se conectar a você, a menos que seja seguro))

você pode reimplementar o TLS em javascript e verificar se o certificado do cliente está conectado é o certificado do seu site.
se você tiver sorte , o usuário pode estar usando o navegador em que o Javascript do lado do cliente pode obter informações sobre o certificado remoto usado (e, portanto, verificá-lo facilmente com relação ao valor codificado do certificado do servidor).
você pode usar JavaScript para executar sua criptografia personalizada . Portanto, mesmo quando o TLS MiTM mal-sucedido da empresa tivesse sucesso, ele ainda não lhe daria acesso aos seus dados. Obviamente, se houver interesse suficiente (e já que eles controlam o cliente), eles poderão substituir rapidamente o seu javascript seguro pelo deles, o que também registra (ou altera) todas as informações em trânsito.

Além disso, como as empresas que empregam proxies TLS MiTM também costumam controlar completamente o computador cliente, elas podem instalar facilmente a tela e o keylogger para gravar vídeos de tudo o que o usuário vê e gravar todas as teclas (e movimentos do mouse) digitados pelo usuário. Como você pode ver, quando o invasor É o cliente, não há maneira absolutamente segura de enganá-lo. É realmente apenas uma questão de quanto eles vão incomodar ... E algumas das soluções acima podem ser boas o suficiente para você.

— Matija Nalis
fonte

" você poderia reimplementar o TLS em javascript " Como? Onde?

— precisa

@curiousguy esse texto qouted é um link - clique sobre ele, e ele vai levá-lo a uma outra pergunta e resposta, e finalmente para digitalbazaar projeto / Forge

— Matija Nalis

Então, quando é utilizável? Para qual finalidade?

— precisa

@curiousguy entre muitas outras coisas, especialmente para os propósitos desta pergunta sobre falha do servidor. Quando você possui seu próprio JS TLS em execução no cliente, esse JS saberá exatamente a qual servidor TLS o cliente foi conectado (e sua chave pública). Em seguida, você pode comparar essa chave pública com a chave pública do servidor autorizado (também codificada em seu JS) e se você saberá se elas são iguais. Se eles não forem iguais, sua conexão foi invadida pelo MiTM.

— Matija Nalis