RE: L2TP vs. SSTP

[Ken Schaefer]

Inbound inspection is relatively trivial, since there are a limited set of 
possible hosts that external users which to connect to.

External inspection is not so trivial, especially when you have a diverse set 
of users who may, or may not, trust your outbound proxy (e.g. contractors, 
consultants, non-PC devices and so on)

And then, even if you do have inspection, what are you going to do about the 
traffic? Signature based products can help to an extent, but for the average 
enterprise, there are simply too many external hosts to really keep track of if 
you are trying to prevent actual theft or malicious traffic (as opposed to 
trying to stop personal use of Bittorrent)

Technology alone does not solve operational maturity issues, and until there is 
some easier way of providing policy based access to sites (beyond whitelisting 
IPs or similar), then this type of technology isn't going to stop 443 being a 
"firewall bypass port" in most large orgs.

Cheers
Ken

-Original Message-
From: Thomas W Shinder [mailto:[EMAIL PROTECTED]
Sent: Sunday, 3 February 2008 3:16 PM
To: NT System Admin Issues
Subject: RE: L2TP vs. SSTP

Keep in mind that the "universal firewall bypass port" only works when
you can't inspect the connections. Some firewalls can do this inbound
and outbound, in which case, the "bypass port" canard no longer applies.

HTH,
Tom

-Original Message-
From: Ken Schaefer [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 02, 2008 1:59 AM
To: NT System Admin Issues
Subject: RE: L2TP vs. SSTP

Well, listen to the evangelism people from Microsoft (and others), it's
all about protecting the core services now.

The hard edge is going to become increasingly irrelevant for many orgs
(there's the need to federate, contractors, mobile devices, home
workers, outsourcers etc, etc, etc).

We already had the discussion about the universal firewall bypass port
:-)

Cheers
Ken

-Original Message-
From: Micheal Espinola Jr [mailto:[EMAIL PROTECTED]
Sent: Saturday, 2 February 2008 6:03 AM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

I guess I missed the meeting ;-)  - whats the primary device now?

On Jan 31, 2008 10:21 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
>
>
> "Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:
>
>
> > On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > > Firewalls haven't been a primary security device for a few
> > years now
> >
> >   I guess I better take ours down then... ;-)
>
> :)  I didn't say they weren't useful, just said they were no longer a
> primary security device - esp. for outbound...


~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~



~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

More information:

http://blogs.windowsecurity.com/shinder/2008/02/03/tcp-443-the-universal
-firewall-port-not/


Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)

 

> -Original Message-
> From: Thomas W Shinder [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, February 02, 2008 10:16 PM
> To: NT System Admin Issues
> Subject: RE: L2TP vs. SSTP
> 
> Keep in mind that the "universal firewall bypass port" only works when
> you can't inspect the connections. Some firewalls can do this inbound
> and outbound, in which case, the "bypass port" canard no 
> longer applies.
> 
> HTH,
> Tom
> 
> -Original Message-
> From: Ken Schaefer [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, February 02, 2008 1:59 AM
> To: NT System Admin Issues
> Subject: RE: L2TP vs. SSTP
> 
> Well, listen to the evangelism people from Microsoft (and 
> others), it's
> all about protecting the core services now.
> 
> The hard edge is going to become increasingly irrelevant for many orgs
> (there's the need to federate, contractors, mobile devices, home
> workers, outsourcers etc, etc, etc).
> 
> We already had the discussion about the universal firewall bypass port
> :-)
> 
> Cheers
> Ken
> 
> -Original Message-
> From: Micheal Espinola Jr [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 2 February 2008 6:03 AM
> To: NT System Admin Issues
> Subject: Re: L2TP vs. SSTP
> 
> I guess I missed the meeting ;-)  - whats the primary device now?
> 
> On Jan 31, 2008 10:21 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> >
> >
> > "Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:
> >
> >
> > > On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > > > Firewalls haven't been a primary security device for a few
> > > years now
> > >
> > >   I guess I better take ours down then... ;-)
> >
> > :)  I didn't say they weren't useful, just said they were 
> no longer a
> > primary security device - esp. for outbound...
> 
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
> 
> 
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
> 
> 

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

Keep in mind that the "universal firewall bypass port" only works when
you can't inspect the connections. Some firewalls can do this inbound
and outbound, in which case, the "bypass port" canard no longer applies.

HTH,
Tom

-Original Message-
From: Ken Schaefer [mailto:[EMAIL PROTECTED] 
Sent: Saturday, February 02, 2008 1:59 AM
To: NT System Admin Issues
Subject: RE: L2TP vs. SSTP

Well, listen to the evangelism people from Microsoft (and others), it's
all about protecting the core services now.

The hard edge is going to become increasingly irrelevant for many orgs
(there's the need to federate, contractors, mobile devices, home
workers, outsourcers etc, etc, etc).

We already had the discussion about the universal firewall bypass port
:-)

