Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


D-BUS settings (current stable release)

nmcli Documentation (current stable release)

Known Bugs

1573720: Unencrypted private keys are insecure error reported even when key is encrypted

Feature Request: Support Passpoint in nmcli

Linux: ConnMan

Configuration Documentation


All bugs are listed here:

Password: nopass

The attack itself will attempt to extract only 10 Bytes of server RAM on the EAP server. This is too few to find out of what nature those bytes are, and they are also immediately discarded. Following questions from operators: no, it is not possible to do a simple version check of the OpenSSL software: firstly, the TLS handshake on the wire does not yield enough information to enable a sufficiently fine-grained fingerprinting of the server-side library; secondly, even a version indicator would not be reliable as most distributions back-ported the fix to an older OpenSSL version, keeping the lower version identifier. The only way to find out if a server is vulnerable is unfortunately: try, and see if you succeed.

Note 1: seeing these inner usernames does not per se mean a server is vulnerable - it could have silently ignored the bogus request and carried on; or it simply does not support TLS heartbeats at all. The only truly positive indication will be an email from eduroam OT that our testing code actually received the payload.

Note 2: Only the presence of the Operator-Name attribute guarantees that the test was run by a member of eduroam infrastructure; a "real" attacker could mount the attack with the same username from any eduroam hotspot - but cannot influence the Operator-Name attribute, as this is set infrastructure-side.

The tests for today will commence shortly before noon.

April 10, 16:50 CEST


Following up on the heartbleed vulnerability in OpenSSL: it is confirmed that EAP-authentication in RADIUS servers is vulnerable to the attack. It is therefore extremely important to upgrade OpenSSL and restart RADIUS services as soon as possible.

The attack is feasible from any public eduroam hotspot, not just your RADIUS peers.

While there is no exploit publicly available, the diagnostics tools of the operational team are updated to test for heartbleed.

As announced to the eduroam steering-group in Europe and published on the TERENA wiki, we're performing proactive scans of European eduroam realms for the vulnerability (as part of section 2.2.1 in the policy service definition) and will continue to do so.

Federation-level admins in Europe will receive notice from the eduroam OT with a list of vulnerable realms. If you're unsure about the completeness of our data, feel free to send a complete list of realms (one per line) to the OT.

While the tools are not publicly available for security reasons, we're providing the service of scanning a realm list for global federation admins on their request. You can send a list of realms to be scanned to and we will get back with the results to the authorized federation admin on file with

WARNING: Expect that mid-April, the threat is more severe, and remediation is extremely difficult. Because the eduroam authentication takes place before getting access to a network, it's not possible to consult a certificate revocation list (CRL) or query the certificate status online (with OCSP). As exploits on HTTPS already exist and can probably be ported to TLS over EAP, we have only limited time to react to this threat.

eduroam OT

April 9, 18:00 CEST

FYI, the eduroam OT is performing proactive testing of eduroam realms for the heartbleed vulnerability. You might notice these in your RADIUS logs.

While it's important to upgrade servers ASAP, we can raise awareness for affected institutions via the federation admins.

April 8, 16:00 CEST


It has come to our attention that there are vulnerabilities in the
relatively new 1.0.1-series of OpenSSL (as detailed by affecting TLS enabled customer services via a heartbeat extension.

While there are no indications that this affects TLS-based
EAP-mechanisms or RADIUS/TLS (aka RadSec) at this time, the operational
team has made the decision to upgrade openssl to versions implementing a
fix for CVE-2014-0160

We advise roaming operators to bring this CVE-2014-0160 to the attention
of eduroam administrators, so they can investigate their systems and
upgrade when systems are running affected versions.

Progress and updates on this note will be published on the TERENA wiki,

eduroam OTWill add a feature request for "allow to specify expected server name" later


April 15, 08:30 CEST

The rate of eduroam RADIUS server patching has been swift and represents a significant reduction in vulnerability to the Heartbleed threat. As part of responsible disclosure, we will soon release the information about the exact nature of the exploit and the specific properties of exploiting Heartbleed over EAP to accredited Computer Security Incident Response Teams (CSIRTs). We want to give the remaining, unpatched, eduroam Identity Providers a little extra time to get their servers in order before doing that release, but the window of opportunity is definitely closing. Those of you who are known vulnerable (by having received notice from your eduroam National Roaming Operator) or otherwise suspect that your server is still using a vulnerable version of OpenSSL: please update your software and restart the services that use OpenSSL at your very earliest convenience. We are going to release the information to CSIRTs around 1600 CEST on Wednesday, 16 April 2014.

April 11, 08:30 CEST

We will be conducting those proactive scans once per day. We will notify federation operators of all sites which are still vulnerable. We will assess the decline of the vulnerability rate over the coming week.

Administrators can identify the tests with the following information:


RADIUS Operator-Name = "1eduroam.ot.heartbleed.test".

The testing attack will be mounted during the TLS tunnel setup, before actual user-side credentials are transmitted. If the server does not terminate the TLS session on receipt of the bogus request, we will send a phantasy username and password inside the tunnel. It will be: