Fail Decrypt Botan ha creato TLS usando Wireshark

Question

Fail Decrypt Botan ha creato TLS usando Wireshark

#1 da (1 voti)

1

Quando utilizzo Wireshark per decrittografare un esempio di Openssl (importando la chiave RSA privata del server) link funziona perfettamente.

E voglio fare la stessa cosa con gli strumenti Botan CLI (un'altra libreria di crittografia) usando cert e chiave autoallineati (RSA_2048bits). Ho configato il server usando i seguenti comandi

botan tls_server selfsignedCer.cer serverPrivate.pem --port=9999

client

botan tls_client localhost --port=9999

risultante

Alert:unrecognized name
Certificate validation status: Cannot establish trust
Handshake complete ,TLS v1.2 using RSA_WITH_AES_256_CBC_SHA256
Session ID : (long hex there)

Da quando la stretta di mano è stata completata, vado a cercare in wireshark, ma non c'è una sezione "Dati decrittografati SSL" come mostrato di seguito (quindi significa che wireshark non può decriptarlo):

Diseguitoèriportatoilmioesempiodisuccessoutilizzandol'esempioOpenssl,possovederelasezione'datiSSLdecrittografati'

wireharkèingradosolodidecodificareTLSimplementatodaopenssl?(mapensochel'implementazionenonabbiaalcuneffettosuTLS)Ohofattoqualcosadisbagliato?Filedicatturaoringaleechiavefornitidiseguito. link i primi 30 sono quelli con botan, quindi interrompo la comunicazione e avvio un altro campione openssl intorno agli anni '40, usando tutti lo stesso tasto

tls decryption

posta TTZ 15.08.2017 - 14:06

fonte

1 risposta

Leggi altre domande sui tag tls decryption

Domanda di certificazione di settore [duplicato] Authy chiede la password di ripristino senza un motivo. Questo comportamento normale?

score 1 · Answer 1

La prima connessione nella cattura, i frame 1-28, presumibilmente botan, utilizza l'estensione Encrypt-then-MAC di RFC 7366 ; cioè, il cliente lo offre / lo richiede e il server accetta. Basandosi sull'esame del log di debug SSL Wireshark a quanto pare non implementa questo, almeno fino alla 2.0 (non sono ancora su 2.2), poiché apparentemente tenta di decodificare l'intero messaggio incluso il MAC e quindi unpad che è completamente sbagliato per EtM. Decisamente non decodifica l'estensione nei messaggi Hello (lasciandola come "Unknown 22"), che mi aspetterei se venisse implementata la relativa funzionalità.

La seconda connessione, i frame 29-48, è apparentemente OpenSSL, che non implementa EtM e quindi non lo offre in ClientHello; il tuo server (botan) è apparentemente felice di negoziare una sessione senza di essa, anche se utilizzando una ciphersuite di AEAD (TLS_RSA_WITH_AES_256_GCM_SHA384 0x9C) che risolve la debolezza che EtM intendeva affrontare.

Intrigantemente il tuo client botanico offre anche l'estensione del ticket RFC 5077 , ma il server non ha effettivamente inviato un ticket per quella stretta di mano, mentre lo ha fatto per la stessa offerta da OpenSSL. Non vedo alcuna ragione ovvia per la differenza - che per essere chiari è permesso a scelta del server.

PS: potresti vedere se puoi far sì che il tuo cliente preferisca, o persino richiedere, ciphersuites AEAD, invece di offrire solo CBC AES (256) come in questa cattura. Se l'handshake seleziona una suite AEAD, EtM non ha alcun effetto sulla crittografia, quindi Wireshark dovrebbe gestirlo.