FeM

A WiFi client is usually connected to an AccessPoint for WPA-protected network access. When the AccessPoint becomes unreachable for example as the client moved, the client needs to switch over to an other AccessPoint providing the same extended service set (ESSID). This is called roaming.

Roaming involves the following steps:

1. Scanning for an other reachable AccessPoint (Probe)
   
2. Disconnect from the old AP
   
3. Changing the WiFi-channel
   
4. Authentication and Association
   
5. WPA-EAP-Handshake (only for 802.1X)
   
6. 4-way WPA handshake
   
7. Connection is ready again
   

These steps need time and the client is disconnected until he completed them, but there are some options available to speed things up:

Some time ago, we enabled IPv6 on our internal database webserver. The PHP application running bound its sessions to the client IP address. The local clients configured its IPv6 address using IPv6 auto-configuration with privacy-extensions enabled. This lead to IPv6 clients sometimes changing its IPv6 address used with the connection to the web server, so they could no longer use their session and thus were logged off.

The solution was to install SSL client certificates, so clients could reliably be identified even across different IPv6 privacy extension addresses. These client certificates were automatically generated and signed by a local CA using HTML <keygen> and PHPseclib and only served to identify the browser instance.

Now these client certificates started to expire.

As our Firefox users had not cleared the "Remember this decision" flag when choosing their single client certificate to connect with, Firefox 41 continued to connect using an expired certificate. The "auto select client certificate" in Firefox does not do any better, thought. When the server rejects an SSL client certificate with ssl_error_expired_cert_alert, Firefox shows an error message to the user but does not offer him to reselect an other client certificate. So users started to puzzle about how to fix this error. Even installing a renewed client certificate (same subject, issuer and public key) ahead of expiration into Firefox 41 does not help, as that does not remove the old certificate which is still chosen for connecting with.

So the only place to fix this is the server. On server side, the list of accepting CAs could be changed. Though Firefox code looks like in "auto select client certificate" mode this would work, the "use remembered client certificate" lacks any client certificate issuer check. So this does not look promising (see ClientAuthDataRunnable::RunOnTargetThread), though it has not been tested. Next, trying to configure apache 2.4 (Debian Jessie) to accept expired client certificates (while still requesting - at least optionally - one) turns out to be impossibly. There just is no such option. Thought, patching and recompiling apache2 was to be avoided as the server should still be able to install Debian security updates without much manual intervention.

After digging through the source of apache 2.4 mod_ssl, it appears that it is making heavy use of OpenSSL certificate validation routines to check client certificates - including the expiration checks (in contrast to https proxy server certificate validation, where expiration time is checked in mod_ssl itself). Specifically, it uses ssl_callback_SSLVerify with SSL_set_verify to ignore some verification errors already.

LD_PRELOAD is a mechanism to load a shared library early during linking (starting) of an applicaton (like apache2). The linker will the prefer the functions provided by LD_PRELOAD libraries over those libraries indicated by the application itself - so it can be used to hook into library function calls. By writing a specifically crafted LD_PRELOAD library, SSL_set_verify can be hooked and the callback replaced. The new callback will filter out any X509_V_ERR_CERT_HAS_EXPIRED error before passing back control to the original ssl_callback_SSLVerify callback.

LD_PRELOAD can the be configured in /etc/apache2/envvars (used by apache2ctl and thus Debian init scripts) to load the new library.


# mysslverify.c
// gcc -Wall -D_GNU_SOURCE -fPIC -DPIC -shared -ldl -o mysslverify.so mysslverify.c
// use with LD_PRELOAD=/.../mysslverify.so

#include <openssl/ssl.h>
#include <dlfcn.h>

void (*orig_SSL_CTX_set_verify)(SSL_CTX *ctx, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;
void (*orig_SSL_set_verify)(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;
int (*orig_verify_callback)(int, X509_STORE_CTX *) = NULL;

int verify_callback(int ok, X509_STORE_CTX *ctx) {
  if (!ok && X509_STORE_CTX_get_error(ctx) == X509_V_ERR_CERT_HAS_EXPIRED) {
    X509_STORE_CTX_set_error(ctx, X509_V_OK);
    ok = !ok;
  }
  return orig_verify_callback(ok, ctx);
}

void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*cb)(int, X509_STORE_CTX *)) {
  if (orig_verify_callback == NULL) orig_verify_callback = cb;
  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;
  if (!orig_SSL_CTX_set_verify) orig_SSL_CTX_set_verify = dlsym(RTLD_NEXT, "SSL_CTX_set_verify");
  orig_SSL_CTX_set_verify(ctx, mode, cb);
}

