The Wireless Web - Is it Secure?

This curious member of Clan Anonymous Coward asks: "I really know very little about the technical details of Sprint's Wireless Web network, AT&T's PocketNet service, and others like them. I'm wondering whether the encryption over the airwaves for these things is any good ('powered by RSA') and properly implemented." This is a decent question on what might turn out to be the next generation of communications services.

smart people built it

[Anonymous Coward]

I was working for Unwired Planet (now phone.com) when the first version of the gateway that implemented encrypted sessions was built and tested. One of the smartest programmers I've ever met built that part, and it's been reviewed by every carrier they've sold gateways to, and some who were just kicking tires. I never heard any complaints.

If the source was open, I'd suggest reading it. Thos guys wrote some of the finest code I've ever seen.

right, but if you're the client. . .

[jslag]

Never trust the client. You should know that HTTP headers can be forged with the hacker tool 'telnet'

On the flip side, if you're the one with the phone, the only way you can keep servers from getting your phone number is by doing through some custom proxy that fudges the header (which is x-up-subno I believe, no http- prefix.)

----------------

need to trust gateway operators, though

[jslag]

Even if the software is tight, which we have to take on faith, people operating webservers with wml / hdml content are IIRC dependant on the people operating the gateways to run with a sane configuration - sure, the phones are capable of doing encryption over the airlink, but isn't using / not using crypto a configuration option? So I could be running a server and only allow https connections between my webserver and phone gateways, but I have no way of knowing if the gateways are in turn encrypting the signal between themselves and the phones.

One answer to this is presumably "run your own gateway", but I don't believe this is practical if you want to run a site for the phone-using public, since they will all be coming in via their phone company's gateways (please correct me if I'm wrong about this).

----------------

Re:smart people built it

[prac_regex]

THIS MEANS NOTHING
and let me tell you why. These "smartest programmers" were coding because a manager told them to make something. look at wslt [waplite.com] and tell me that ppp-encapsulation over wireless is secure. Until cryptography is done on the device, and strong. count me out of the wireless e-commerce movement. because it is STUPID.

Re:Answers...

[prac_regex]

Cryptography is the key. and of course key signing protocols bettter then verisigns lame "im verisign because i say i am" method. then https can be nice. and of course if the nsa stopped being lame it wouldnt hurt.

Re:Offtopic: one thing I despise...

[GeorgeH]

Never trust the client. You should know that HTTP headers can be forged with the hacker tool 'telnet'

OTOH, I've been trying how to WAP enable my house's X-10 system securely, and haven't come across a better mechanism to do this.
--

general summary

[jslag]

I looked into this a few months ago, and came up with the following understanding of wireless security. I find it easiest to break things down by the path your data takes from your device to the server in question:

1) airwaves (between mobile device and phone tower). This is relatively secure right off the bat, insofar as it's a pain in the ass to intercept phone signals, esp. for CDMA as is used by Sprint (and everyone else but AT&T). If someone really wanted to intercept your signal, they'd probably need something along the lines of a bogus base tower - not so easy for civilians without contacts in the industry to do, but it could be done. Then there is optionally encryption of the data, which happens 1) automatically for AT&T's CDPD network, and 2) optionally on the content layer: HDML and WML both are associated with bastardized versions of SSL, HDTP (handheld device markup layer) and WTLS (wireless transport layer security) respectively. These last two forms of encryption are configured via phone gateways - key size can vary, as can the requirement that they be used at all (IIRC).

2) at the gateway, content is always unencrypted - the wireless encryption needs to be translated to SSL, if in fact the HTTP portion of things is to be encrypted. phone.com makes a big deal about how hard it would be to intercept the unencrypted data, but we'll never really know until we get our hands on gateway software, eh?

3) the internet (or frame relay): typically the phone gateway will then send your packets out over the internet to the server in question, so normal internet security issues apply here. Note that the phone gateways seem to have some abilities to store client certificates, so it may be possible to do various client-authentication type stuff.

As far as the frame relay thing, AT&T also suggests the possibility of running a private line of some sort between their phone gateways and your server, thereby avoiding the uncertainties of the public internet, but that would limit your customers to those with AT&T phones (which is certainly possible for intranet type apps).

Conclusion: There don't seem to be any gaping security holes for low-risk apps such as those that my company had been involved with up until recently, but there are a number of places that a highly-motivated person might be able to sniff / mess with your data - in the air & at the gateway, primarily. If I were interested in fund transfers or the like, I'd want to do some serious investigation into the security policies & practices of wireless phone companies with regards to their gateways, and find out more about the practicalities of intercepting signals in the air.

----------------

Offtopic: one thing I despise...

[pnevares]

I was messing around with building some pages for my phone to check my e-mail, and wanted to secure it against other viewers. Usually I do this based on IP, because my home and work computers are both static, but my cell phone doesn't have an IP. Instead, I did it by subscriber ID. In the Developer FAQ on Phone.com, they say it's impossible to determine what the clients phone # is, but the subscriber ID has it sitting right there!

IIRC, the HTTP header is HTTP_X_UP_SUBNO...check it out.

Pablo Nevares, "the freshmaker".

Ricochet

[rise]

Metricom seems to be doing it right: low power (side effect of the mesh network, but yet another difficulty in interception), many packet routes from poletop to poletop, frequency hopping, and a halfway decent encryption algorithm. I'd still use FreeS/WAN or OpenSSH over the connection, but that's because I'm paranoid. In common usage it should be far harder to intercept & decrypt than any of the proposed or implemented cell based systems, and would you trust USWest or Bell Atlantic with implementing security correctly?

Answers...

[rjh]

#include "disclaimer.h" /* see my sig */

Is the wireless Web secure? No. Is the Web secure? Also no. There is no difference, realistically, between wireless and wired networks. Have you ever used a satellite link to send data across the globe? A lot of people have and never realize it. The Net is a hybrid network; wired and wireless coexist equally. They only exist to transport data, and data sent in the clear is just as vulnerable on a wire as it is via wireless as it is via smoke signal.

Remember that a network is only as secure as its weakest node. Unless you take significant precautions, your Web transactions are insecure, period. Even HTTPS isn't a great solution.