Does the Heartbleed bug affect WiFi networks secured by WPA2-EAP in TLS mode? Since it's using TLS to secure connections between the server and clients, is it possible to attack the server using the Heartbleed attack and read the memory, stealing the private SSL key from the server?

  • This will depend on the server implementation, at a minimum to be affected the server will need to use OpenSSL. But there are many other layers/technologies in Wifi networks so that is probably not the only consideration. Commented Apr 8, 2014 at 7:10
  • Fairly certain that the implementation uses a vulnerable version of OpenSSL. Commented Apr 8, 2014 at 15:05

1 Answer 1


There are two main ways in which SSL/TLS and EAP may mix: EAP-TLS and EAP-TTLS. Basically, EAP is a generic protocol for exchanging "messages", and the "authentication method" defines the message contents. In the case of the TLS-based EAP methods, the messages contain the various handshake messages from SSL/TLS. In EAP-TLS, the normal case is that the client uses a certificate, and the certificate-based authentication from TLS is then leveraged; with EAP-TTLS, client authentication is not performed during the handshake, but an additional authentication protocol (which may itself use EAP) is played within the tunnel.

In any case, the normal SSL/TLS handshake messages are sent and received and processed, including the "heartbeat" extension of ClientHello and ServerHello. If a given implementation of EAP-TLS or EAP-TTLS uses a vulnerable version of OpenSSL to process the SSL/TLS handshake, then yes, the so-called "heartbleed" attack should apply, subject to the usual (and mostly unknown) vagaries of such kinds of attacks (namely, the buffer overrun will reveal what lies at that place in RAM, which depends a lot on the operating system and overall applicative layer).

Notably, the vulnerability occurs in the processing for the very first handshake message (the ClientHello), thus nothing in the rest of the protocol (e.g. cipher suite choice) has any impact on it.

However, we may say that most WiFi access points are never updated, so this specific vulnerability is just one more at the end of the long (and growing) list of vulnerabilities which apply to most deployed access points. In that sense, there is no reason to panic (the situation is bad, but it already was, and it is not made significantly worse).

  • 1
    A couple additions: PEAP, which is hugely popular, also uses TLS as the outer tunnel, must like TTLS does (it can also optionally use TLS as the inner auth as well). Also, the vast majority of APs don't implement EAP locally; they just pass it through to a RADIUS server. So most sysadmins need to check if their RADIUS server is using a vulnerable version of OpenSSL for their EAP-TLS, EAP-TTLS, or PEAP support. FreeRADIUS DOES use OpenSSL for its TLS implementation for TLS-based EAP types, so when built with vulnerable versions of SSL, it IS vulnerable: freeradius.org/security.html
    – Spiff
    Commented Apr 11, 2014 at 3:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .