Ricevo un errore: SSL3_GET_RECORD: decodifica non riuscita o mac record errato

Ho il mio server (dove sto correndo Apache/2.4.27), e oggi mi sono reso conto che da (Brave e Google Chrome - computer diversi) ricevo dai miei siti Web questo errore;

This site can’t provide a secure connection

mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

E la cosa strana è che ricevo questo errore ogni cinque clic sul mio sito Web.

Dal mio file conf:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mywebsite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
SSLCompression off

da options-ssl-apache.conf;

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder     on
SSLCompression          off

Ho controllato il file di registro dal sito Web ma niente, anche qui nulla; /var/log/apache2/error.log

Sto cercando di capire cosa sta causando questo errore, qualche idea su dove posso trovare maggiori informazioni o anche meglio, come risolvere questo problema?

MODIFICARE:

Se provo openssl s_client -connect mywebsite.com:443, restituirà:

Sto usando: OpenSSL 1.1.0f

CONNECTED(00000003)

...

3073276480:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:469:

UN ALTRO EDIT:

Come suggerito da @quadruplebucky ho cambiato le opzioni-ssl-apache.conf in:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite           HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder     on
SSLCompression          off

#SSLSessionTickets       off

Ho anche provato ad aggiungere SSLProtocol all -SSLv2 -SSLv3nel mio file conf virtualhost, e nello stesso tempo ho cambiato un paio di cose qui;/etc/apache2/mods-available/ssl.conf

#SSLCipherSuite HIGH:!aNULL
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

SSLHonorCipherOrder on

#   The protocols to enable.
#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
#   SSL v2  is no longer supported
SSLProtocol all -SSLv2 -SSLv3

MODIFICARE:

Dopo aver modificato LogLevel in Infoesso restituisce:

[Sat Jul 08 13:34:53.374307 2017] [ssl:info] [pid 8710] [client] AH02008: SSL library error 1 in handshake (server mywebsite:443)
[Sat Jul 08 13:34:53.374717 2017] [ssl:info] [pid 8710] SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
[Sat Jul 08 13:34:53.374750 2017] [ssl:info] [pid 8710] [client] AH01998: Connection closed to child 1 with abortive shutdown (server mywebsite:443)

MODIFICARE:

Se corro con l'opzione -crlf, in questo modo:

openssl s_client -crlf -connect mywebsite:443

Non ricevo alcun errore?

Un'altra cosa se cambio LogLevel in debug, prima di quell'errore ottengo questo:

[Tue Jul 11 23:00:38.641568 2017] [core:debug] [pid 26561] protocol.c(1273): [client 188.64.25.162:23165] AH00566: request failed: malformed request line
[Tue Jul 11 23:00:38.641634 2017] [headers:debug] [pid 26561] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()

Quindi dopo questo accadrà lo stesso errore:

SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message

openssl version
OpenSSL 1.1.0f  25 May 2017

Non puoi dire da quell'errore se il tuo server sta negoziando SSLv3 o TLSv1 (potresti dare un'occhiata a questa domanda su Unix e Linux e assicurarti che sia disabilitato ovunque in apache ...) --- 1.1.0f il codice sorgente qui su GitHub sfuoca deliberatamente i due ...

   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;
}

Quindi potresti voler riordinare la tua suite di cifratura:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

Questo post su askubuntu sulla vulnerabilità di POODLE ha un eccellente elenco di risorse per l'ispezione e l'impianto idraulico SSL.

Il generatore di configurazione di Mozilla è un servizio pubblico eccellente .

Il commento "ottenere questo errore ogni quinto clic" è un po 'strano. Vuoi dire clic o ogni quinta riga è una cattiva richiesta nei registri? Prova ad avviare apache a thread singolo (il flag -X) e vedi se fa la stessa cosa ... o forse l'impostazione SSLSessionTickets off.

Il mio pensiero qui è di eliminare il threading e la coerenza / coerenza sessione / cache come fonte di problemi. Eseguire apache a thread singolo (avviandolo con il flag -X) è un modo per farlo, un altro modo è quello di impostare MaxClients=1(almeno con il modello MPM). I ticket di sessione sono stati in passato fonte di problemi con TLSv1.2 e sono abilitati per impostazione predefinita, questo è il ragionamento alla base SSLSessionTickets off(si noti che fa parte del messaggio SSL "Server Hello", non un cookie di sessione o simile). L'errore "ogni quinto clic" mi dà ancora fastidio: non posso fare a meno di notare che la maggior parte dei browser eseguirà il pipeline di quattro richieste di risorse in una sola ...) e aprirà una nuova connessione (una nuova stretta di mano ssl, ecc ...) per il quinto ... senza un'acquisizione di pacchetti è difficile dire cosa stia realmente accadendo.