Cheers
Ken

-Original Message-
From: Micheal Espinola Jr [mailto:[EMAIL PROTECTED]
Sent: Saturday, 2 February 2008 6:03 AM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

I guess I missed the meeting ;-)  - whats the primary device now?

On Jan 31, 2008 10:21 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
>
>
> "Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:
>
>
> > On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > > Firewalls haven't been a primary security device for a few
> > years now
> >
> >   I guess I better take ours down then... ;-)
>
> :)  I didn't say they weren't useful, just said they were no longer a
> primary security device - esp. for outbound...


~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~



~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Ken Schaefer]

Well, listen to the evangelism people from Microsoft (and others), it's all 
about protecting the core services now.

The hard edge is going to become increasingly irrelevant for many orgs (there's 
the need to federate, contractors, mobile devices, home workers, outsourcers 
etc, etc, etc).

We already had the discussion about the universal firewall bypass port :-)

Cheers
Ken

-Original Message-
From: Micheal Espinola Jr [mailto:[EMAIL PROTECTED]
Sent: Saturday, 2 February 2008 6:03 AM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

I guess I missed the meeting ;-)  - whats the primary device now?

On Jan 31, 2008 10:21 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
>
>
> "Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:
>
>
> > On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > > Firewalls haven't been a primary security device for a few
> > years now
> >
> >   I guess I better take ours down then... ;-)
>
> :)  I didn't say they weren't useful, just said they were no longer a
> primary security device - esp. for outbound...


~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Eric E Eskam]

"Micheal Espinola Jr" <[EMAIL PROTECTED]> wrote on 02/01/2008 
02:02:39 PM:

> I guess I missed the meeting ;-)  - whats the primary device now?

There isn't one.  Hasn't been for a long time now.  Unfortunately you 
can't always convince some managers of that, even today.  Still looking 
for that solution where they can just pay some money and have the problem 
"go away'.

Then again, I don't suppose I'm telling you anything new...

Eric Eskam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The contents of this message are mine personally and do not reflect any 
position of the U.S. Government
"The human mind treats a new idea the same way the body treats a strange 
protein; it rejects it."
-  P. B. Medawar
~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Micheal Espinola Jr]

I guess I missed the meeting ;-)  - whats the primary device now?

On Jan 31, 2008 10:21 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
>
>
> "Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:
>
>
> > On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > > Firewalls haven't been a primary security device for a few
> > years now
> >
> >   I guess I better take ours down then... ;-)
>
> :)  I didn't say they weren't useful, just said they were no longer a
> primary security device - esp. for outbound...
>
>
>
> Eric Eskam
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> The contents of this message are mine personally and do not reflect any
> position of the U.S. Government
> "The human mind treats a new idea the same way the body treats a strange
> protein; it rejects it."
> -  P. B. Medawar
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-- 
ME2

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

General IT Security musings (was Re: L2TP vs. SSTP)

[Eric E Eskam]

"Kurt Buff" <[EMAIL PROTECTED]> wrote on 01/30/2008 09:17:38 PM:

> If you have subscribed to the Firewall Wizards mailing list over the
> past, oh, 8 or 10 years, you'll note that folks like Marcus Ranum, and
> a whole host of others, have been bitching about this for a long time.

Speaking of Ranum:

http://www.ranum.com/security/computer_security/editorials/dumb/

Smart guy - I'm a fan. Him, Bruce Schneier and a few others - common sense 
security

Eric Eskam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The contents of this message are mine personally and do not reflect any 
position of the U.S. Government
"The human mind treats a new idea the same way the body treats a strange 
protein; it rejects it."
-  P. B. Medawar
~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Eric E Eskam]

"Ben Scott" <[EMAIL PROTECTED]> wrote on 01/31/2008 09:42:14 AM:

> On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> > Firewalls haven't been a primary security device for a few 
> years now
> 
>   I guess I better take ours down then... ;-)

:)  I didn't say they weren't useful, just said they were no longer a 
primary security device - esp. for outbound...

Eric Eskam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The contents of this message are mine personally and do not reflect any 
position of the U.S. Government
"The human mind treats a new idea the same way the body treats a strange 
protein; it rejects it."
-  P. B. Medawar

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 31, 2008 8:51 AM, Eric E Eskam <[EMAIL PROTECTED]> wrote:
> Firewalls haven't been a primary security device for a few years now

  I guess I better take ours down then... ;-)

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Eric E Eskam]

"Carl Houseman" <[EMAIL PROTECTED]> wrote on 01/30/2008 08:30:02 PM:

> One starts to wonder, what's the point of outbound firewall security if
> everybody is bypassing it on port 80 or 443 to do whatever they want? 

Firewalls haven't been a primary security device for a few years now

Eric Eskam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The contents of this message are mine personally and do not reflect any 
position of the U.S. Government
"The human mind treats a new idea the same way the body treats a strange 
protein; it rejects it."
-  P. B. Medawar
~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Kurt Buff]

On 1/30/08, Ben Scott <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 11:10 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> > But the cn value in the presented certificate will not
> > match the FQDN that the client initially connected to.
>
>  Why wouldn't it?  The proxy has the CA key and can make up new
> certificates all day long, each one with the right CN/DN to match what
> the client requested in the HTTP proxy CONNECT method.
>
> -- Ben

After thinking about this for a couple of hours (and without having
looked at documentation at all yet - we're just sitting down
today/tomorrow with the VAR to unbox things, and start the
implementation), I want to qualify my statement a bit.

The Sidewinder *does* show in its configuration an option to examine
SSL traffic. However, I don't know for what purpose, or under what
circumstances.

It's entirely possible that it's only meant as a proxy for a web
server sitting in a DMZ that it's protecting. This is a far less
onerous task, since the cert is under control of the site that runs
the firewall.

However, if someone wants to remind me next week, after I've had a
chance to breathe a moment, I'll be very happy to delve into the docs
and see what I can find.

Kurt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Ken Schaefer]

Ah - OK - I see how this works now.

I suppose I'm glad I have my 3G 5250 WWAN card built into my Dell laptop now :-)

Cheers
Ken

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 3:23 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

On Jan 30, 2008 11:10 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> But the cn value in the presented certificate will not
> match the FQDN that the client initially connected to.

  Why wouldn't it?  The proxy has the CA key and can make up new
certificates all day long, each one with the right CN/DN to match what
the client requested in the HTTP proxy CONNECT method.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

Hi Ben,

You are correct. If you're using an ISA Firewall, you can use
ClearTunnel add on to do this. Who knows, it *might* be included in the
next version of the ISA Firewall.

Tom

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 10:23 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

On Jan 30, 2008 11:10 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> But the cn value in the presented certificate will not
> match the FQDN that the client initially connected to.

  Why wouldn't it?  The proxy has the CA key and can make up new
certificates all day long, each one with the right CN/DN to match what
the client requested in the HTTP proxy CONNECT method.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~



~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

My New Year's resolution is to be civil and only offer useful
information on the list. 

I'm a nice guy nice now :)

Thanks!
Tom

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 8:57 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

On Jan 30, 2008 9:17 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> The only cure is an application proxy that actually understand the
> protocols, and enforces them, and that's nearly unobtainable.

  It's not actually that rare.  It's a Simple Matter of Programming to
confirm that the traffic on TCP/443 actually is SSL.  (As I'm sure Tom
will point out, ISA Server can do this (I believe)).  The real problem
is that SSL, by design and intent, prevents you from looking inside
the secure tunnel.  (If it didn't, it wouldn't be very secure, now
would it?)  You don't know what the SSL tunnel is being used to carry.
 Could be HTTP.  Could be a backdoor to an attacker.

  Default deny with whitelisting of SSL sites is one approach, but
that's an obvious hassle.

  Approaches which explicitly open the payload to trusted inspection
have been proposed.  The idea is, have the client software create an
SSL tunnel to the proxy.  Using a special protocol over that
connection, the client requests an SSL tunnel to the real destination.
 The proxy creates that SSL tunnel.  The client then sends the payload
