Raising the Shields – Part 14: Skype Jumps Into My VPN Tunnel Despite The NAT

According to public wisdom, the days when Skype was secure are long gone and I use my own instant messaging server to communicate securely when it comes to text messaging. When it comes to video calling, however, there are few alternatives at the moment that are as universal, as easy to use and with a similar video quality. Under normal circumstances Skype video calls are peer to peer, i.e. there is no central instance on which the voice and video packets can be intercepted. That's a good thing and Skype has many ways to find out if a direct link between two Skype clients can be established.

And here's a really interesting scenario: Skype is even able to find out that a direct link can be established through my VPN link I usually establish with my VPN server at home when I'm traveling and a Skype client on a PC at home despite a NAT between the VPN link and the local home network. That means that when I'm traveling, Skype packets are routed directly between the Skype client running on a PC at home and the Skype client on my notebook that is connected to my home network over a VPN tunnel. At no time do such Skype packets traverse a link on the Internet outside the VPN tunnel. In other words, potential attackers that can passively collect packets between where I am and my home network are unable to decrypt my Skype traffic, should they have such an ability.

Sure, Skype and anyone who has access to Skype can still find out if and when I'm online, probably even where I'm online and when and to whom I make calls. The call content, however, can't be intercepted without me noticing, i.e. when the traffic suddenly is not peer-to-peer through the VPN tunnel anymore. Far from perfect, but something to work with for the moment.

Opera Turbo Turned Off After 30 Seconds

Opera and it's server side compression have helped me a lot over the years to overcome issues like slow connections or strange operator proxys blocking access to websites such as the strange case I came across back in 2008. Fortunately, networks have become faster and other strange effects caused by meddling with data have also receded so I usually use the full Opera browser these days instead of Opera Mini or the Opera Turbo functionality. But every now and then I end up in a GSM-only place and so far the server side compression always helped. Well, up until now.

When I recently wanted to use Opera Turbo again to browse my favorite websites in a bandwidth starved area it took a long time because all advertisement I can block so conveniently locally with a modified hosts file had to be loaded again. Not only did it take long to load the pages due to the advertisement but splash screens and other intrusive advertisement is just not my cup of cake. So after about 30 seconds I switched off Opera Turbo again and resorted to a non-proxied connection, which was not slower for my favorite pages than using server side compression as all advertisement was stripped out. And not only was it not slower, I also didn't have to put up with splash screen advertisement. So for me the days of using server side compression to speed up my web experience in bandwidth limited areas are definitely over…

Another LTE First For Me: Intercontinental Roaming

I've had quite a couple of LTE and roaming firsts this year and, as I've laid down in this post, 2014 is the year when affordable global Internet roaming finally became a reality. Apart from having used a couple of LTE networks in Europe over the last couple of months I can now also report my first intercontinental LTE experience. When I recently traveled with my German SIM card to the United States, I was greeted by an LTE logo from both the T-Mobile US and AT&T network. Data connectivity was as quick (but I didn't run speed tests  so I can't give a number) and with the 20 bands supported by my mobile device I could actually detect quite a number of LTE networks at the place in Southern California where I stayed for a week:

  • Verizon was active in band 13 (700 MHz)
  • Metro-PCS in Band 4 (1700/2100 MHz)
  • AT&T was available in band 4 (1700/2100 MHz) and Band 17 (700 MHz)
  • Sprint had a carrier on air in band 25 (1900 MHz, FDD) and band 41 (2500 MHz, TDD)
  • T-Mobile US had a carrier on air in band 4 (1700/2100)

And in case you wonder how you can find LTE transmissions without special equipment, have a look here. It's not quite straightforward to map transmissions to network operators but not impossible with a bit of help of Wikipedia (see here and here) and 3GPPs band plan that shows uplink and downlink frequencies of the different bands.

Netflix, HTML5, Linux and What Else Made Me Sign-Up

There we go, I signed up to Netflix after being on the lookout for years for a video on demand service that would fit my needs! Here's the story:

A video on demand service has to run on Linux for me because that's my OS of choice for all my computers at home. This, together with a 4 year old media center PC, disqualified all VoD services so far because all of them either require the Adobe Flash player plugin or, even worse, Microsoft's Silverlight. I tried Amazon's video service for a while but the Linux version of the Adobe Flash player sooner or later crashes during video playback. I also tried the Linux wrapper for Silverlight, which seems to work fine on newer PCs. On my 4 year old media center PC, however, I never got a smooth video playback that way.

And then Netflix came around the corner with HTML5 video playback support. Unfortunately, but hardly surprising, it uses an HTML5 extension to play back DRM protected media. Yes, I know that's evil from an open source point of view and Mozilla has rejected to put it into their browser so far. On the other hand, however, Google has decided to support this extension in their Chrome browser. I'm about as far away from liking Chrome than being a Microsoft or Adobe fan boy but I can live with a Chrome installation on my Linux system for a specific purpose while continuing to use Firefox for everything but Netflix.

Up until last week a tweak was required to make Netflix use Chrome on Linux, i.e. the user agent needed to be tweaked. I was tempted to install the plugin for the purpose but didn't come around to it before Netflix announced that they now support Chrome on Linux as well now. Having heard that I signed up immediately to give it a try and the video is as smooth on my somewhat older machine than as I could ask for. Well done!

And the second issue I've had with most VoD services, in particular the ones offered by German companies, is that their support of the original English audio of the content is minimal at best. Not so with Netflix, everything I've watched so far has English audio.

So as you can imagine, I was busy over the weekend to check things out. Netflix says on the configuration settings page that full-HD video streaming requires a  bandwidth of up to 6.5 Mbit/s. In practice I've observed that the content I've watched was streamed at around 3.5 Mbit/s or around 1.5 GB per hour on the PC and around 1.5 Mbit/s or around 650 MB per hour via the Netflix App on my smartphone. Let's see how long Netflix can keep me entertained and what kind of impact that will have on my monthly data consumption over my VDSL line at home. So far, my monthly usage has been around 35 GB which already includes a fair amount of audio and video streaming.

And the closing thought for today: Netflix also seems to offer some content in 4k resolution. No I don't have a screen for such high resolution content but I'm mentioning this because of the staggering bandwidth required for that resolution. On the settings page, Netflix says that 4k video requires up to 7.5 GB per hour, i.e. the video streams at over 16 Mbit/s. Now double that for two screens in the household… And now assume two times 2 hours consumption a day which would result in a monthly data usage for Netflix alone of 900 GB. Yes, I know, that's not going to be tomorrow and not for everyone but it shows were we are headed.

How Fast Is An OpenVPN Server on A Raspberry Pi And A Banana Pi?

I've been running an OpenVPN server at home to protect my data traffic for quite some years now, first on an WRT54 Wi-Fi Router and later on a Raspberry Pi thanks to a great article over on ReadWrite. The solution I had so far has been limited to a maximum throughput of 5 Mbit/s as that was the uplink speed of my VDSL line at home. As we have a fiber FTTH line in Paris now with a maximum speed of 264 Mbit/s in the downlink direction and 48 Mbit/s in the uplink direction it was time to relocate my VPN service to that location to lift the 5 Mbit/s limit. It was really time for that as I easily surpass such speeds today while connected via UMTS and LTE. But it turns out the next road block is just around the corner.

And that next road block is the Raspberry Pi. Encryption and Decryption data must be quite computing intensive so the Raspberry Pi's processor is fully loaded at an encrypted line rate of around 10 Mbit/s. Twice as much as I had before but still far from what the fiber line offers. So I decided to move to a Banana Pi with it's much stronger processor. At around €40 without casing it only costs 10 euros more than a Raspberry Pi. And as it turns out the processor can shuffle encrypted OpenVPN data through the Ethernet Interface at a rate of 30 Mbit/s. Not quite the line rate of the FTTH connection but it's not too bad either and to go further I would have to put an Intel NUC or other high power CPU device in place which would cost much more. So the price / value balance of the Banana Pi seems quite right to me, at least for now.

Next on my list of things to do is to make the Banana Pi work as a OpenVPN Client Gateway and Wi-Fi Access Point. I use a Raspberry Pi today today to bundle the data traffic of all my devices while I'm traveling through a single VPN tunnel to my VPN Gateway which is, not surprisingly, also limited to 10 Mbit/s. All the scripts for configuring a Raspberry Pi are on GitHub but I'm running Ubuntu on the BananaPi so some of the things need to be tweaked.

 

