Forzare l'autenticazione EAP-TLS 1.2 con FreeRadius e OpenSSL

1

Funzionava con l'handshake basato su certificato DHS di TLS con un server FreeRADIUS e WPA_supplicant - entrambi con FIPS OpenSSL 1.0.1j.

Afer guardando il traffico di Wireshark, noto che il client invia un Client Hello usando TLS 1.0. Credo che i certificati ECC abbiano un problema con OpenSSL / TLS 1.0.

Ho testato s_client e s_server con gli stessi certificati usando TLS 1.2 ed era SUCCESSIVO.

Non riesco a capire come modificare la versione TLS da 1.0 - > TLS 1.2 sul messaggio hello del client. Forse, poiché TLS 1.0 non supporta i codici ECC, potrebbe esserci un problema? Tuttavia, DOVREBBE forzare un TLS 1.2 perché la nuova versione di SSL lo supporta e le cifre.

Inoltre, l'handshake ha esito negativo con un "Errore irreversibile SSLS3_GET_CLIENT_HELLO" durante il primo passaggio dell'handshake TLS 1.0.

Qualche idea in merito?

    
posta userJoe 31.10.2014 - 01:12
fonte

1 risposta

1

Al massimo una risposta parziale ma troppo per commenti ragionevoli.

ECDHE NON richiede TLS1.2, solo 1.0 come ho detto nel commento. L'ho usato spesso in openssl 1.0.0 che non implementa nemmeno 1.2, e comunque testare bene specificando 1.0 in openssl corrente o usando java non-bleeding (j7 può fare 1.1 e 1.2 ma default 1.0). In effetti, openssl supporta effettivamente ECDHE (e altre funzionalità ECC) su SSL3, che RFC non richiede, quindi funziona con openssl-to-openssl ma non necessariamente con altre implementazioni; ma non c'è una buona ragione per usarlo quando è disponibile TLS1.0 più robusto. Le uniche funzionalità di crittografia che richiedono TLS1.2 sono AEAD (in GCM openssl) e SHA2. Se le tue app richiedono ECDHE-ECDSA-AES128-SHA256 ma non ECDHE-ECDSA-AES128-SHA, che non funzionerà su 1.0. Quali codici sono offerti nel tuo ClientHello? Alcuni googling trovano il link che suggerisce almeno la possibilità di specificare l'elenco di cifrari a partire dal 2012, ma non l'ho fatto Vedi qualsiasi documento su if e su come un utente controlla questo.

Che mi ricorda: stai guardando la versione corretta in ClientHello? Esistono due versioni: livello record e handshake. OpenSSL utilizza la versione 0301 (TLS1.0) di "Record Layer" per ClientHello per offrire una gamma di protocolli, per garantire che un peer che implementa solo una versione precedente "negozierà" correttamente; è la versione in "Protocollo Handshake: Client Hello" che specifica la versione offerta. E ancora non hai detto quale sia la risposta in Wireshark: c'è un avviso e con quale codice, o qualcos'altro, o cosa?

Detto questo, potresti vuoi TLS1.2 per i suoi altri vantaggi o semplicemente per futureproofing. Tra i protocolli che openssl implementa, quelli che offre per un client o accetta per un server sono controllati dalle chiamate effettuate dal rispettivo codice dell'applicazione client o server. Il punto di partenza per un SSL_CTX sono "metodi" per un protocollo specifico come SSLv3_*method o TLSv1_2_*method , o il "generico" SSLv23_*method (un nome legacy che ora è fuorviante e potrebbe essere cambiato in una versione di openssl futura ) seguito da SSL_[CTX_]set_options con (tra gli altri) SSL_OP_NO_(protocol) bit.

Supponendo che per sopra il tuo ClientHello sia la versione record 0301 E la versione handshake 0301, che significa solo TLS1.0, potrebbe essere che wpa_supplicant sia stato codificato per fare specificamente TLSv1_*method . Questo avrebbe potuto avere senso dieci anni fa quando TLS1 (.0) era il migliore disponibile e c'erano problemi con SSLv2 che poteva essere attaccato e SSLv3 inaccettabile per l'uso di USgovt (anche se in realtà sicuro) così qualcuno avrebbe potuto ragionevolmente pensare "noi proteggere gli utenti di # # da un errore e fare qualcosa di non sicuro forzando TLS1 ". Se è così, il passare del tempo ha reso questo modo di pensare sbagliato.

    
risposta data 01.11.2014 - 09:41
fonte

Leggi altre domande sui tag