A complexidade dos protocolos criptográficos e suas implementações torna desafiadora a tarefa de validar a configuração exata de um servidor seguro. Embora existam ferramentas automatizadas, entender o que ocorre "sob o capô" é fundamental. O utilitário de linha de comando do OpenSSL funciona de forma análoga a um telnet ou nc, mas com a capacidade de gerenciar a camada SSL/TLS, oferecendo controle total sobre as camadas subsequentes da comunicação.

Iniciando Conexões de Teste

Para estabelecer uma conexão com um servidor seguro, utilizamos o comando s_client. É necessário informar o endereço e a porta de destino. ``` openssl s_client -connect google.com:443

Ao executar o comando, o OpenSSL exibirá detalhes do handshake, incluindo a cadeia de certificados e os parâmetros da sessão. Caso queira testar uma requisição HTTP simples após a conexão ser estabelecida, você pode digitar manualmente o comando `HEAD`: ```
HEAD / HTTP/1.1
Host: www.google.com

Se o servidor responder com os headers HTTP, a camada de transporte TLS está operando corretamente. ### Análise de Certificados do Servidor

A saída do s_client detalha a hierarquia de confiança. A seção "Certificate chain" mostra a ordem dos certificados entregues pelo servidor: ``` Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com i:/C=US/O=Google Trust Services/CN=GTS CA 1C3 1 s:/C=US/O=Google Trust Services/CN=GTS CA 1C3 i:/C=US/O=Google Trust Services/CN=GTS Root R1

Nesta lista, **s** representa o *Subject* (assunto) e **i** representa o *Issuer* (emissor). Para validar a cadeia, o emissor de um certificado deve corresponder ao assunto do próximo certificado na lista. ### Informações da Sessão TLS

Após o handshake, o OpenSSL resume os parâmetros técnicos da conexão: ```
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data: disabled
Verify return code: 0 (ok)

Os pontos mais críticos aqui são a versão do protocolo (ex: TLSv1.3) e o cipher suite selecionado. Estes dados confirmam se o servidor está utilizando algoritmos modernos e seguros. ### Testando Protocolos com STARTTLS

Protocolos como SMTP, POP3 e IMAP iniciam em texto claro e são "elevados" para criptografia via comando STARTTLS. O OpenSSL automatiza esse processo com a flag -starttls: ``` openssl s_client -connect smtp.gmail.com:587 -starttls smtp

Isso instrui o cliente a enviar os comandos iniciais necessários para o protocolo específico antes de iniciar o handshake TLS. ### Validação de Protocolos e Ciphers Específicos

Para garantir que um servidor não aceita protocolos obsoletos ou para forçar uma versão específica, utilize flags dedicadas: ```
# Testar apenas TLS 1.2
openssl s_client -connect cloudflare.com:443 -tls1_2

# Testar apenas TLS 1.3
openssl s_client -connect cloudflare.com:443 -tls1_3

Se você precisar testar se um servidor suporta um algoritmo de criptografia específico (cipher), use a opção -cipher: ``` openssl s_client -connect portal.exemplo.br:443 -cipher ECDHE-RSA-AES128-GCM-SHA256

Se o handshake falhar com este comando, o servidor provavelmente não suporta esse cipher específico. ### Verificação de Reutilização de Sessão

A reutilização de sessões melhora a performance ao evitar handshakes completos em conexões subsequentes. O OpenSSL pode testar isso com a flag `-reconnect`, que abre a conexão seis vezes consecutivas: ```
echo | openssl s_client -connect api.github.com:443 -reconnect 2>/dev/null | grep -i "reuse"

Uma saída indicando "Reused" nas últimas cinco tentativas confirma que o servidor está gerenciando corretamente os Session IDs ou Tickets. ### Teste de Renegociação Manual

Durante uma sessão ativa no s_client, você pode solicitar uma renegociação enviando o caractere R (seguido de Enter). Isso é útil para verificar como o servidor lida com solicitações de mudança de chaves no meio da conexão: ```

R RENEGOTIATING

Se o servidor suportar e permitir a renegociação iniciada pelo cliente, um novo handshake ocorrerá. Caso contrário, a conexão poderá ser encerrada ou um erro de "no renegotiation" será exibido. ### Identificação de Vulnerabilidades Legadas (BEAST)

O ataque BEAST explora vulnerabilidades em protocolos antigos (SSLv3 e TLS 1.0). Para verificar se o servidor ainda é vulnerável, tente forçar uma conexão usando esses protocolos: ```
openssl s_client -connect servidor-legado.com:443 -tls1

Se a conexão for estabelecida com sucesso, o servidor ainda permite o uso de protocolos considerados inseguros para padrões moedrnos.