WirelessMoves

There is two extremes in the popular cloud space when it comes to ease of updating: WordPress and Owncloud…

On one side is WordPress which has about the most simple and most reliable update process that is fully automatic and doesn't even have to be triggered by the administrator for small upgrades and a simple click when going from one major release to the next. It hasn't failed me once in the past five years. And then there is Owncloud, which is the exact opposite.

Over the past year it failed me during each and every update with obscure error messages even for small security upgrades, broken installations and last resort actions such as deleting app directories and simply ignoring some warnings and to move ahead despite of them. If you think it can't be that bad, here's my account of one such update session last year. In the meantime I've become so frustrated and cautious as to clone my live Owncloud system and first try the update on a copy I can throw away. Only once I've found out how to run the upgrade process, which unfortunately changes every now and then as well, which things break and how to fix them do I run an upgrade on my production system. But perhaps there is some hope in sight?

My last upgrade a couple of days ago worked flawlessly, apart from the fact that the update process has changed again and it's now mandatory to finalize the upgrade process from a console. But at least it didn't fail. I was about to troll about the topic again but this morning I saw a blog post over at the Owncloud blog in which they finally admit in public that their upgrade process leaves a lot to be desired and that they have started to implement a lot of things to make it more robust and easier to understand. If you have trouble updating Owncloud as well I recommend to read the post, it might make you feel a bit better and give you some hope for the next update process.

And to the Owncloud developers I would recommend to go a bit beyond what they have envisaged so far: Blinking lights, more robustness and more information of what is going on during an update is a nice thing and will certainly improve the situation. In the end, however, I want an update process that is just like WordPress'es: You wake up in the morning and have an email in your inbox from your WordPress installation that tells you that it has just updated itself, that all is well and that you don't have to do anything anymore! That's how it should be!

Today, most Wi-Fi hotspots at home use the standard WPA/WPA2 authentication and encryption mechanism that uses a shared password between the Wi-Fi hotspot and clients. The downside of this approach is that all users have to share the same password which enables an attacker who is in range of the network and in possession of the password to decode encrypted packets if he has observed the initial EAPOL authentication and ciphering dialog of another client. Another downside is that the password needs to be stored in all access points of a Wi-Fi network. All these things are clearly not acceptable in company environments or during public events that want to offer air interface security. For such environments, the Wi-Fi alliance has specified the WPA-Professional authentication approach that can use various authentication methods with certificates and individual passwords for each user. Let's have a closer look at one option of which I was recently able to take a Wireshark trace:

To address the need of companies for a centralized user management, WPA/WPA2-Professional manages certificates and passwords from a central authentication server, often referred to as a RADIUS server. In practice it's not straight forward to discuss such setups because they are mostly used by companies and hence can't be discussed in public. Fortunately I've now found one network that uses WPA2-Professional with a certificate and passwords that can be discussed in public: The Wi-Fi network that was used during 32C3.

As they've described on their Wiki, a server side certificate was used to authenticate the network towards the user via TTLS. To authenticate clients, a username/password of choice could be used in the network. As the conference network administrators were not interested to authenticate users, any username and password combination was accepted. In practice users could remain anonymous this way while at the same time an individual secret was used to generate cipher keys, i.e. packets can't be deciphered by an attacker even if the authentication packets were captured.

