Author: Martin

Breaking HTTPS Connections in Two Parts Considered Harmful

Last week, About Mobility and Masabists ran a story on the difficulties mobile transcoders have with secure HTTP connections and how they can put themselves into the the connection and thereby breaking end to end security. I've done some research on my own and since I am quite opinionated on the topic I wanted to post my results and thoughts here as well.

O.k. so first of all, what is the fuzz all about in simple words: Today, when somebody uses his mobile browser to connect to his bank, a secure HTTP (HTTPS) web connection is established to the mobile portal of his bank. HTTPS means that before any data is exchanged the banking portal sends a certificate the browser can cross check to ensure that the browser really talks to the server of the bank and has not been redirected to another site. After the certificate has been received, an encrypted end to end connection is established that no one, not even a mobile transcoder in the network can put itself into.

So for the user this is good since he can trust HTTPS to verify that he is really connected to the bank and he can also trust that all data that is sent and received is encrypted from end to end. For the transcoder this is bad since it has no chance to transcode the content and do other things with it.

So some smart people came up with what is called link rewriting to circumvent this 'issue', if you want to call it that way. With link rewriting, the transcoder doesn't forward a web page to the user with an original HTTPS link but with an HTTPS that points to the transcoder itself. When this HTTPS connection is established a secure connection is only established to the transcoder itself. The transcoder then establishes a second HTTPS link to the original server.

This means that the user no longer has a end to end encrypted protection but has to trust that the transcoder keeps his data secret. Also, the user can no longer verify if the transcoder contacts the original server, as the certificate that can be queried in the browser is that of the transcoder and not that of the original site.

In addition, this is totally transparent to the user as he will still see the "lock" icon that suggests an end to end secure and encrypted connection. Only when the user actively looks at the certificate will he actually see that the connection is terminated at the transcoder.

Counter measures: The only way for the user to ensure that this does not happen is to save the original https link as a bookmark. This way the transcoder has no possibility to rewrite the URL and hence can not put itself in the transmission chain.

From a user point of view I consider breaking a HTTPS connection in two parts as very harmful. It only takes one incident where data is stolen via a leak in the transcoder to damage HTTPS' reputation. Also, if it is suddenly acceptable to break HTTPS connections in two parts for reformatting purposes, why not also use it for statistics or to ensure no content the provider does not approve of traverses the network!? No way, the data inside an HTTPS connection only belongs to the user and the server at the end and to no one in between, no matter how good the intentions of the party in the middle are.

My Latest Book is Now Also Available at Amazon in the US

I've noticed today that after the launch of my new book last month in Europe, it is now also available on Amazon in the US. It took a bit for the bulk shipment from the UK to arrive but now that it's available, sales seem to have picked up quite quickly. At the moment, Amazon.com says only a few copies are left and more are on the way. Thanks to all who have already ordered a copy! So if you live in the US or Canada and have considered getting a copy from Amazon.com, now's the time. At some point it will go back to "shipping in 7-10 days" status but it's usually restocked much quicker now that it is available from a local distribution center.

Opera Mini for Android

As an avid user of Opera Mini I was very happy to see that the version v4.2 is now available for Android. Alphas and betas have been available since last October/November so announcing a non beta version probably means it's quite stable by now. Good news for G-Phone users and mobile Internet access in general. Kudos to Opera, looking forward to see it on the G-Phone in Barcelona at the MWC!

Vodafone Germany Now Earns More With Data Than With SMS

Interesting trend to observe these days in Europe: The revenue generated from data services in mobile networks is now close or even surpasses the revenue generated by SMS services. Recently, Vodafone Germany reported their numbers of the previous quarter compared to the quarter a year ago here and the table shows how data service revenue is now slightly higher than SMS revenue. Only a year ago, data revenues were still significantly behind.

What the table does not show, however, is that from an earnings point of view, SMS is probably still far ahead. After all, transferring 160 character messages through the network at a price of around 10 cents makes a far better bottom line than the megabytes of data transferred at a flat rate. But nevertheless, things are changing and it shows how mobile Internet access continues to increase in importance to mobile network operators.

SAE Review Part 2: Mobility and Connection Management

