[EMAIL PROTECTED]
To: Tim [EMAIL PROTECTED]
CC: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] SSL VPNs and security
Date: Tue, 13 Jun 2006 15:13:45 +1000
SSL VPNs have their legitimate place as does IPSec. Personally, I'd rather
that travelling exec's who need to log on from a public
Sure traffic can be filtered, but the point is that the layer 7 connection is terminated at the network perimiter rather than the internatl network which is typically much less protected.
On 6/14/06, Ray P [EMAIL PROTECTED] wrote:
Why do I keep reading that IPSec provides full network
SSL VPNs have their legitimate place as does IPSec. Personally, I'd rather that travelling exec's who need to log on from a public Internet terminal, dont have full IP connectivity into the network, but maybe that's just me.
Q-BallOn 6/10/06, Tim [EMAIL PROTECTED] wrote:
That depends on whether
Hello MZ,
I think SSL VPNs are a pretty lame idea in the first place, but for the
specific problem you bring up, would the following design work around
this?
Set up a wildcard record, *.webvpn.example.org, pointing to the device.
The device then maps all internal domain names or IP addresses to
On 6/9/06, Tim [EMAIL PROTECTED] wrote:
Set up a wildcard record, *.webvpn.example.org, pointing to the device.
The device then maps all internal domain names or IP addresses to a
unique hostname, such as: internalhost.webvpn.example.org, or
192-168-0-1.webvpn.example.org, etc.
Wouldn't this
Set up a wildcard record, *.webvpn.example.org, pointing to the device.
The device then maps all internal domain names or IP addresses to a
unique hostname, such as: internalhost.webvpn.example.org, or
192-168-0-1.webvpn.example.org, etc.
This has the side effect of making procurement of the
That depends on whether the solution tries to solve single-sign-on
problems as well. If the vendor is trying to handle SSO in such an
environment, then they are probably using domain cookies. The
problems are exactly the same as the ones Michal listed, plus some
additional ones specific to
Set up a wildcard record, *.webvpn.example.org, pointing to the device.
The device then maps all internal domain names or IP addresses to a
unique hostname, such as: internalhost.webvpn.example.org, or
192-168-0-1.webvpn.example.org, etc.
This has the side effect of making procurement of
SSL certificates are free. You just have to have enough knowledge to
distribute your own CA certificate. For a VPN appliance, this should
not be a problem at all, since only your trusted users should be
accessing it. Even if you aren't competent enough to figure out how to
distribute your own
Sure, it's trivial to create self-signed certs (or run a CA), but
distributing your cert (or the CA cert) to all but a handful of clients
is a logistical nightmare.
For company managed laptops, it is trivial to distribute via normal
software distribution processes. For non-managed systems
On 6/9/06, Tim [EMAIL PROTECTED] wrote:
For non-managed systems (which you
shouldn't allow into your network via a VPN anyway), installing a CA
cert is as simple as clicking on a link ONCE, and installing the cert.
This cert can be distributed over a VeriSign secured SSL connection.
Are you
Are you referring to telling end-users to click Accept this
certificate permanently box on the certificate warning pop-up? Or is
there a software package out there that can do this without the
warning pop-up?
In Windoze, if you have a .cer file, and did the use fields correctly
when you
Web VPN or SSL VPN is a term used to denote methods for accessing
company's internal applications with a bare WWW browser, with the use of
browser-based SSO authentication and SSL tunneling. As opposed to IPSec,
no additional software or configuration is required, and hence, corporate
users can
13 matches
Mail list logo