(without further encryption) over the tunnel to the proxy, which can
inspect it and (if it passes inspection) forward it over its own SSL
tunnel.

  The problem is there are no standards for this (that I'm aware of),
and there are cases which are non-trivial to handle.  (What if the
remote's CA is unknown?  What about client certificates?)  Even if we
get standards, adoption is going to take some time.  There are also
obvious security implications with deliberately defeating the
end-to-end security model.  Presumably one can manage that risk
internally, but it's still an issue.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~



~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 11:10 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> But the cn value in the presented certificate will not
> match the FQDN that the client initially connected to.

  Why wouldn't it?  The proxy has the CA key and can make up new
certificates all day long, each one with the right CN/DN to match what
the client requested in the HTTP proxy CONNECT method.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Ken Schaefer]

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 3:02 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

On Jan 30, 2008 10:38 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
>> I do know of at least one firewall that will decrypt SSL as it
>> passes through ...
>
> Really? How does this work?
>
>  I dunno about what Kurt's talking about, but here's one possible scenario:
>
>  Create your own, locally-hosted CA (Certificate Authority).  Add
> that CA certificate to the trusted certificate list for all your
> clients (web browsers, etc.).  Tell all the clients to use your
> special HTTP proxy server.  Clients connect to the HTTP proxy, issue
> the CONNECT method, and attempts to start SSL over the TCP pipe.  But
> special proxy server didn't really make the TCP connection that was
> asked for -- it instead just waits for the SSL startup and acts as an
> SSL server.  Proxy claims to be the server asked for in the CONNECT.
> Proxy uses its own SSL certificate, which is made-up, but signed by
> the local CA.  Client has been configured to trust that CA, so as far
> as client is concerned, it thinks it has the real destination site.

But the cn value in the presented certificate will not match the FQDN that the 
client initially connected to. So you'd get a name mismatch warning in the 
client browser.

Cheers
Ken



So it sends the HTTP request over the SSL tunnel like it normally
would.  Proxy then opens an SSL client connection to the real
destination, and passes the HTTP requests from the client on.

  I think that would work, at least for the common cases.  It won't
work if the real destination is using client certificates to
authenticate the client.  The proxy doesn't have the client's secret
key and thus can't impersonate the client.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 11:01 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> >  I don't know why any of that should be relevant.
>
> Because the content needs to be inspected, validated and accepted or
> rejected.

  That's if you can peek inside the SSL tunnel.  Just enforcing that
SSL is being used (and not someone shoving their stuff down TCP/443 in
the hopes of finding an open port) is the SMOP.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 10:38 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
>> I do know of at least one firewall that will decrypt SSL as it
>> passes through ...
>
> Really? How does this work?

  I dunno about what Kurt's talking about, but here's one possible scenario:

  Create your own, locally-hosted CA (Certificate Authority).  Add
that CA certificate to the trusted certificate list for all your
clients (web browsers, etc.).  Tell all the clients to use your
special HTTP proxy server.  Clients connect to the HTTP proxy, issue
the CONNECT method, and attempts to start SSL over the TCP pipe.  But
special proxy server didn't really make the TCP connection that was
asked for -- it instead just waits for the SSL startup and acts as an
SSL server.  Proxy claims to be the server asked for in the CONNECT.
Proxy uses its own SSL certificate, which is made-up, but signed by
the local CA.  Client has been configured to trust that CA, so as far
as client is concerned, it thinks it has the real destination site.
So it sends the HTTP request over the SSL tunnel like it normally
would.  Proxy then opens an SSL client connection to the real
destination, and passes the HTTP requests from the client on.

  I think that would work, at least for the common cases.  It won't
work if the real destination is using client certificates to
authenticate the client.  The proxy doesn't have the client's secret
key and thus can't impersonate the client.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Kurt Buff]

On 1/30/08, Ben Scott <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 10:16 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> > Not quite - I don't know of any application proxy that actually
> > does well with all of the verbs, etc., in the HTTP suite, especially
> > when you throw javascript, xml, activeX controls, etc., etc., etc. at
> > it.
>
>  I don't know why any of that should be relevant.

Because the content needs to be inspected, validated and accepted or
rejected. ActiveX controls are mostly just executables, but the rest
could, usually, be considered part of the HTTP protocol suite, in one
sense or another. Even if not part of the protocol suite, it's content
that needs the same scrutiny as anything else.



> > I do know of at least one firewall that will decrypt SSL as it
> > passes through, though, for inspection purposes - of course, that
> > means some tricky work with certs ...
>
>  Hmmm... I'm guessing it has you add a local CA certificate to the
> trusted CA list on all the clients, and then the proxy impersonates
> whatever SSL site the client is requesting?  Wouldn't that break
> client SSL certificates, though?
>
>  Even so, I'm kinda curious -- got a link or product name?

Sidewinder, by Secure Computing.

> > ... you have the underlying protocol that's
> > being tunneled, and if it's not HTTP, then it gets really tricky.
>
>  *Exactly*.  Although, if the goal is just to make sure TCP/443 is
> only being used for HTTP-over-SSL (and not some arbitrary protocol),
> it at least makes that much possible.  Of course, there's still the
> possible use of HTTP as a covert channel.  I think someone has created
> an "IP over HTML" proof-of-concept.
>
> >>   Default deny with whitelisting of SSL sites is one approach, but
> >> that's an obvious hassle.
> >
> > Yes, and I'm nearly ready to go there.
>
>  Wish I could.  Cost/benefit isn't there for us.

Isn't there for me, either, but there are days when I want to do it anyway!

> > I say, let's kill all the users - then we'll have good security, eh? :)
>
>  The DoD still says the best way to secure a classified system is
> with the Air Gap(TM) firewall -- don't connect it to a network and
> you've solved the network attack problem.