LTE and SAE are making big steps forward and the major specification documents are nearing completion. In part 1 of this mini-series, I've started taking a closer look at 3GPP TS 23.401, the main SAE (System Architecture Evolution) specification document and reported about the flexible meshed like architecture design. In this part, I'll have a look at Evolved Packet System Mobility Management (EMM) and EPS Connection Management (ECM) and their differences to Mobility- and Session Management of UMTS.

Before taking a look at the features in SAE, let's have a look at how similar things work today with UMTS as many of you will be familiar to that. Here, the SGSN at the border between the radio access network and the core network has two management tasks:

UMTS – Packet Mobility Management

The first is called Packet Mobility Management (PMM) and deals with keeping track of the whereabouts of mobile devices. There are three states: A mobile device is PMM detached when it is switched off or if it is not connected to the packet switched part of the UMTS network. That's the case for example if the device has been set to connect to the circuit switched part right at power on but not to the packet switched part unless it becomes necessary, i.e. the user wants to establish a data session. When a data session is established, the connection state changes to PMM connected. Afterwards, if the mobile is connected but hasn't exchanged data with the network for some time, the radio network controller (RNC) can ask the SGSN to release the mobility management connection. The connection then enters PMM idle state and the mobile only reports to the SGSN when it changes a routing or location area. If an IP address was assigned, it is kept. From the application layer point of view (e.g. the web browser) there is no difference between PMM connected and PMM idle.

UMTS – Session Management

The Mobility Management only deals with the whereabouts and tracking of the mobile device, so this state machine knows nothing about assigned IP addresses and contexts. This is task of Session Management (SM). Here there are only two states, either a device has a session and an IP address or it hasn't. 

And now to SAE / LTE

In SAE things work a bit different and I guess that's the reason why the mechanisms had to change as well. The biggest difference in SAE is that once a mobile device is switched on it always has at least a default bearer. In other words, it always has an IP address when it is switched on. And again in other words it's not possible for a mobile device to be attached to the network and not have an IP address. Hence, session managements makes no sense in LTE/SAE. To reflect this, the following two state machines are used in LTE/SAE:

EPS – Mobility Management

This EMM state machine only has two states. When a mobile is switched off or uses a different radio access network technology (e.g. GPRS or UMTS) it's state is EMM deregistered. That's simple. There's an optional feature referred to as Idle-mode Signaling Reducation (ISR) described in Annex J of 23.401 that changes that rule somewhat but let's ignore it for now. Once the mobile sees an LTE network it tries to register and if successful it's state is changed to EMM registered. At the same time the mobile is also assigned an IP address. As a consequence mobile devices in EMM registered state always have an IP address. But the EMM state machine does not care about that fact, it is only influenced by mobility management procedures such as Attach, Detach and Tracking Area Updates. While in EMM registered, the network knows the location of the mobile device either on a cell level or a tracking area level. Which of the two depends on the connection management state machine described right below.

EPS – Connection Management

When a mobile device is registered (EMM state = registered) it can be in two connection management (ECM) states. While a data transfer is ongoing the device is in ECM connected state. For the mobile device this means that on the radio link a Radio Resource Control (RRC) connection is established. For the network, ECM connected means that both the Mobility Management Entity (MME) and the Serving (User Data) Gateway (SGW) have an connection to the mobile device via the S1 interface (the physical and logical link between the core network and the radio access network). in ECM connected state, the location of the mobile is known to the cell level and cell changes are controlled by handovers.

If there is no activity for some time, the network can decide that it is no longer worthwhile to keep a logical and physical connection in the radio network. The connection management state is then changed to ECM idle. Note the use of the term 'idle'. It doesn't mean the connection completely goes away. Logically, it is still there but the RRC connection to the mobile is removed as well the S1 signalling and data link. The mobile continues to be EMM registered and the IP address it has been assigned remains in place. In ECM idle state the location of the mobile is only known down to the tracking area level and cell changes are performed autonomously by the device without any signaling exchanges with the network

Interactions With the Radio Interface

