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?
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
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).