We’ve recently discovered a great new resource (well, new to us, at least!) called Start64.com – a news and discussion forum for 64-bit software, security and OS issues. As the first provider of a VPN client for Windows XP 64-bit, NCP will now be regularly visiting Start64.com in order to take part in discussions and help readers with their questions about 64-bit security.
Archive for July, 2008
NCP has just announced the release of its Secure Entry Client for Symbian OS-based mobile devices. The new IPSec VPN client can be used on mobile devices such as the Nokia Eseries, which run Symbian OS from V.9.0 on S60 3rd Edition.
See Dark Reading for more information on this news.
One story has reigned supreme on the blogosphere this week: Dan Kaminksy’s DNS vulnerability discovery, Matasano’s accidental (?) explanation of the details, and the resulting community fallout over the ethics of blogging about security.
From the Network Security Blog…
Martin McKeay gives a good synopsis of the situation so far, and describes the efforts Matasano’s Thomas Ptacek has taken to apologize to the community at ChiSec.
From Matasano Chargen…
Regarding The Post On Chargen Earlier Today
Meanwhile, Ptacek has posted an explanation and apology on the Matasano blog.
From Errata Security…
A discussion of the implications this vulnerability has for ISPs and users – and which solutions will and will not mitigate the risk.
From Zero Day…
Microsoft joins ‘patch DNS now’ chant; Apple patch missing
ZDnet’s bloggers discuss the industry reaction to finding out about these vulnerabilities, and takes Apple to task for failing to respond with urgency.
From Rational Survivability…
The DNS Debacle In Poetic Review
Chris Hoff comments on the DNS fiasco in an epic series of rhyming couplets.
We asked NCP’s Joerg Hirschmann to take look at the arguments presented in Reliable Systems’ recent post, “Remote Access for Everyone,” and offer some respectful criticism of the case made for SSL versus IPsec. Quotations below are from the original article, with Joerg’s comments following.
Installation:
The success rate for an average user being able to install an IPSec client and get the VPN tunnels to work, even with phone support, was around 15%. Most of the time the user had to bring in the computer or we had to send a tech on site.
Management based native VPN installations are pre-configured by central administration. Configurations will be created automatically using a leading internal database like Active Directory. Users do not encounter configuration issues at all! They cannot even change VPN related settings. Pre-installed basic settings, getting personalized at first connection = Plug & Play VPN.
Compatibility:
Different physical network technologies – notably DSL – run into performance problems with IPSec in many configurations, requiring adjustments on the client, routers, or other things that you just can’t expect end users to understand.
A communication suite deals not only with the VPN part but also takes care of connecting the client safely and with the highest possible performance with the internet with only one goal: establish the VPN tunnel. The user does not even need to know the communication media; the client will select it automatically.
In general SSL VPN has much more performance issues than an IPsec based VPN which is primarily based on the protocol in use.
Portability:
IPSec is very easy to block on a network. In fact, it took some time for most network routers to be compatible with IPSec. Now try to get it to work at 8 PM over a wireless network in a hotel in Buffalo.
For this reason the client must be able to provide alternative tunneling protocols. If IPsec is blocked it must be able to use SSL tunneling as well.
SSL is Simple, IPSec is complicated:
SSL is a single TCP/IP socket with a relatively straightforward, self-configuring, and invisible to intervening appliances.
IPsec is as complicated as the solution installed. It can be as easy as SSL and offers advantages on protocol level as it is UDP and not TCP based (much more overhead with TCP!).
SSL is essential, IPSec is a threat:
No one can afford to block SSL on their network without basically admitting to not having a network at all. It’s very expensive to proxy by decrypting and re-encrypting, so few companies do it. On the other hand, many networks view with suspicion the goal of establishing an encrypted connection out of their network, so blocking IPSec may sound like a good idea
SSL is encrypted as well, so where is the advantage if you do not want to introduce those “very expensive to proxy by decrypting and re-encrypting” servers? This message is very contradictory. However, a VPN client must be able to provide a solution for those blocking networks and then switch to SSL based tunneling. In non-blocking networks IPsec is to be preferred as far less bandwidth consuming.
In response to our discussion yesterday about “Man in the Middle Attacks,” Rene points us to this article in Wired, which describes how Colombian government forces ‘masqueraded’ as FARC revolutionaries, in order to release hostages. “That was another example of MITM attack,” says Rene. “This time used for a good purpose!”
On the subject of practical precautions against more nefarious MITM attacks, he says:
You can help a user by adding mechanisms to assist in certificate verification in applications. Not only simple verification such as identities, but further nail them down to verify serial numbers/certificate fingerprints, verify issuer’s certificates and even the whole ‘chain’ / hierarchy of certification authorities involved and deny connectivity if something is amiss in this chain.
Further security can be leveraged by using online certificate checks (OCSP) or offline certificate revocation lists (CLRs) (of both user/client [EPRLs] as well as issuers [ARLs]). This should be done from two sides; the client should verify the gateway’s identity and the gateway should verify the client’s identity!
Furthermore, using main mode, or also known as identity protection mode to set up an IPsec based VPN prevents a malicious user from ‘sniffing for valid identities’ as mentioned in the article, with certificate exchange/verification of both the initiator (client) and responder (gateway) making it very difficult for a MITM attack. The identities are made known only after an encrypted session/channel has been established.
VPN Haus 