Tom,
> Really? Why is that? VPN seems *less* safe to me, because by default
> it opens up all ports to pass through the tunnel. With SSL you know
> exactly what ports will be forwarded.
With my clientele, the majority of *directed* attacks against their systems
are sociological, rather than cracker attacks. For example:
One of my clients thought is was clever to give all of the employees their
middle names, oddly capitalized, as passwords. This made it very easy for
ex-employees to guess the passwords of current employees, and one of them did
... plus this client frequently failed to cancel the accounts of terminated
employees for up to 3 weeks.
Another client, an attorney, wrote down his "extranet" username and password
on a post-it, and then stuck it to the outside of his laptop, which he took
to court. He therefore shared his login information with everyone in the
courtroom ... including opposing counsel.
In both of those cases, attackers* were able to gain legitimate user names and
passwords. If they log in to an HTTP/SSL system, the web server has no way
to distinguish between a legitimate user and an attacker with a legitimate
password.
A VPN-based system imposes an additional barrier to the sociological attacker
in the form of requiring them to procure and install specialized VPN
software. This barrier can be made additionally impervious by having the IT
department issue keys to the remote client machines rather than relying on
the VPN software's auto generated keys.
However, all of this is a big pain in the keister to administrate, which is
why I've only recommended it to one client, and they decided against the
expense.
(* = when I say "attacker" I'm not talking about someone who wants to crash
the web server. My clients are law and accounting firms; what they are
worried about is unauthorized users gaining access to information which would
compromise their clients. A script kiddie hosing the web server is a
*secondary* concern; it's a lot cheaper to re-build a web server than to
defend a malpractice suit)
--
Josh Berkus
Aglio Database Solutions
San Francisco