Tale messaggio viene inviato da una parte (ad esempio il server) all'altra parte (ad esempio il client) per indicare che ha avuto un problema con gli elementi crittografici inviati da quella parte. Nominalmente , questo si verifica nelle seguenti condizioni:
bad_record_mac This alert is returned if a record is received with an incorrect MAC. This alert also MUST be returned if an alert is sent because a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
Nell'handshake SSL / TLS, il primo messaggio crittografato inviato da una qualsiasi parte è il messaggio Finished handshake che precede i dati dell'applicazione. Quando il crypto è andato storto, questo verrà visualizzato a quel punto, con l'avviso bad_record_mac .
Si deve notare che quando lo scambio di chiavi asimmetriche fallisce, ad es. se il server ha tentato di decifrare il "pre-master secret" crittografato da RSA inviato dal client ma non ha trovato un messaggio RSA correttamente crittografato, le implementazioni dei server più recenti continueranno con un segreto pre-master casuale. Questa è una difesa contro gli attacchi Bleichenbacher , che cercano di ottenere informazioni extra sul server privato chiave cercando di indovinare se la decrittografia non è riuscita allo stadio RSA o successivo. Per contrastare questi attacchi, i server "ritardano" gli errori fino ai messaggi Finished , e proveranno veramente non a spiegare l'esatta causa dell'errore. Quindi, mentre bad_record_mac è nominalmente un problema con il livello di controllo dell'integrità, tali errori tenderanno ad apparire per qualsiasi problema relativo alla crittografia.
Una causa plausibile sarebbe la seguente: il client utilizza una presunta chiave pubblica del server che non corrisponde alla reale chiave privata del server. Normalmente, il client estrarrà la chiave pubblica del server dal certificato del server, che il server invia al client durante l'handshake. Il server possiede anche una chiave privata, che è collegata matematicamente alla chiave pubblica. Se il server è configurato per utilizzare il file sbagliato, è possibile ottenere i sintomi che si osservano.
Ti suggerisco di utilizzare uno strumento di monitoraggio della rete (come Wireshark ) per osservare i messaggi di handshake: dovresti vedere Certificate messaggio dal server, contenente la catena di certificati del server; per il primo certificato di quella catena, è possibile estrarre la chiave pubblica del server, che verrà utilizzata dal client. Sul server, prova a stampare i dettagli della chiave privata del server (se questo è facile o meno dipende dal software coinvolto e dalla memorizzazione effettiva della chiave), per vedere se corrispondono.
Altre possibili cause implicano implementazioni bug di alcuni algoritmi crittografici (sul client e / o sul server). Individuare questi errori potrebbe essere difficile.
Per ottenere più dettagli di debug, puoi anche provare a connetterti al server con lo strumento da riga di comando openssl :
openssl s_client -connect theservername:443 -msg -debug
Prova anche a giocare con alcune delle opzioni per selezionare la versione del protocollo ( -ssl2 , -ssl3 , -tls1 ...) e le suite di crittografia supportate ( -ciphers ). In definitiva, potresti persino ricompilare la tua versione di OpenSSL con il codice di debug personalizzato inserito (per stampare i valori intermedi e così via). OpenSSL è opensource, quindi è tecnicamente fattibile, se hai qualche conoscenza di programmazione C.
Una certa padronanza dei dettagli del protocollo SSL aiuterà. Vedi questa risposta come punto di partenza.
Leggi altre domande sui tag encryption openssl tls