Você não pode dizer a partir desse erro se o seu servidor está negociando SSLv3 ou TLSv1 (você pode querer dar uma olhada em esta questão no Unix & Linux e verifique se ele está desativado em todos os lugares no apache ...) --- o código-fonte 1.1.0f aqui no GitHub deliberadamente desfaz os dois ...
if (enc_err < 0) {
/*
* A separate 'decryption_failed' alert was introduced with TLS 1.0,
* SSL 3.0 only has 'bad_record_mac'. But unless a decryption
* failure is directly visible from the ciphertext anyway, we should
* not reveal which kind of error occurred -- this might become
* visible to an attacker (e.g. via a logfile)
*/
al = SSL_AD_BAD_RECORD_MAC;
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
goto f_err;
}
Então, você pode querer reordenar seu conjunto de criptografia:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
Este post no askubuntu sobre o POODLE vulnerabilidade tem uma excelente lista de recursos para inspeção e encanamento SSL.
O gerador de configuração do Mozilla é um excelente serviço público.
O comentário "recebendo este erro a cada quinto clique" é um pouco estranho. Você quer dizer cliques , ou toda quinta linha é uma requisição ruim nos logs? Tente iniciar o single-threaded do apache (o sinalizador -X) e ver se isso faz a mesma coisa ... ou talvez configurar SSLSessionTickets off .
Meu pensamento aqui é eliminar a coerência / consistência de threads / sessões / cache como fonte de problemas. Executar o single-threaded do apache (iniciando-o com o sinalizador -X) é uma maneira de realizar isso, outra maneira é definir MaxClients=1 (pelo menos com o modelo MPM). Os tickets de sessão têm sido uma fonte de problemas no passado com o TLSv1.2 e eles estão habilitados por padrão, este é o raciocínio por trás do SSLSessionTickets off (note que isso é parte da mensagem SSL "Server Hello", não um cookie de sessão ou similar ). O erro 'cada quinto clique' ainda me incomoda - não posso deixar de notar que a maioria dos navegadores irá enviar quatro solicitações de recursos em um único ...) e abrir uma nova conexão (um novo handshake SSL, etc ...) para o quinto ... sem uma captura de pacotes, é difícil dizer o que realmente está acontecendo.
Parece que você eliminou a negociação de criptografia como uma fonte de erro (é possível duplicar a condição de erro sob especificações de criptografia muito mais restritivas, a menos que eu esteja enganado). Eu ficaria curioso para saber se você pode acionar o erro renegociando SSL (apenas para pontapés, digamos): openssl s_client -connect server:443 e, em seguida, digite 'R', ver o que dizem os registros. Também ver se o cache de sessão está trabalhando com a opção -reconnect para s_client.
Algo deve ser diferente sobre os contextos de recebimento para as solicitações SSL, e parece ser a melhor maneira de descobrir isso (menos de um byte-by-byte) a inspeção do que está acontecendo com o fio, que pode ser difícil de anonimizar) é limitar severamente o tamanho do que está ouvindo (ou seja, o número de ouvintes).
Outras ferramentas de depuração que eu tentaria (supondo que a postagem de capturas de pacote esteja fora de questão ...)
- ssltap (em libnss3-tools no ubuntu)
- cipherscan
- sslscan
UPDATE
Dar uma olhada nisso por meio de ssltap parece muito com erro do OpenSSL # 3712 ressurgiu (renegociação de chave durante a leitura / gravação, basicamente). Procurando por uma solução alternativa decente que não mate o desempenho. Coisas divertidas!