Como verificar/inspecionar conexões de rede de saída no Linux para garantir que o conteúdo e as senhas estejam realmente criptografados?

• O sinalizador /ssl aparentemente usa TLS.
• O sinalizador /tsl não funciona.

O programa usa o termo "SSL" para significar o uso direto (também conhecido como "implícito"; "modo wrapper") de SSL/TLS em uma porta dedicada, onde o handshake TLS começa no 1º byte – da mesma forma que HTTPS – e o termo "TLS" para significar o uso explícito de SSL/TLS na porta de texto simples, onde o cliente primeiro recebe uma saudação em texto simples, emite o STARTTLScomando e então o handshake TLS começa.

Embora ambos usem o mesmo protocolo TLS e ambos possam ser igualmente seguros, atualmente considera-se que o SSL/TLS direto na porta dedicada é mais seguro porque é mais fácil de programar — ele efetivamente garante "TLS ou nada" — enquanto o STARTTLS na porta de texto simples tem muitas oportunidades para erros de implementação.

(Por exemplo, alguns clientes não deixam claro qual configuração é "STARTTLS obrigatório" (seguro) e qual é "STARTTLS se oferecido" (inseguro). Alguns clientes têm bugs e podem ser convencidos a continuar, apesar de STARTTLS não ser oferecido; eu até vi um cliente LDAP que, se definido como STARTTLS, simplesmente não o ativava e continuava em texto simples.)

Cabe ao administrador de cada servidor decidir se deseja oferecer TLS direto na porta 993 para IMAP, ou se deseja oferecer STARTTLS na porta 143 para IMAP, ou ambos. O Gmail oferece apenas TLS direto.

Essa última questão é meu foco de caso de uso. A documentação implica que se o sinalizador /secure não estiver definido, a senha será enviada como texto simples! (A menos que isso seja algo como criptografar a string apesar da conexão em si talvez já estar criptografada?) Se for, então não importa se todo o resto estiver criptografado, porque qualquer invasor pode simplesmente se virar e usar as credenciais que acabou de encontrar. Não, não estamos falando sobre autenticação de dois fatores, pois isso evita explicitamente esse tópico e é uma desculpa para enfraquecer o reforço da autenticação base.

A /secureopção funciona em um nível diferente: ela não interage com a segurança de transporte (como no TLS executado "por baixo" do IMAP e criptografando todos os dados transferidos), em vez disso, ela solicita um handshake de autenticação seguro no nível do protocolo IMAP/POP/SMTP.

A maioria dos protocolos criados antes da era atual do TLS onipresente tende a oferecer suporte a algum tipo de handshake de autenticação que não envia apenas a senha bruta — normalmente uma forma de "desafio/resposta" — para que, mesmo que seu e-mail tenha sido transmitido sem criptografia, pelo menos sua senha não possa ser roubada.

Por exemplo, HTTP tem Kerberos e Digest; SMB tem Kerberos e o infame NTLM; e similarmente POP/IMAP/SMTP tem a opção de suportar CRAM-MD5 e SCRAM-SHA1 (e também o mesmo Kerberos e NTLM).

É /securepara isso que serve a opção: ela pede à biblioteca do cliente IMAP para limitar a seleção de mecanismos àqueles que não revelam credenciais diretamente (restringindo as opções de "PLAIN/Kerberos/CRAM/NTLM" para apenas "Kerberos/CRAM/NTLM").

Então, concluindo: quando a documentação da /secureopção diz "como texto simples", o que realmente quer dizer é "nenhuma proteção adicional além do resto da conexão IMAP" – o que no momento da escrita significava de fato "nenhuma proteção" porque poucos, se algum, servidores de e-mail suportavam SSL. Claro, se TLS for usado para toda a conexão, então a senha "simples" também será protegida por TLS.

(Atualmente, é raro que servidores suportem CRAM ou SCRAM, pois eles dificilmente oferecem vantagens quando o TLS é usado, além de trazer suas próprias limitações, enquanto o Kerberos só é encontrado em servidores de e-mail locais corporativos.)

Qual programa sniffer devo usar para poder inspecionar o conteúdo (não apenas os cabeçalhos) das solicitações de rede?

Qualquer.

Versões antigas do tcpdump tinham um limite padrão de capturar apenas os primeiros 64 bytes de cada pacote (que pode ser aumentado usando -s); versões modernas capturam o pacote inteiro. Use -Aou -xpara mostrar o conteúdo bruto dos pacotes.

O Tshark usa as opções -Ve -Opara expandir "protocolos" individuais (como mostrado na interface gráfica do usuário do Wireshark), por exemplo, -VO imap,datapara expandir cargas úteis IMAP e/ou 'dados brutos'.

Se forem aplicáveis: tanto o tshark quanto o tcpdump parecem claramente ser programas tail; como limito sua saída à porta 993?

Ambos usam a sintaxe libpcap e, consequentemente, a sintaxe pcap-filter(7) para o filtro de captura; o tshark usa a opção -fpara especificar o filtro de captura; o tcpdump não.

tcpdump -A -n -i eth0 "port 993"

Um filtro de port 993corresponde tanto a TCP quanto a UDP. Você pode ser específico e usar tcp port 993. Dada a questão, no entanto, você deve capturar port 993 or 143.

Ao capturar via SSH, sempre use pelo menos not port 22se você não estiver limitando por host/porta – não filtrar nada faz com que cada pacote impresso acione outro pacote e assim por diante, gerando uma enxurrada de saídas mesmo que a rede esteja razoavelmente ociosa.

Se muitas coisas estão acontecendo na porta 993 (servidor de uso mínimo, mas ainda assim), como posso reduzir ainda mais a saída para poder encontrar as solicitações que estou fazendo?

Limite-o ao endereço IP do servidor específico usando hostou net.

tcpdump -Ai eth0 "host imap.example.com and (port 993 or 143)"

Como alternativa, capture em um arquivo .pcap e carregue-o em um Wireshark instalado localmente, o que permite filtrar por "conversa" específica – clique com o botão direito do mouse em um pacote e selecione "Seguir > Fluxo TCP" para ver apenas os dados dessa conexão.

tcpdump -i eth0 -w foo.pcap "port 993"

Há uma maneira de capturar via SSH diretamente em uma interface gráfica local do Wireshark:

ssh root@myserver "tcpdump -i eth0 -s 65535 -Uw - port 993" | wireshark -k -i -

Se aplicável, como posso esclarecer cabeçalhos, conteúdo ou ambos para ter uma ideia do que estou vendo?

O "TCP Stream" do Wireshark extrairá automaticamente apenas a carga TCP.

Qual é uma maneira simples/fácil de enviar uma solicitação de texto simples (em qualquer contexto) que eu possa usar para contrastar as solicitações (espero) criptografadas da porta 993?

Clientes TCP básicos como nc, ncatou telnetpodem ser usados ​​para conectar a qualquer porta TCP e enviar texto simples. Se você fizer isso na porta 993, o servidor irá desconectá-lo, pois espera um handshake TLS válido, mas seu pacote ainda estará visível em uma captura.

Para uma melhor comparação, você precisa de um servidor IMAP que aceite conexões TLS na porta 993 e conexões plain/starttls na porta 143. Como o Gmail só faz a primeira, um cliente IMAP tentando falar texto simples na porta 993 geralmente nem chega à etapa de autenticação – ele espera uma eternidade pela "saudação" inicial que os servidores IMAP enviam.