Fundo
Sou um desenvolvedor web tentando garantir que as conexões IMAP de saída sejam feitas com segurança . Infelizmente, estou preso usando a extensão IMAP do PHP (por enquanto). A documentação para imap_open() é... insuficiente. Exemplos:
- A ordem dos sinalizadores para o
mailbox
parâmetro é aparentemente importante o suficiente para sabotar strings não compatíveis, mas não o suficiente para documentar. - Aparentemente, a
/ssl
bandeira usa TLS. - A
/tsl
bandeira não funciona. - A
/secure
bandeira resulta emCan't do secure authentication with this server
.
Essa última questão é meu foco de caso de uso. A documentação implica que se o /secure
sinalizador não for 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.
Isso funciona: {mail.example.com:993/ssl/imap}
.
Isso não funciona: {mail.example.com:993/ssl/imap/secure}
.
Existem muito poucas páginas que os mecanismos de busca retornam com o erro Can't do secure authentication with this server
, e isso implica no que vejo a maioria das pessoas fazendo: copiar e colar o código às cegas, fazendo apenas pequenas modificações e então presumindo que, porque funciona, a implementação está correta.
No entanto, insisto em verificar a aparência. Isso me leva a lembrar do programa Fiddler no Windows no final dos anos 2000, quando a Microsoft estava voltando a trabalhar no Internet Explorer. Você podia inspecionar todos os tipos de coisas sobre cada conexão de rede.
Ambiente do servidor
- Tenho cPanel e CloudLinux.
- Tenho acesso root.
- Já dei uma olhada em outros tópicos; meu servidor tem
tshark
etcpdump
instalou. - Ficarei feliz em instalar outro programa se isso facilitar minha vida aqui.
- Os cabeçalhos das mensagens de e-mail sugerem o uso de uma conexão TLS 1.2, mas não sei se esse é meu servidor de envio ou o servidor de recebimento.
- Meu servidor está configurado para TLS 1.2 e 1.3 pelo menos em 443; 1.1, 1.0 e SSL estão desabilitados em 443.
- O protocolo SSL está desabilitado em 443 e 993, embora eu ainda não tenha descoberto como desabilitar o TLS 1.0 e 1.1 na porta 993 (fora do tópico, apenas esclarecendo que pelo menos estou ciente das coisas).
Condições de teste
Estou intencionalmente tentando testar as condições de teste, caso contrário não verei nenhum contraste e, portanto, não aprenderei nada. As instruções do e-mail de e para:
- De example1.com para example1.com (nunca saindo do servidor).
- De example1.com para example2.com (domínio diferente, mas ainda sem sair do servidor).
- De example1.com para differentserver.com (para sair intencionalmente do servidor).
- Quero evitar usar o
/novalidate-cert
sinalizador que parece funcionar bem para solicitações de servidor para o mesmo servidor.
Intenção de Interpretação
Sim, a porta 993 deve ser criptografada, novamente, o ponto principal é verificar o que está acontecendo em vez de usar confiança cega. Idealmente, eu gostaria de fazer uma solicitação de texto simples explicitamente para contrastar uma solicitação criptografada. Obviamente, o contraste seria que com um programa sniffer eu seria capaz de ver a solicitação de texto simples como, bem, texto simples! Então, o exemplo criptografado eu esperaria basicamente apenas dados binários confusos. Se eu puder verificar que as solicitações são aquelas que estou interpretando, então tenho a verificação que estou procurando! Contanto que eu possa repetir esse processo de verificação, então essa é minha resposta! O mais importante é que as credenciais sejam criptografadas, o que eu esperaria depois que os dois servidores tivessem seu "handshake"?
Aspectos técnicos do farejador
Não sou um cara de servidores ou Linux, embora eu consiga me virar no terminal. Então, espero ajuda especificamente com os programas sniffer, por favor:
- Qual programa sniffer devo usar para poder inspecionar o conteúdo (não apenas os cabeçalhos) das solicitações de rede?
- Se forem aplicáveis : ambos
tshark
etcpdump
parecem ser programas de cauda; como limito sua saída à porta 993? - 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?
- Se aplicável, como posso esclarecer cabeçalhos, conteúdo ou ambos para ter uma ideia do que estou vendo?
- 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?
A questão
Como posso inspecionar o tráfego de rede no meu servidor Linux ativo a partir do terminal como root para verificar se as solicitações do meu foco estão realmente criptografadas?
Com efeito aqui no Windows, eu poderia usar o Notepad++ para "inspecionar" um arquivo de texto e lê-lo normalmente. Se eu abrir uma imagem raster, veria os dados binários. Quero garantir que as credenciais estejam realmente sendo criptografadas, apesar da documentação confusa da imap_open()
função do PHP.
A resposta
Um grande obrigado a @grawity. Em resumo:
- Windows para Linux: PuTTY.
- Listar dispositivos de rede:
ifconfig -a | sed 's/[ \t].*//;/^$/d'
. - Inspecionar solicitações de saída da porta 993:
tcpdump -A -n -i [NETWORK DEVICE] "port 993"
.