Yup, if you have two armed guards, no USB or other ports, etc. Heh.

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Kurt Buff]

On 1/30/08, Ken Schaefer <[EMAIL PROTECTED]> wrote:
> Kurt Buff wrote:
> > You don't know what the SSL tunnel is being used to carry.
> >  Could be HTTP.  Could be a backdoor to an attacker.
>
> SMOP? Not quite - I don't know of any application proxy that actually
> does well with all of the verbs, etc., in the HTTP suite,
>
> Who said that the traffic has to be HTTP? Over SSL/TLS you can send whatever
> you like, and the proxy would not know any different.
>
> And that is the problem - if some wants to do something bad (either an inside
> job, or a malicious outside attacker that comprises your machines through
> malware), they can just use the universal firewall bypass port :-)

See my last comment, below. heh.

> > I do know of at least one firewall that will decrypt SSL as it
> > passes through, though, for inspection purposes - of course, that
> > means some tricky work with certs,
>
> Really? How does this work? SSL/TLS is designed to be resistant to exactly 
> this
> form "inspection", otherwise it would be possible to mount MitM attacks 
> against
> SSL/TLS.

I don't know. I do know that it's one we're installing - cutting over
on Friday, but we didn't pay for that option, nor for the add-in board
that would be useful to go with it.

> > but even assuming that, you have
> > the underlying protocol that's being tunneled, and if it's not HTTP,
> > then it gets really tricky. For instance, how about RPC/HTTPS?
> > Basically, it's MAPI over SSL
>
> No - RPC over HTTPS can be any RPC traffic. You can tunnel ADO over HTTP if
> you want. Or almost any other type of RPC traffic. All that's required is 
> that the
> client library support it.
>
> MAPI is just one client that supports such tunnelling.

I see - well, I suppose that makes it all better then, doesn't it? :)

Kurt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Ken Schaefer]

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 2:53 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

> The DoD still says the best way to secure a classified system is
> with the Air Gap(TM) firewall -- don't connect it to a network and
> you've solved the network attack problem.

I'm sure some enterprising malware writer is working on some kind of software 
that somehow manages to tunnel traffic over even this type of firewall...

Cheers
Ken

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 10:16 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> Not quite - I don't know of any application proxy that actually
> does well with all of the verbs, etc., in the HTTP suite, especially
> when you throw javascript, xml, activeX controls, etc., etc., etc. at
> it.

  I don't know why any of that should be relevant.  When SSL is
tunneled over an HTTP proxy, the client makes the regular connection
to the proxy server, and then submits a CONNECT method.  The proxy
then opens the TCP connection to the specified destination, and gets
out of the way.  The client then starts SSL like it opened the TCP
connection that way from the start.  Everything else is part of the
SSL payload, and thus encrypted.  The proxy can't see any of it, so it
can't screw it up, either.

  The SSL verification just means the proxy watches what is sent over
the TCP connection to make sure it looks like an SSL session setup,
and drops the connection if it isn't.

> I do know of at least one firewall that will decrypt SSL as it
> passes through, though, for inspection purposes - of course, that
> means some tricky work with certs ...

  Hmmm... I'm guessing it has you add a local CA certificate to the
trusted CA list on all the clients, and then the proxy impersonates
whatever SSL site the client is requesting?  Wouldn't that break
client SSL certificates, though?

  Even so, I'm kinda curious -- got a link or product name?

> ... you have the underlying protocol that's
> being tunneled, and if it's not HTTP, then it gets really tricky.

  *Exactly*.  Although, if the goal is just to make sure TCP/443 is
only being used for HTTP-over-SSL (and not some arbitrary protocol),
it at least makes that much possible.  Of course, there's still the
possible use of HTTP as a covert channel.  I think someone has created
an "IP over HTML" proof-of-concept.

>>   Default deny with whitelisting of SSL sites is one approach, but
>> that's an obvious hassle.
>
> Yes, and I'm nearly ready to go there.

  Wish I could.  Cost/benefit isn't there for us.

> I say, let's kill all the users - then we'll have good security, eh? :)

  The DoD still says the best way to secure a classified system is
with the Air Gap(TM) firewall -- don't connect it to a network and
you've solved the network attack problem.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Ken Schaefer]

-Original Message-
From: Kurt Buff [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 2:17 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

> You don't know what the SSL tunnel is being used to carry.
>  Could be HTTP.  Could be a backdoor to an attacker.

SMOP? Not quite - I don't know of any application proxy that actually
does well with all of the verbs, etc., in the HTTP suite,

Who said that the traffic has to be HTTP? Over SSL/TLS you can send whatever 
you like, and the proxy would not know any different.

And that is the problem - if some wants to do something bad (either an inside 
job, or a malicious outside attacker that comprises your machines through 
malware), they can just use the universal firewall bypass port :-)