From the base station and mobile device point of view there is a lot of room for maneuvering between ECM connected and ECM idle. While a lot of data is exchanged, the air interface can be fully activated for a device so it has to continuously listen for incoming data. In times of lower activity or even no activity at all, the base station can activate a discontinuous reception (DRX) mode so mobile devices can power down their transcievers for some time. The power down cycles range from milliseconds to seconds. In fact, the longest DRX cycle is as long as the paging interval. So from a mobile point of view the main difference between being in ECM connected state with a DRX cycle the length of a paging intervall and being in ECM idle state without a radio interface connection is how it's mobility is controlled. In ECM connected state, handovers are performed, in ECM idle state, it can change its serving cell autonomously and only has to report to the network when it leaves the current tracking area. In other words, the base station is likely to keep the mobile device in ECM connected state for as long as possible by using DRX so data transfers can be resumed very quickly before cutting the link entirely and setting the state to ECM idle.

Summary

Quite difficult to make a summary as Mobility Management, Connection Management and air interface DRX control are in theory independent from each other but have to be looked at in common to make sense. In a rough generalization I would say that during normal operation:

  • a mobile is always in EMM registered state because it's identiy is known to the network and, implicity, an IP address has been assigned;
  • a mobile transfering data is always in ECM connected state;
  • a mobile not transfering data is also in ECM connected state but DRX is activated on the air interface;
  • only mobile whith very long periods of inactivity are in ECM idle state while staying EMM registered.

I hope this look at EMM and ECM from different points of view have made the concepts a bit clearer. In the next part of this mini-series, I'll have a look at the different handover variants the SAE architecture supports to ensure the mobile device is always best connected. As always, comments are welcome.

Meet Me at the Mobile World Congress at the Wiley Booth

Ms-mwc-sm
The Mobile World Congress 2009 in Barcelona is coming closer and I am happy to announce that my publisher John Wiley and I will feature a "Meet The Author" session at their booth to promote the launch of my latest book "Beyond 3G – Bringing Networks, Terminals and the Web Together".

The details:

  • Where: John Wiley and Sons, Hall 2, 2A130
  • When: Wednesday, 18th February
  • Time: 2 to 4 p.m.

So no matter whether you already have a copy, are interested in the content, are thinking about picking one up, or if you just want to have a chat with me I am very much looking forward to meeting you there!

For those interested in taking a copy home, Wiley will offer a 20% discount. If your suitcase is already full, there's also the option to place an order at the booth and have to book shipped to you.

Over the years, this blog has become a very frequented place and I had many e-mail conversations with people working in the industry from all over the world. Now it's time to put some of these conversations into the real world. Again, it would be a pleasure meeting you at the Congress! See you there!

Carnival of the Mobilists #159 at The Mobile Broadband Blog

Cotm-button
This week, the Carnival of the Mobilists has stopped over at Ram Krishnam's "The Mobile Broadband Blog". It's edition 159 this week, quite amazing, and I still remember how I was part of one of the first single or double digits ones by accepting to run an edition by exchanging e-mails with Russel Buckley on my mobile phone while being on the way from Lisbon airport to a meeting. Nothing special these days anymore but at the time, quite something. Tomi Ahonen would probably say it was a magical moment. So without further ado, I can warmly recommend to head over and enjoy the great writeup.

Email As The Simple Way Out

Another normob (normal mobile user) story today. A friend of mine keeps track of her notes on her Nokia N82 as it's quite convenient to use it together with a Bluetooth keyboard while traveling. While most of those notes stay on the phone, every now and then they should also end up on the PC. So how can that be done best, i.e. quickest? As a normob, that's a difficult question (but shouldn't be).

The answer is quite simple once you've set up an email account on the phone and are used to using the Wi-Fi connectivity at home with the phone. Then you just go to the notes application, click on send via email and the note ends up in the email inbox on the PC a couple of seconds later. Simple and straight forward once you've figured out how. And again, that's the problem, figuring it out in the first place. Too many pieces have to fall into place first before it becomes easy.

On the other hand, now that there is one 'killer application' for mobile email and use of the Wi-Fi at home (in addition to VoIP telephony) with the phone (and to her it's still a phone and not a mobile device…), it might lead to discovery that the mobile email client can be used for much more than to just forward notes.

Hm, maybe that's the difference between the iPhone vs. the competition from a normob point of view: While the iPhone is seen as 'something + a phone', other devcies are still seen as 'a phone + something'!?