* Encapsulating IPSec inside SSL
Once in a while, you come across a seemingly preposterous idea that, on further investigation, makes a lot of sense. This was certainly the case with one demo at Nortel’s Enterprise Industry Analysts Conference.
Nortel demonstrated a way to use Nortel data/security gear to establish an SSL session and then to run IPSec inside the SSL session to a given application, such as a corporate VPN. And while this tunnel-in-a-tunnel process seems like something from the Department of Redundancy Department, it actually makes sense in at least two scenarios.
The first is support for road warriors who may be visiting another company that offers guests Internet access. While many companies will offer visitors generic and benign access – like Web access, many also block the more commonly used ports for IPSec at the corporate firewall for security reasons. Consequently, you might be able to get to the Internet, but it’s impossible to connect to your external IPSec-based VPN.
In this case, you first connect to the internal corporate network by opening up an SSL session. Then, inside the SSL session, you open up your IPSec connection to the internal network. This traffic gets through the firewall because the SSL session is encrypting the contents – which happen to be the IPSec session.
The second scenario is much more applicable to the SOHO market. High-speed access at home is becoming a given for many knowledge workers. However, the ISPs are increasingly blocking IPSec traffic since IPSec is seldom – if ever – needed for generic home communications. Instead, they are forcing users to buy a “business class” DSL or cable service in order to have IPSec traffic unblocked. Whether this policy is “fair” can be argued in either direction, and we’ll not comment on that at this time.
In this scenario, the at-home worker similarly connects to the corporate net via SSL using a consumer-grade service, and then opens up the IPSec connection inside the SSL session.