> I do know of at least one firewall that will decrypt SSL as it
> passes through, though, for inspection purposes - of course, that
> means some tricky work with certs,

Really? How does this work? SSL/TLS is designed to be resistant to exactly this 
form "inspection", otherwise it would be possible to mount MitM attacks against 
SSL/TLS.

> but even assuming that, you have
> the underlying protocol that's being tunneled, and if it's not HTTP,
> then it gets really tricky. For instance, how about RPC/HTTPS?
> Basically, it's MAPI over SSL

No - RPC over HTTPS can be any RPC traffic. You can tunnel ADO over HTTP if you 
want. Or almost any other type of RPC traffic. All that's required is that the 
client library support it.

MAPI is just one client that supports such tunnelling.

Cheers
Ken

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 10:02 PM, Ken Schaefer <[EMAIL PROTECTED]> wrote:
>> > It's not actually that rare.
>
> ... everything that wants to tunnel over 443 will use SSL/TLS ...

  Yah, that's why I wrote "You don't know what the SSL tunnel is being
used to carry" immediately after that.  ;-)

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Kurt Buff]

On Jan 30, 2008 6:56 PM, Ben Scott <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 9:17 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> > The only cure is an application proxy that actually understand the
> > protocols, and enforces them, and that's nearly unobtainable.
>
>   It's not actually that rare.  It's a Simple Matter of Programming to
> confirm that the traffic on TCP/443 actually is SSL.  (As I'm sure Tom
> will point out, ISA Server can do this (I believe)).  The real problem
> is that SSL, by design and intent, prevents you from looking inside
> the secure tunnel.  (If it didn't, it wouldn't be very secure, now
> would it?)  You don't know what the SSL tunnel is being used to carry.
>  Could be HTTP.  Could be a backdoor to an attacker.

SMOP? Not quite - I don't know of any application proxy that actually
does well with all of the verbs, etc., in the HTTP suite, especially
when you throw javascript, xml, activeX controls, etc., etc., etc. at
it. I do know of at least one firewall that will decrypt SSL as it
passes through, though, for inspection purposes - of course, that
means some tricky work with certs, but even assuming that, you have
the underlying protocol that's being tunneled, and if it's not HTTP,
then it gets really tricky. For instance, how about RPC/HTTPS?
Basically, it's MAPI over SSL - know any good application layer
proxies for that, which will robustly interpret and enforce correct
semantics for that protocol? I'll bet even ISA won't do what we really
want it to do for enforcement of MAPI over SSL.

>   Default deny with whitelisting of SSL sites is one approach, but
> that's an obvious hassle.

Yes, and I'm nearly ready to go there.

>   Approaches which explicitly open the payload to trusted inspection
> have been proposed.  The idea is, have the client software create an
> SSL tunnel to the proxy.  Using a special protocol over that
> connection, the client requests an SSL tunnel to the real destination.
>  The proxy creates that SSL tunnel.  The client then sends the payload
> (without further encryption) over the tunnel to the proxy, which can
> inspect it and (if it passes inspection) forward it over its own SSL
> tunnel.

Special protocol - ye gods, another one? Will it have its BNF diagram
ready to go?

>   The problem is there are no standards for this (that I'm aware of),
> and there are cases which are non-trivial to handle.  (What if the
> remote's CA is unknown?  What about client certificates?)  Even if we
> get standards, adoption is going to take some time.  There are also
> obvious security implications with deliberately defeating the
> end-to-end security model.  Presumably one can manage that risk
> internally, but it's still an issue.
>
> -- Ben

I say, let's kill all the users - then we'll have good security, eh? :)

Or maybe just the programmers. Or protocol designers, or ...  :):)

It's terribly frustrating.

Kurt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

RE: L2TP vs. SSTP

[Ken Schaefer]