void SSL_set_verify(SSL *s, int mode, int (*cb)(int, X509_STORE_CTX *)) {
  if (orig_verify_callback == NULL) orig_verify_callback = cb;
  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;
  if (!orig_SSL_set_verify) orig_SSL_set_verify = dlsym(RTLD_NEXT, "SSL_set_verify");
  orig_SSL_set_verify(s, mode, cb);
}


Nachdem ein Teil der AccessPoints nun geliefert ist, schreitet der Ausbau voran.

Aktuell ist Haus P vollständig, im Haus I sind noch 2, im Haus H noch 4 und im Haus K noch 23 AccessPoints zu installieren; diese sind auch als Nächstes für den Ausbau eingeplant.

Voraussetzung für den Ausbau mit FeM-WLAN sind freie LAN-Kabel und die Unterstützung von Strom-über-LAN (POE). Im Haus A, C, D, E, Q, CJD ist POE verfügbar, allerdings fehlen noch Kabel. Im Haus B, L und N sind Kabel verfügbar, aber noch kein POE - was sich jedoch nachrüsten ließe.

Daneben gibt es an ausgewählten Standorten (beispw. in den Clubs) bereits jetzt FeM-WLAN zu empfangen.

Wenn du also Interesse hast, den Ausbau beispw. in deinem Block zu beschleunigen, dann komm doch einfach mal vorbei.

Donnerstags in ungeraden Wochen um 20:30 Uhr im Haus L, Eingang 6d, im Keller.

Wie ermittelt man eigentlich aus dem Browser heraus, wie schnell gerade das WLAN ist? Diese Frage stellte sich uns, bei dem Versuch, über eine Webseite den Nutzern die Möglichkeit einzuräumen, uns Feedback zur FeM-WLAN Qualität und -Empfang zu geben.

Der WLAN-Ausbau auf dem Campus schreitet voran. Nach und nach werden die AccessPoints geliefert, die Software installiert und die Geräte verbaut.

Dafür sind wir auf eure Mithilfe angewiesen, da die AccessPoints in den Fluren der WGs installiert werden sollen! Wir werden euch daher in den kommenden Zeit bei Bedarf persönlich ansprechen oder anschreiben, sofern in eurer WG ein AccessPoint installiert werden soll.

Derzeit ist das Haus I an der Reihe. Außerdem gibt es in den Studentenclubs, im Keller des Haus A, im Interclub, im Haus P, im FeM-Office sowie bei einigen Administratoren bereits FeM-WLAN.

Die Authorisierung von Anfragen einloggter Nutzer erfolgt in Webanwendungen sehr oft mit Hilfe von Sitzungscookies.

Kann ein Angreifer ein solches Ausspionieren oder erraten, kann er oft die gesamte Sitzung des eingeloggten Nutzers übernehmen und mit seinen Rechten die Webanwendung / Webseite nutzen.

Derartige Angriffe sind in der Vergangenheiten manigfaltig dokumentiert worden. Ein erster Schritt zum Schutz der Sitzungscookies ist die Nutzung von HTTPS.

Die Nutzung von HTTPS reicht jedoch nicht in allen Fällen aus, wie die BEAST, CRIME und BREACH Angriffe zeigen.

Angenommen, man möchte einen LAN-Anschluss bereit stellen, an welchem sich die Nutzer zunächst mit 802.1X authentifizieren müssen, und danach das passende VLAN bereit gestellt bekommen.
Bei der FeM bespielsweise an den APs für Veranstaltungsstreaming.

Die dafür notwendigen Änderungen am Linux-Kernel, an Bibliotheken und am hostapd finden sich nun auf http://git.fem.tu-ilmenau.de

• libnl: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/libs/libnl/patches/0001-macvlan-add-support-for-source-mode.patch;h=4572e10f54bf809bdd3659bcda220d81dfbff63e;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• iproute2: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/utils/iproute2/patches/999-iproute2-macvlan-add-source-mode.patch;h=0abcb39925efa12485fe0df2b5535eebbf6ab89c;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• linux kernel: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=target/linux/generic/patches-3.10/998-add-macvlan-source-mode.diff;h=3862d393f19fd1b5e342024b8f15d7ca4bf9c0d2;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• hostapd: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/services/hostapd/patches/905-add-wireng-vlan-driver.diff;h=d34519710e069eff9e86f3a4abda63f12217356f;hb=2ba3eff2d9ed3e573055bf8b1835b0da9265e7d1
  

Einrichtung im hostapd:

interface=eth2
driver=wired-ng

ieee8021x=1

# RADIUS
auth_server_addr=1.2.3.4
auth_server_shared_secret=MySharedPasswd

# VLAN
dynamic_vlan=2
vlan_tagged_interface=vpnuplink
vlan_bridge=brvlan


Die Deauthentifizierung erfolgt bei timeout oder wenn der Port offline geht.