Ci sono due modi principali in cui SSL / TLS ed EAP possono mescolarsi: EAP-TLS e EAP-TTLS . Fondamentalmente, EAP è un protocollo generico per lo scambio di "messaggi" e il "metodo di autenticazione" definisce il contenuto del messaggio. Nel caso dei metodi EAP basati su TLS, i messaggi contengono i vari messaggi di handshake da SSL / TLS. In EAP-TLS, il caso normale è che il client utilizza un certificato e quindi l'autenticazione basata su certificato da TLS viene sfruttata; con EAP-TTLS, l'autenticazione del client non viene eseguita durante l'handshake, ma all'interno del tunnel viene riprodotto un protocollo di autenticazione aggiuntivo (che può utilizzare esso stesso EAP).
In ogni caso, i normali messaggi di handshake SSL / TLS vengono inviati, ricevuti ed elaborati, inclusa l'estensione "heartbeat" di ClientHello
e ServerHello
. Se una determinata implementazione di EAP-TLS o EAP-TTLS utilizza una versione vulnerabile di OpenSSL per elaborare l'handshake SSL / TLS, allora sì, si dovrebbe applicare il cosiddetto attacco "heartbleed", soggetto ai consueti (e soprattutto sconosciuti) capricci di tali tipi di attacchi (ovvero, il sovraccarico del buffer rivelerà cosa si trova in quel punto nella RAM, che dipende molto dal sistema operativo e dal livello applicativo generale).
In particolare, la vulnerabilità si verifica durante l'elaborazione del primo messaggio di handshake ( ClientHello
), quindi nulla nel resto del protocollo (ad esempio la scelta della suite di crittografia) ha alcun impatto su di esso.
Tuttavia , potremmo dire che la maggior parte dei punti di accesso WiFi non vengono mai aggiornati, quindi questa specifica vulnerabilità è solo un'altra alla fine del lungo (crescente) elenco di vulnerabilità che si applica alla maggior parte dei dispiegati punti di accesso. In questo senso, non c'è motivo di farsi prendere dal panico (la situazione è brutta, ma lo era già, e non è peggiorata significativamente).