Subject: Re: [saag] Comments: SAAG SSL-VPN Preso

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Aug 2008 04:24:12 -0700

At 6:37 AM -0700 7/31/08, Gregory M. Lebovitz wrote:
>2 - there are (at least) three types of TLS-VPN functional modes. 
>Paul listed 2, web-proxy-rewriter and full network access. The 3rd 
>is a per-application forwarding and protection. This type is 
>different from the other two in that one or more specific 
>application types (e.g. MAPI, CIFS, HTTP, etc.) can be made to be 
>forwarded off the client through the TLS tunnel, while no other 
>traffic would pass through the VPN.

Per-application forwarding is a sub-type of full network access. That 
is, it requires a shim be pushed to the user for the application to 
be tunneled through. It is just a matter of the VPN policy whether 
everything to the corporate network goes through the tunnel, just 
some of the traffic bound for the corportation goes through the 
tunnel, or everything coming off of the remote computer goes through 
the tunnel.

>3 - Paul referred to an issue of a "Silent gateway-in-the-middle 
>attack" that is a security consideration/weakness of the TLS-VPNs. 
>Users of these products (and they are many, the majority now) might 
>find this characterization contrary to their perspective. The 
>entities that operate TLS-VPNs use them precisely to be able to know 
>and control what is and isn't going in and out of their networks. 
>They see these HTTPS forward-proxy-like features as a wonderful 
>enforcement tool of their entity's security policy for maintaining 
>their networks and securing/control their data.

Fully agree. I called it an "attack" because, from the normal IETF 
security perspective, it is one. From the customer's perspective, it 
is the only way to enforce policy. The latter trumps the former.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 04 Aug 2008 15:27:50 +0100

See below.

    Yaron

Paul Hoffman wrote:

>> Paul listed 2, web-proxy-rewriter and full network access. The 3rd is 
>> a per-application forwarding and protection. This type is different 
>> from the other two in that one or more specific application types 
>> (e.g. MAPI, CIFS, HTTP, etc.) can be made to be forwarded off the 
>> client through the TLS tunnel, while no other traffic would pass 
>> through the VPN.
>
> is, it requires a shim be pushed to the user for the application to be 
> tunneled through. It is just a matter of the VPN policy whether 
> everything to the corporate network goes through the tunnel, just some 
> of the traffic bound for the corportation goes through the tunnel, or 
> everything coming off of the remote computer goes through the tunnel.
>
This is true in theory, but not in practice. Full network access VPNs 
are rather OS-intrusive (require the installation of network adaptors). 
Per-app forwarding often requires much less infrastructure and thus can 
be deployed as OS "hooks", with lower end-user privileges.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Aug 2008 08:49:08 -0700

At 3:27 PM +0100 8/4/08, Yaron Sheffer wrote:
>>Per-application forwarding is a sub-type of full network access. 
>>That is, it requires a shim be pushed to the user for the 
>>application to be tunneled through. It is just a matter of the VPN 
>>policy whether everything to the corporate network goes through the 
>>tunnel, just some of the traffic bound for the corportation goes 
>>through the tunnel, or everything coming off of the remote computer 
>>goes through the tunnel.
>>
>This is true in theory, but not in practice. Full network access 
>VPNs are rather OS-intrusive (require the installation of network 
>adaptors). Per-app forwarding often requires much less 
>infrastructure and thus can be deployed as OS "hooks", with lower 
>end-user privileges.

Probably true. I was talking about from a VPN administrator's or 
user's perspective, not from a developer's perspective. Going back to 
Gregory's first point, we will do better talking in their terms 
instead of our own because then what we say can be used by them in 
their day-to-day work.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Aug 2008 23:30:00 +0300

> infrastructure and thus can be deployed as OS "hooks", with lower  

That really says that we've found a way to run the per-application  
version without administrator privileges and without scary operating  
system pop-ups for the user.

To me that sounds like a hole that everybody's waiting for Microsoft  
to patch. But then that's what I think about full network access as  
well.

---

From: Richard Basch <[email-masked]>
Date: Tue, 05 Aug 2008 08:44:29 -0400

> is the only way to enforce policy. The latter trumps the former.

I guess my view of whether it constitutes an "attack" depends on the
ownership & control rights of the assets in question. If it is a corporate
resource, a corporate operator of a TLS-VPN may be imposing security
policies in-line, and while a user (employee) of a corporate resource may
not appreciate such, it is hard to argue that such policy enforcement
constitutes an attack on the resource.  Of course, a user who may be using a
personal resource may have a legitimate complaint about external entities
imposing security policies on their personal resource, if there was no other
agreement (i.e. employment contract stipulating that the user will comply
with corporate security policies, etc.)

I am not a lawyer, but it seems to me that an attack between two parties
engaged in a collaborative partnership can only be measured by property
rights (whether it be intellectual or tangible property rights).

In the first example where an employee is using a corporate resource, it
could be construed as an attack on the legal entity, known as a corporation,
to have the user be able to violate the corporate entity's policies and
rights.

Perhaps I misinterpreted the form of attack to which Paul alluded.

Sincerely,
Richard Basch

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Aug 2008 06:27:54 -0700

>Perhaps I misinterpreted the form of attack to which Paul alluded.

The "attack" is that neither the remote access user nor the HTTPS 
server inside the corporate network agreed to having the tunnel be 
terminated and restarted. Both can see that it is happening (well, 
the user can see it if he's careful), but neither agreed to it. SSL 
VPNs explicitly try to make the remote access user "feel" like they 
are connecting to the internal resources, and they explicitly try to 
make the internal resource act as if there is a local user connecting 
to them. It is a nudge-nudge-wink-wink two-way spoofing that is 
visible.

Fortunately, it doesn't matter. As you say, the corporation gets to 
make the security policy. In this case, there are two linked 
policies: "some SSL tunnels that were meant for an internal resource 
stop at the SSL VPN gateway instead of at the resource" and "the SSL 
VPN gateway can emulate a remote access user to internal HTTPS 
resources".

--Paul Hoffman, Director
--VPN Consortium