-Original Message-
From: Ben Scott [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 1:57 PM
To: NT System Admin Issues
Subject: Re: L2TP vs. SSTP

On Jan 30, 2008 9:17 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
>> The only cure is an application proxy that actually understand the
>> protocols, and enforces them, and that's nearly unobtainable.
>
> It's not actually that rare.  It's a Simple Matter of Programming to
> confirm that the traffic on TCP/443 actually is SSL.

I'm pretty sure just about any decent proxy will do this.

But because it's so trivial to implement TLS/SSL support, just about everything 
that wants to tunnel over 443 will use SSL/TLS, and I think that's what Kurt 
was getting at.

Once the traffic is actually secured using SSL/TLS there really isn't any way, 
at the moment, to work out what is inside that channel. SSL/TLS is designed to 
be resistant to "man-in-the-middle" attacks, so unless the client co-operates, 
you can't look inside the traffic. And when you have 
outsiders/contractors/consultants/etc on your network, you need to find 
alternate ways of protecting your assets - separate networks, or Rights 
Management or whatever.

Cheers
Ken

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

Re: L2TP vs. SSTP

[Ben Scott]

On Jan 30, 2008 9:17 PM, Kurt Buff <[EMAIL PROTECTED]> wrote:
> The only cure is an application proxy that actually understand the
> protocols, and enforces them, and that's nearly unobtainable.

  It's not actually that rare.  It's a Simple Matter of Programming to
confirm that the traffic on TCP/443 actually is SSL.  (As I'm sure Tom
will point out, ISA Server can do this (I believe)).  The real problem
is that SSL, by design and intent, prevents you from looking inside
the secure tunnel.  (If it didn't, it wouldn't be very secure, now
would it?)  You don't know what the SSL tunnel is being used to carry.
 Could be HTTP.  Could be a backdoor to an attacker.

  Default deny with whitelisting of SSL sites is one approach, but
that's an obvious hassle.

  Approaches which explicitly open the payload to trusted inspection
have been proposed.  The idea is, have the client software create an
SSL tunnel to the proxy.  Using a special protocol over that
connection, the client requests an SSL tunnel to the real destination.
 The proxy creates that SSL tunnel.  The client then sends the payload
(without further encryption) over the tunnel to the proxy, which can
inspect it and (if it passes inspection) forward it over its own SSL
tunnel.

  The problem is there are no standards for this (that I'm aware of),
and there are cases which are non-trivial to handle.  (What if the
remote's CA is unknown?  What about client certificates?)  Even if we
get standards, adoption is going to take some time.  There are also
obvious security implications with deliberately defeating the
end-to-end security model.  Presumably one can manage that risk
internally, but it's still an issue.

-- Ben

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~

Re: L2TP vs. SSTP

[Kurt Buff]

This is not a new thought, you know.

If you have subscribed to the Firewall Wizards mailing list over the
past, oh, 8 or 10 years, you'll note that folks like Marcus Ranum, and
a whole host of others, have been bitching about this for a long time.

The only cure is an application proxy that actually understand the
protocols, and enforces them, and that's nearly unobtainable.

It's now down to defense in depth, and protecting every asset on the
network, if you can get away with it. Default deny and least privilege
rule. Wish I could actually implement that at $EMPLOYER as I would
prefer, though we *are* moving in that direction - just too slowly for
my taste.

Kurt

On Jan 30, 2008 5:30 PM, Carl Houseman <[EMAIL PROTECTED]> wrote:
> One starts to wonder, what's the point of outbound firewall security if
> everybody is bypassing it on port 80 or 443 to do whatever they want?
>
> Carl
>
> -Original Message-
> From: Ken Schaefer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 30, 2008 8:26 PM
> To: NT System Admin Issues
>
> Subject: RE: L2TP vs. SSTP
>
> One operates at the IP layer
> One operates at the TCP layer
>
> Both use certificates for authentication and encryption.
>
> But I suppose that SSL VPN products are popular now because port 443 is seen
> as the "universal firewall bypass" port, and so setting up SSTP (or similar
> SSL VPN product) and having roaming clients be able to access your server
> maybe the easiest to do.
>
> Cheers
> Ken
>
> -Original Message-
> From: Jim Dandy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 31 January 2008 12:22 PM
> To: NT System Admin Issues
> Subject: L2TP vs. SSTP
>
> Windows Server 2008 is supposed to come out with Secure Socket Tunneling
> Protocol (SSTP).  Does anyone know the advantages/disadvantages of using
> this verses L2TP?  Thanks for your help.
>
> Curt
>
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
>
>
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
>

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

Hi Carl,

You can control outbound access if you're using a proxy based or
integrated stateful packet inspection and proxy based firewall. That's a
nice thing about the ISA Firewall. The CONNECT request sent by the SSTP
client has a special HTTP header called SSTPVERSION. The value for this
header is 1.0. You can use your Web proxy configuration (like an ISA
Firewall's HTTP Security Filter) to block it. In contrast, if you're not
using a Web proxy enabled firewall, then you're right -- everyone can
bypass your security controls on the SSTP VPN outbound.

HTH,
Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)

 

> -Original Message-
> From: Carl Houseman [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 30, 2008 7:30 PM
> To: NT System Admin Issues
> Subject: RE: L2TP vs. SSTP
> 
> One starts to wonder, what's the point of outbound firewall 
> security if
> everybody is bypassing it on port 80 or 443 to do whatever they want? 
> 
> Carl
> 
> -Original Message-
> From: Ken Schaefer [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 30, 2008 8:26 PM
> To: NT System Admin Issues
> Subject: RE: L2TP vs. SSTP
> 
> One operates at the IP layer
> One operates at the TCP layer
> 
> Both use certificates for authentication and encryption.
> 
> But I suppose that SSL VPN products are popular now because 
> port 443 is seen
> as the "universal firewall bypass" port, and so setting up 
> SSTP (or similar
> SSL VPN product) and having roaming clients be able to access 
> your server
> maybe the easiest to do.
> 
> Cheers
> Ken
> 
> -Original Message-
> From: Jim Dandy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 31 January 2008 12:22 PM
> To: NT System Admin Issues
> Subject: L2TP vs. SSTP
> 
> Windows Server 2008 is supposed to come out with Secure 
> Socket Tunneling
> Protocol (SSTP).  Does anyone know the 
> advantages/disadvantages of using
> this verses L2TP?  Thanks for your help.
> 
> Curt
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
> 
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
> 
> 

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Thomas W Shinder]

Hi Jim,

Check out my article series on this topic:

http://www.windowsecurity.com/articles/Configuring-Windows-Server-2008-R
emote-Access-SSL-VPN-Server-Part1.html

http://www.windowsecurity.com/articles/Configuring-Windows-Server-2008-R
emote-Access-SSL-VPN-Server-Part2.html

The first article provides the rationale for using SSTP and provides
information about how the protocol works and packet structure.

The second article is the beginning of the step by step configuration
procedure.

SSTP's major advantage is that it works through firewalls that block
L2TP/IPSec and PPTP. Since the SSTP is essentially PPP/SSL, so there's
an HTTP header that capsulates the payload. Why is this good? Because it
enables SSTP to work through both stateful packet inspection firewalls
AND Web Proxy devices. 

I've been really impressed with the work that the RRAS group has done
with this protocol and if you want to find even more information on it,
check out the RRAS blog at http://blogs.technet.com/rrasblog/

HTH,
Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)

 

> -Original Message-
> From: Jim Dandy [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 30, 2008 7:22 PM
> To: NT System Admin Issues
> Subject: L2TP vs. SSTP
> 
> Windows Server 2008 is supposed to come out with Secure 
> Socket Tunneling
> Protocol (SSTP).  Does anyone know the 
> advantages/disadvantages of using
> this verses L2TP?  Thanks for your help.
> 
> Curt
> 
> ~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
> ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~
> 
> 

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Carl Houseman]

One starts to wonder, what's the point of outbound firewall security if
everybody is bypassing it on port 80 or 443 to do whatever they want? 

Carl

-Original Message-
From: Ken Schaefer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 8:26 PM
To: NT System Admin Issues
Subject: RE: L2TP vs. SSTP

One operates at the IP layer
One operates at the TCP layer

Both use certificates for authentication and encryption.

But I suppose that SSL VPN products are popular now because port 443 is seen
as the "universal firewall bypass" port, and so setting up SSTP (or similar
SSL VPN product) and having roaming clients be able to access your server
maybe the easiest to do.

Cheers
Ken

-Original Message-
From: Jim Dandy [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 12:22 PM
To: NT System Admin Issues
Subject: L2TP vs. SSTP

Windows Server 2008 is supposed to come out with Secure Socket Tunneling
Protocol (SSTP).  Does anyone know the advantages/disadvantages of using
this verses L2TP?  Thanks for your help.

Curt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~


~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

RE: L2TP vs. SSTP

[Ken Schaefer]

One operates at the IP layer
One operates at the TCP layer

Both use certificates for authentication and encryption.

But I suppose that SSL VPN products are popular now because port 443 is seen as 
the "universal firewall bypass" port, and so setting up SSTP (or similar SSL 
VPN product) and having roaming clients be able to access your server maybe the 
easiest to do.

Cheers
Ken

-Original Message-
From: Jim Dandy [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 January 2008 12:22 PM
To: NT System Admin Issues
Subject: L2TP vs. SSTP

Windows Server 2008 is supposed to come out with Secure Socket Tunneling
Protocol (SSTP).  Does anyone know the advantages/disadvantages of using
this verses L2TP?  Thanks for your help.

Curt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm>  ~

L2TP vs. SSTP

[Jim Dandy]

Windows Server 2008 is supposed to come out with Secure Socket Tunneling
Protocol (SSTP).  Does anyone know the advantages/disadvantages of using
this verses L2TP?  Thanks for your help.

Curt

~ Upgrade to Next Generation Antispam/Antivirus with Ninja!~
~   ~