October 2014: Three Networks Left In Germany

A little note today so I can search more easily for it in the future that October 2014 was the month when the EU sanctioned merger of Telefonica O2 Germany and KPN's E-Plus was finalized from a contractual point of view. While the networks of the formerly two independent companies are still separate, this effectively reduces the competition from 4 mobile network infrastructures to 3 once O2 starts integrating the two separate networks.

Yes, the EU has put some conditions in place to 'ensure' (in their opinion) continued competition. I doubt, however, that even the most important one in the form of putting a capacity reseller in place for a certain percentage of the united O2 and E-Plus will do much in this regard. The business practices of the company that got the contract in the past has, well lets says, been somewhat unusual and even apart from that, it still doesn't make up for the fact that infrastructure competition is seriously hampered by this move.

So no, I'm not happy about this decision at all and I really hope that I will be proven wrong. But it's only hope as up to today, there aren't too many examples in Europe, if any, where competition with three incumbent network infrastructures in a country have led to a healthy price level and adequate coverage.

So let's see how the mobile landscape will look like in Germany 2 years and 5 years down the road from now.

My First Prepaid LTE Experience

It's taken a long time and still today, at least in Germany, most network operators reserve their LTE networks for their postpaid customers. In recent months, this has somewhat changed in Germany with the fourth network operator also starting LTE operations and allowing their prepaid customers access from day one. These days their LTE network is also available in Cologne so I had to take a closer look, of course with a prepaid SIM and a €2 per 24 hours data option that gave me up to 1 GB of unthrottled data.

