Netmotion wireless provide some innovative solutions for VPN from mobile devices. Their product Mobility XE allows organisations to provide seamless VPN access from mobile devices. Now it’s available for Windows Mobile 5.0! Check out more details at:
Nothing like the smell of FUD in the morning 
After my post about the Fear Uncertainty and Doubt (FUD) being spread by some competitors around incoming firewall ports – there is some new FUD to deal with.
This is that some organisations are claiming that our solution is not secure because we use SSL vs 3DES which they use.
This isn’t really an accurate comparison as it’s like comparing a boat with a car.
3DES is a type of encryption cipher (156 bit) and SSL is a secure channel of communication.
Windows Mobile uses SSL with RC4 cipher (128bit). This is the web standard for the most secure internet based communication between two entities (even used in online banking).
Most use SSL or TLS with RC4 encryption today. To crack 128 bit key using exhaustive key search, it would take 5.4 x 10^(18) years to crack it doing 100 billion decryptions per second.
Within Windows Mobile we can use 3DES as the cipher if you wish – all you have to do is enforce group policy setting for FIPS compliance on the Exchange Front End, it will use 3DES encryption over Exchange Activesync as well.
Following on from the success of the Orange M500 (HTC Magician) – Orange have announced the Orange M600 which is their variant of the HTC Prophet device.
I somehow missed this announcement but one of my colleagues pointed to it at CoolSmartphone. http://www.coolsmartphone.com/news2163.html
The device carries Windows Mobile 5.0 and Orange estimate standby time of 180 hours (7 and a half days!) as well as talk time of 5hrs.
A really interesting article has appeared citing the a Survey estimated that T9 Predicitive texting is causing up to 3.8 million UK citizens to be suffering from repetitive stress injury!
The survey was done by Virgin Mobile and showed that in the UK over 93.5 million text messages are sent every day but all this digit action has lead to an explosion in people reporting cases of repetitive strain injury (RSI).
Thirty-eight percent more people suffer from sore wrists and thumbs due to texting than five years ago and 3.8 million people now complain of text-related injuries every year.
The survey for Virgin Mobile found the texting phenomenon shows no sign of slowing. Over 12 percent of the population admit to sending 20 texts per day and 10 percent confess to sending up to 100 texts every day.
So are you in the top 10% ?
I’d better go now… my fingers hurt 
If you haven’t been to WindowsMobile.com (www.windowsmobile.com) lately you are missing out on the huge update that’s taken place on the site!
Check it out….
T-Mobile USA has released the SDA and MDA devices!
Both are Windows Mobile 5.0 devices!
Check out more details at:
I’ve had a number of questions regarding my previous post and questioning whether ISA is a requirement for our Push Email solution.
Let me clarify – it is NOT….
However…. there are some benefits of using ISA in that:
1) It’ll pre-authenticate any SSL traffic
2) It will allow you to inspect the traffic passing through Port 443 and ensure it is Activesync traffic
Many customers won’t have or won’t want to implement ISA so you can use any firewall that allows you to publish port 443.
There seems to be some FUD (Fear Uncertainty and Doubt) being circulated by some of our competitors in the Mobile Email space.
The FUD is really in two areas:
1) We require lots of firewall ports open
2) This is ‘insecure’
Both the areas are actually a huge mis-understanding:
For Windows Mobile/MSFP you do need to allow inbound access somehow to the Exchange server, but that can be done securely by using an ISA Server as the firewall to sit in front of Exchange and terminating the SSL connection on the ISA box, pre-authenticating the user (so nothing anonymous ever hits the real Exchange server), inspecting the protocol for attempts to subvert it, and then ultimately re-encrypting the stream and forwarding it on to Exchange.
The only firewall port that needs to be opened is port 443 which is SSL. A large majority of our customers already have this firewall port opened for the use of Outlook Web Access.
All traffic is encrypted using SSL (128 bit encryption).
Microsoft itself uses this exact approach and we have over 40,000 users using this environment securely:
http://www.microsoft.com/windowsmobile/business/strategy/scalability.mspx
If you wish to go one step further by enforcing two factor authentication above and beyond the protection that our Firewall is providing then you can add any of the following:
1) Certificate based user authentication
2) Secure ID authentication
3) Private APN services in the GPRS world where only specific devices can connect over a secure APN to a specific Server.
For Microsoft Partners we have the following FREE course which will give you the in-depth knowledge to setup, configure and support the Microsoft Direct Push Email solution!
Courses are at Wokingham, Edinburgh, Wakefield and London run by our training partner Azlan.
There are still places free so sign up at:
http://www.microsoft.co.uk/events/EventDetail.aspx?eventid=8320
Previously many customers had avoided using SecureID with Exchange Activeync because entering the credentials each push/sync would impact the users experience negatively.
This has however recently become a much more viable alternative. SecureID will now work much better with DirectPush due to some recent enhancements they’ve made.
In their latest RSA Web Agent update http://www.rsasecurity.com/node.asp?id=2807&node_id= there is a new feature that allows ActiveSync sessions to be “cached” for an admin-chosen number of hours. This better explained by an extract from RSA:
”RSA Authentication Agent 5.3 for Web for IIS enables you to use Microsoft Outlook Web Access ActiveSync without having to reauthenticate every time ActiveSync is invoked. When you invoke ActiveSync by clicking Sync on the Pocket PC, the Agent provides a one-time authentication window for ActiveSync that is valid for a default of 15 minutes. This default time setting matches the default time setting of Cookies Always Expire After the Specified Time. If you extend the duration of the browser session cookie by changing the value in the Cookies Always Expire After the Specified Time field on the Agent tab of the IIS configuration panel, you extend the one-time authentication window for ActiveSync to the same number of minutes. You can further extend the ActiveSync time window to remain valid beyond the maximum time duration of the browser session cookie by adding an entry to the registry”
More details are posted over at the Exchange blog by Max
http://blogs.technet.com/exchange/archive/2006/02/16/419756.aspx
