Android API browser, WifiEnterpriseConfig (API level for Android 7 "Nougat" is 24)
178688: Enterprise Wi-Fi CA certificate disappears in config UI when you forget the network
53089: Android does not send intermediate certificate while using EAP-TLS for wifi connection
178687: Allow multiple CA certificates in an 802.1X profile (fixed in Nougat -> WifiEnterpriseConfig::setCaCertificates!)
82036: Self-signed certificates cause "network may be monitored by third party" warning (fixed in 6.0.1 April patchlevel)
.mobileconfig File Description
iOS Release Notes for all released versions
17775556: iOS Passpoint profiles show UUID instead of user-friendly PayloadDisplayName; differs from correct OS X behavior (private; owned by Stefan Winter)
20220334: UI for username/password in Wi-Fi profile import incorrectly capitalises the SSID name (private; owned by Stefan Winter)
28888950: Profile import does not notify+retry user of wrong import password of his client certificate
.onc File Description (version history)
388457: Feature Request: direct import from clicking in web browser, UI integration
XML Profile Schema Definition
EAP Certificate Requirements
PEAP Protocol Specification
D-BUS settings (current stable release)
1573720: Unencrypted private keys are insecure error reported even when key is encrypted
All bugs are listed here: https://01.org/jira/projects/CM/issues/
Will add a feature request for "allow to specify expected server name" later
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.
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 User-Name (outer ID): "heartbleed.test@<targetrealm>
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:
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.
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 email@example.com and we will get back with the results to the authorized federation admin on file with eduroam.org.
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.
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.
It has come to our attention that there are vulnerabilities in the
relatively new 1.0.1-series of OpenSSL (as detailed by http://heartbleed.com/) 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,