Data rates I could achieve were not stellar but not really bad either. Under very good signal conditions I got close to 30 Mbit/s in the downlink direction and about 10 Mbit/s in the uplink direction. Closer examination revealed that they are using a 10 MHz carrier in the 1800 MHz band which should allow, under very ideal conditions up to 75 Mibt/s in the downlink direction (have a look here if you'd like to know how you can find out which band and bandwidth your LTE network operators is using). But no matter what I did and where I went in the city, the 30 Mbit/s was the magical limit. I don't think the air interface is the limit, the bottleneck must be somewhere else. Under other circumstances I would probably be ecstatic about such speeds but with data rates of 100 Mbit/s+ other operators achieve easily, the 30 Mbit/s pale in comparison.

In a recent network test I reported on, CS-Fallback Voice Call establishment times of that network operator were reported to be pretty bad. I can't confirm this, however, so perhaps they have changed something in their network in the meantime. What's a bit unfortunate, however, is that after a voice call the mobile stays in 2G or 3G a long time before returning to LTE. Other network operators are more advanced and redirect their mobiles back to LTE after the call. That makes for a much better experience. Also, I noticed that there's a 2-3 seconds interruption in the data traffic while switching from UMTS and LTE. That means that they must still be using a rather crude LTE Release with Redirect to UMTS procedure rather than a much smoother PS handover.

While the above is perhaps still excusable, there's one thing they should have a look at quickly: Whenever the mobile switches from 2G or 3G back to LTE the PDP context is lost. In other words, I always get a new IP address when that happens which kills, for example, my VPN tunnel every time it happens. Quite nasty and that's definitely a network bug. Please fix!

In summary the network speed is not stellar compared to what others offer today and some quirks in the network still have to be fixed. On the other hand, however, you can pick up a prepaid SIM in a supermarket and get LTE connectivity without a contract.

Affordable Global Internet Access Roaming Becoming A Reality

Accessing the Internet from a mobile phone or tethering a PC over it while traveling all over the world has been possible for many years. Unfortunately, it was also prohibitively expensive. A solution to the problem was to use local SIM cards but getting them has and still often is a hassle. 2014, however, will have been the year when all that has changed, at least for some of us, fortunately including me. And here's why:

New in 2014: EU Data Roaming For A Few Euros A Month

Earlier this year I reported about the new Euro-Roaming offer of my network operator that lets me use my data bucket that is included in my monthly subscription in all EU countries without any extra charges for 5 Euros extra per month. One price for all countries. Perfect, my Internet access problem is solved, and I no longer need local SIM cards except in really exceptional circumstances.

New in 2014: Global Roaming Prices Reach Affordable Levels

But the EU isn't the world and I also travel a lot to Asia and the US. Again, new roaming prices of my home network operator for global destinations completely changes the game. Instead of 20 euros a day for only a few megabytes, the latest offer for any destination is around 12 Euros per week for a 150 MB bucket. If the data is used up sooner, another bucket can be bought instantly via a landing page. 150 MB is not much by today's standards and I had to buy several packages during a recent trip to China to keep me connected, but compared to previous prices this is heaven and totally usable.

New in 2014: Fast Networks And LTE Roaming

When I visited countries such as China in previous years I always noticed how slow even 3G connectivity was. While it could have been the local network I suspect that connectivity between the visited network and my home network was rather underdesigned. Again, when I was recently in China, 3G connectivity was fast and totally usable. I'm delighted! Also, 2014 is the year when LTE roaming agreements finally started to fall in place. Over the past months I've roamed on foreign LTE networks in quite a number of countries and I've achieved data rates of well of 20 Mbit/s. Not that 3G networks are slow but seeing that LTE indicator in the status bar is still something special and promises fast data rates.

New in 2014: Viginti Band LTE Phones That Also Include 5-6 UMTS Bands

While LTE roaming in Europe for European customers is not a problem from a mobile device point of view, getting LTE connectivity in other parts of the world has been another matter altogether so far as North America and China use different UMTS and LTE bands. 5-6 band UMTS and LTE devices have been available for a while in Europe but these unfortunately did not include bands for other regions. But again, things have changed dramatically for the better. One popular smartphone now boasts support of 20 (!) LTE bands and 6 UMTS bands. This includes all major LTE and UMTS bands used in Europe, North America and even the TD-LTE bands used in China. That's especially good news for global travelers no matter where they come from because true Global UMTS and LTE roaming has now become a reality. I'm more than delighted!

I've been using mobile Internet access while traveling for pretty much a decade now. 2014, however, has brought about an as dramatic a change of my usage behavior as the introduction of local prepaid SIM cards for mobile Internet access had many years ago.

Will Fiber To The Home Become The New Monopoly?

Those who have gigabit Internet speeds at home thanks to a 'fiber to the home' (FTTH) connection are probably more than happy with their Internet access. I benchmarked such a connection recently and I guess I'd be more than happy as well to have such a line at my home in Cologne. Given some time, perhaps…But I can't help thinking that once a fiber cable is laid into the streets and houses by a network operator, it effectively creates a (next generation) monopoly, as no other network operator will have an incentive to put a fiber into the same ground as well. So the monopoly moves from copper to fiber as once users have become accustomed to fiber access they are unlikely to go back to something that is significantly slower. Again, the only competition could come from cable operators who also have fiber cables close to buildings today and can thus extend fiber connectivity from there to individual buildings. Hm, sounds like operator monopoly 2.0!?

Android’s Password For Encryption Can Be Different From The Screen Unlock PIN

I can't remember when I first read about Android's ability to encrypt the user data partition. What I did remember however was, that the article said that the PIN used for unlocking the screen is also used during system startup to unlock the encrypted partition. I was pretty disappointed at the time because a four or five digit screen unlock PIN can easily be cracked in an offline attack so I never really bothered to give encryption a try. But is this really the case?

A Long Password For Encryption And A Short PIN for Unlocking The Screen

As I couldn't find the definite answer on the web I tried out myself with a device running CyanogenMod 11 (Android 4.4.4). And indeed, to start the encryption process a screen unlock PIN has to be set which is then also used to unlock the encrypted drive during system startup. But, and this is the good part now, the password to unlock the encryption key during system startup can be changed afterward to a password of a much longer length independent of the screen unlock PIN. In other words, it's possible to use use a long and strong password during system startup and a reasonably short and different screen unlock PIN. Perfect!

CyanogenMod Update Trouble

As far as CyanogenMod is concerned, however, there's a little catch: The automatic updater doesn't work anymore as the downloaded image is put into the user's encrypted data directory. Unfortunately, the CWM (ClockWorkMod) recovery manager used by CyanogenMod for many devices doesn't support encrypted user data partitions. The only way to update the system image on such devices if they are encrypted is to push the image from a PC via ADB to a temporary partition after the device has been booted to recovery mode. Here's a description of how that works. It's not difficult to do but not very convenient either.

More Details on Encryption

And for some more background information on how Android encryption works, have a look here.