The screenshot of the Wireshark trace on the left (here's the pcap in case you want to have a more detailed look) shows how the TTLS/Certificate authentication works in practice. After associating with the network, the Wi-Fi access point asks for a username, which can be anonymous and then tells the user that it wants to proceed with a TTLS-EAP authentication procedure. The client device then answers with a 'Client Hello' packet that contains all cipher suites it supports. The network then selects a cipher suite and sends it's signed certificate to authenticate itself which contains it's public key.

In company environments, the certificate used in Wi-Fi networks is usually signed by a private certificate authority. To enable the device to validate the signed certificate that was sent, the public key of the certificate authority that has signed the delivered certificate has to be stored in the device before it connects to the network for the first time.

In case of the 32C3 network a public certification authority was used to sign the certificate delivered to the device. As anyone can get a signature for a certificate from a public certification authority if he is the owner of the domain specified in the certificate an additional client side configuration is required to ensure that only signed certificates with the correct domain name of the Wi-Fi network are accepted. Unfortunately, Ubuntu's graphical network configuration tool doesn't have a field to configure this extra information as shown in the second screenshot.

Fortunately it's possible to modify Ubuntu's configuration file for the network after it has been created in '/etc/NetworkManager/system-connections' by adding the 'altsubject' line in the 802.1x section with the domain name used by the Wi-Fi network's certificate.

[802-1x]
eap=ttls;
identity=x
ca-cert=/etc/ssl/certs/StartCom_Certification_Authority.pem
altsubject-matches=DNS:radius.c3noc.net;
phase2-auth=pap
password-flags=1

Putting in a wrong value in this line makes the connection establishment fail so I could verify that the overall authentication process is secure.

Once the client device has accepted the server certificate (packet 14 in the trace) an encrypted handshake message is exchanged that is client specific. For this dialog, the client uses the public key that was part of the certificate to encrypt the message. Decoding the packets on the network side is only possible with the private key. As the private key is never sent over the air an attacker can't use a copy of the certificate for a rogue access point.

Afterward the standard 4 step EAPOL Wi-Fi messaging is used to activate link level wireless encryption, based on an individual secret exchanged during the TTLS process. Packet 22 shows the first encrypted packet exchanged between the access point and the client device, a DHCP message to get an IP address. As the trace was done on the client device the decoded version of the packet is shown. Once the IP address has been received the connection is fully established and user data packets can be exchanged.

I travel a lot in Europe and I call lots of people in different countries not only when I'm in my home country but also while traveling. In other words, without a good tariff for international calling and data use, it's no fun. A new mobile EU-Flat tariff introduced by my mobile network operator last year has, for the first time, enabled me to use my monthly mobile data volume anywhere in the EU and to call back home without per minute fees for a modest additional monthly fee of 5 euros. This has helped a lot and apart from one exception I didn't have to use local SIM cards anymore.

One thing that the offer didn't include, however, was making calls from my home country or while traveling in the EU to fixed and mobile phones of other EU countries. At prices of well over a euro a minute this had remained prohibitively expensive. But things have moved on since then and my fixed and mobile network operator of choice has made me a bundle offer to extend my current EU-flat to also include voice calls from anywhere in the EU to anywhere in the EU to both fixed and mobile devices. Yes, that's what I've been waiting for for some many years. The 'everything inclusive anywhere EU-Flat' now costs an extra 10 euros on top of my normal fixed line and mobile contracts instead of the 5 euros I paid before but with my usage pattern that's a deal I was more than willing to take.

No longer waiting to make some calls only until I'm back home or in the office or by using complicated dial-in numbers, no nightmares about costs spiraling out of control because that conference call only offers an international dial-in number, it's definitely my tariff add-on of the year!

P.S.: No, this is not an advertisement for a particular fixed and mobile network operator which is why I haven't named the company in the first place. This blog entry is about documenting a very positive change in the telecommunication market and to encourage other network operators to follow.

Like ever year at the end of the Congress one of the last sessions is the Infrastructure Review. Here, the people who built the congress data network, the DECT network, the GSM network and the Seidenstraße talk about the technology they used this year. It always interesting to hear how much data, calls and packets have been shuffled through the networks and how that compares to last year, how many people used the network, how many wireless devices were used, which networking equipment was used and so on and so on. For anyone interested in networks this talk is a must see and fun to watch not only because of the interesting numbers but also because the presentation contains a lot of hacker fun and sarcasm. This year was certainly no exception. The cut video of the session is not yet on the congress streaming server but the raw-uncut version can be found here in the meantime.

One important message I also want to repeat here: So far, the GSM network of the Congress used the 1800 MHz DECT/GSM guard band. This won't be possible in 2016 anymore as that part of the spectrum has been auctioned in 2015 so one of the network operators in Germany has to be kind enough to loan the Congress GSM network organizers a couple of ARFCNs for the week. So if you are working in spectrum planning at a network operator and think you can spare a couple of channels for a week at the Congress location please think about it and get in touch with the organizers. If you don't know how to do that, let me know, I'll be glad to help!

One feature some proponents are pushing for future 5G networks are ultra short reaction times for ultra critical communication, for example between cars. What I failed to understand so far in this discussion was why for car to car communication a fixed network infrastructure and a backhaul network was necessary!? After all, car to car communication mainly makes sense for cars that are in close proximity to exchange information about potential dangers such as emergency braking, breakdowns and their current status such speed, direction etc., etc. It seems that my skepticism was not unfounded because unknown to me and perhaps also to the 1 ms 5G proponents, decentralized solutions not requiring a network infrastructure already exist.

While Europe and the US seem to be on different paths (once again) on higher layers of the protocol stack, both approaches are based on the IEEE 802.11p extension of the Wi-Fi standard. In this "Wi-Fi" flavor, there are no central access points, no fixed equipment and no backhaul of any kind. On top of this physical layer, event and context information is exchanged. An interesting challenge is how to ensure that messages are sent from "real" vehicles and not from rouge devices that want to disrupt traffic, e.g. by sending messages about emergency breaking etc. while at the same time ensuring privacy, i.e. to send messages anonymously to prevent tracking.

The concept that car companies have come up with is a public key infrastructure and cars equipped with a master certificate by car manufacturer. Based on the master certificate, temporary certificates are signed by a certificate authority which are then included in 802.11p messages sent by cars. Vehicles receiving messages can then validate the message by checking the temporary certificate which does not contain the car's identity and which are changed frequently. Rouge devices that do not have a master certificate can't get temporary certificates, at least in theory, and therefore can't include proper temporary certificates in their messages. That makes me wonder of course how hard it might be in the future to get a valid certificate by extracting it from an on-board computer of a vehicle. SIM cards of mobile devices have provided pretty good security over the past decades so there is at least some hope that the master certificates can be stored safely.

For more details, here's the talk on this topic from 32C3.