SSL or Secure Sockets Layer which is widely used in the "web" world to encrypt the data stream between the browser and the webserver is actually also used in the WAP environment. However, SSL is only used between the webserver and the WAP gateway. Between the WAP gateway and the WAP device, a similar system called WTLS or Wireless Transport Layer Security. WTLS is specialized for the wireless environment.

Security is a touchy subject. Althought no systems are totally secure, SSL and WTLS on their own in my humble opinion provide adequate security for most applications. However, there is a potential security problem where the two protocols meet, and that's inside the WAP gateway.

SSL is not directly compatible with WTLS, so the WAP gateway must decrypt the SSL protected data stream coming from the webserver and then re-encrypt it using WTLS before passing the data on to the WAP device. Inside the memory of the WAP gateway, the data is unprotected.

This is the current model:

                   |                              |
  [WAP device]------------[WAP gateway]-----------[Content server]
              <---WTLS--->{unprotected}<---SLL--->
                |                              |
     (Firewall) |                              | (Firewall)
  

Imagine if your bank or other institution dealing with sensitive data make public a WAP service. When the data leaves the security of your system and your network they are resonably well protected. Then, when they enter the WAP gateway which is commonly owned and operated by a third party such as a mobile operator, the data is decrypted. I'm not saying all mobile operators are potential security risks, trusting sensitive data to an unknown third party is hardly a good idea. The mobile operator in question could be any mobile operator in the world. Your customer might be on vacation in some country where security is considered a trivial matter. If the mobile operator's networks are vulnerable to attacks, so are your data.

All the major WAP players are developing solutions to this problem, but for now these solutions create other problems. Developers of so called "WAP servers", or webservers with WAP gateway capabilities provide end-to-end security in a way because the data stream leaves the content server (the "WAP server") already encrypted with WTLS.

The model then looks like this:

However, the mobile operator's WAP gateway can now no longer be part of the chain, and the user has to reconfigure his WAP device to point to the "WAP server" which will become the WAP gateway for this session. But, this WAP gateway only provides access to this one service, and when the user wants to access his other favourite WAP sites, he has to reconfigure his phone again. Some WAP devices are fairly easy to reconfigure for someone with who can be bothered to read a manual, but some WAP devices are extremely difficult to reconfigure.

Adding to this problem is the fact that many mobile operators place their Point-to-Point service where the mobile device dials in to get on the internet, and their WAP gateway on the same private IP range network, usually behind a firewall. This firewall is usually set up only to allow the HTTP protocol on port 80 which is default for this protocol. The WAP gateway uses this port to receive data from content servers on the internet, and that's all it really needs. When the WAP device attempts to access another WAP gateway on the internet, the firewall will stop them either because the firewall says that the IP address of the WAP device is not allowed to route data on to the internet, or that it cannot open the ports it requires. This effectively stops the user from using other gateways that the one provided by the mobile operator.

There are lots of people suggesting solutions to this problem, and the rumours say that upcoming versions of WAP will have a solution. Until then, at least sit down and think through what you are about to do. In my opinion there are far easier ways of getting hold of someone's credit card number, name and signature than hacking into a WAP gateway.

If I might make a suggestion myself, it would be to make WAP gateways accept already WTLS encrypted data streams and simply pass them along to the browser untouched. This would cause the least amount of problems for the consumer. It's easier to upgrade all WAP gateways than all WAP devices. The third party's gateway (for instance the mobile operator) would then just be a relay for the data stream as it is already protected by WTLS by the "WAP server" securely located at the company providing the service.

In other words, a model like this where the WAP gateway has two modes. A "normal mode" where it works like WAP gateways work today, and a "passthrough" mode where the gateway detects the WTLS stream and simply lets it pass through.

  "Passthrough mode"

                 |                             |
  [WAP device]------------[WAP gateway]-----------["WAP server"]
              <---------------WTLS--------------->
                 |                             |
      (Firewall) |                             | (Firewall)

Some good information on securing WAP are available at the following locations:

• Wapforum's WTLS specs (high caffeine factor): SPEC-WTLS-19991105
• Baltimore Telepathy's Secure Demonstration: http://www.baltimore.com/telepathy/wdemo.html
• Tantau's excellent paper covering, among other things, WAP protcol structures (*register* first!): An Introduction to WML Programming and Third-Party WAP Toolkits
• Phone.com's excellent paper on wireless security (*register* first): Understanding Security on the Wireless Internet