Sembrerebbe che tu abbia eliminato la negoziazione di cifratura come fonte di errore (puoi duplicare la condizione di errore con specifiche di cifratura molto più restrittive, a meno che non mi sbagli). Sarei curioso di sapere se è possibile attivare l'errore rinegoziando SSL (solo per calci, diciamo): openssl s_client -connect server:443e quindi digitare 'R', vedere cosa dicono i registri. Controlla
anche se la memorizzazione nella cache delle sessioni funziona con l' -reconnectopzione s_client.
Qualcosa deve essere diverso nei contesti di ricezione per le richieste SSL, e sembra il modo migliore per capirlo (a parte un'ispezione byte per byte di ciò che sta passando sul filo, che potrebbe essere difficile da anonimizzare) è severamente limitare le dimensioni di ciò che è in ascolto (ovvero il numero di ascoltatori).

Altri strumenti di debug che proverei (supponendo che postare acquisizioni di pacchetti sia fuori discussione ...)
- ssltap (in libnss3-toolssu Ubuntu)
- cipherscan
- sslscan

AGGIORNAMENTO
Frugando a questo tramite ssltap sembra molto simile alla ricomparsa del bug # 3712 di OpenSSL (in pratica la rinegoziazione della chiave durante la lettura / scrittura). Alla ricerca di una soluzione decente che non uccida le prestazioni. Cose divertenti!

L'ho già visto prima, in effetti era già successo prima.

La risposta nel mio caso è stata estremamente sottile.

L'adattatore di rete ha abilitato l'offload del segmento TCP, che a causa di un bug di qualche forma stava rovinando (o troncando, non ricordo) gli ultimi pochi byte di alcuni messaggi, causando successivamente il fallimento del MAC sui record SSL.

Era una macchina virtuale su VMWare.

Vorrei provare a disabilitare TSO / GSO / GRO nel tuo ambiente e vedere se il problema scompare.

ethtool -K eth0 tso off gro off gso off ufo off

C'è qualche stranezza con OpenSSL e multithreading. Quale MPM usi? Se questo è legato al multithreading, "prefork" dovrebbe essere sicuro mentre "worker" ed "event" potrebbero essere interessati.

Se il tuo profilo di carico lo consente, puoi provare a passare a Prefork e vedere se il problema persiste.

Innanzitutto assicurati che Chrome sia aggiornato. Le versioni precedenti danno problemi con determinate cifre. Ho avuto questo problema con il cromo me stesso con siti comuni come Amazon, ecc.

Secondo, il consiglio di proibire i protocolli nella "lista di cifratura" che hai seguito è una pessima idea perché non proibirà i protocolli, proibirà la maggior parte delle cifrature, comprese quelle che funzionano "da" SSLv3 (ma non significa che stai abilitando SSL3 se consenti le cifre SSLv3), utilizza un elenco più generioc fornito dal generatore di configurazione SSL Mozilla per la compatibilità (nota che SSLv2 non esiste più o è supportato in httpd o openssl, quindi non c'è motivo di vietarlo esplicitamente più) e forse la tua combinazione precedente era troppo rigida , prova questo:

SSLProtocol             all -SSLv3
SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Se i problemi persistono, abilita il debug per SSL e vedi cosa ha da dire httpd (invia solo 1 tentativo o due e disabilita questa registrazione, è troppo rumoroso):

LogLevel ssl:trace3

Sidenotes: puoi anche andare avanti e rimuovere SSLCertificateChainFile poiché quella direttiva è obsoleta in 2.4. È possibile aggiungere la catena SSLCertificateFile e ordinare tutti i certificati da foglia a radice o persino modificare SSLCertificateChainFile in SSLCACertificateFile (sebbene questo sia utilizzato principalmente per l'autenticazione SSL).

Dovresti anche aggiungere (se non l'hai ancora fatto) per aggiungere:

SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)

Modifica: a seguito della nostra conversazione, ricorrere al controllo dell'installazione di openssl e / o se è davvero la stessa versione utilizzata dal tuo httpd:

Emetti questo comando e vediamo cosa dice: openssl ciphers -v 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'

Inoltre per assicurarti che la versione di openssl sia quella corretta esegui questo:

openssl version