[squid-users] TeamViewer and other http tunneled connections

[Amos Jeffries]

On 1/02/2016 9:56 p.m., Markus wrote:
> I've got a Squid server (v. 3.5.x) configured that way, that only some
> "banking sites" are allowed to be tunneled (spliced) - the rest of SSL
> sites are bumped.
> That works OK. I thought that it prevents me from illegal
> tunneling-out by users. However recently I've realized that TeamViewer
> is still able  to establish connection over my Squid.
> Moreover user's PC are totally blocked on my firewall - they only have
> access to the web via Squid-proxy (their browsers are proxy aware).
> 
> Of course I can block out teamviewer.com domain by ACL - and that
> works. But I'm wondering if there is any way to prevent such
> tunnel-connection in future. (I mean another -  mainly malicious
> software)
> 
> I've captured some details using Etherreal and it looks like
> Teamviewer app does a normal http GET request to the TeamViewer's ASP
> script
> http://master13.teamviewer.com/din.aspx?s=00000000&id=0&client=DynGate&rnd=144452645&p=10000001
> 
> TeamViewer's server response is an application/octet-stream , but it
> contains an ID which is presumably used later in client's POST
> request.
> 
> See: http://dev.3d.pl/tmp/teamv.png  (screenshot from Ethereal) and
> TCP the stream http://dev.3d.pl/tmp/teamv.txt
> 
> My question is - does the TeamViewer tunnel traffic differ in any way
> from normal http binary content transmission (eg. youtube or radio
> streaming) ?

"Maybe". Both of the examples you mention are applications that use both
HTTP(S)/ICY streaming, and non-HTTP(S) streaming protocols depending on
which works.

If TeamViewer traffic is taking the form of HTTP(S) messages, then
SSL-Bump has nothing to do with it. They are HTTP(S) messages.

If TeamViewer is using non-HTTP protocol over TLS after the initial
HTTP(S) setup, then...


> 
> Can we somehow detect that this kind of transmission is probably a
> tunnel traffic?

What Squid can determine is whether the TLS tunneled protocol is one
that it can proxy (HTTP, ICY, FTP). Squid-3 versions all have a single
explicit action that they do, which varies from auto-deny to auto-allow
depending on the version. You need Squid-4 to control it...

> 
> Sorry if my post is a bit chaotic, but I'm kinda confused now , how it works.
> 
> Please note - I'm not talking only about TeamViewer itself but in
> general about HTTP-tunneled traffic.  Maybe an ICAP server could be
> useful here? but how do I know what to look for? (how should
> ACLs/rules look like)

ICAP services cannot handle non-HTTP message types, and Squid does even
attempt to pass CONNECT messages to them IIRC.

> 
> or you want to tell me, that the only possible way is continuous
> observation what's new "on market" and adding new rules?

Squid-3.x depend on http_access rules managing the CONNECT requests that
Squid synthesizes for new client connections. The info on that is
limited to raw-IP:port or perhapse SNI:port, depending on version and
what ssl-bump processing as been done so far in the transaction.


Squid-4 also has the on_unsupported_protocol directive - which takes
effect at the point Squid attempts to decrypt the TLS traffic. At that
point Squid discovers if the traffic is HTTP/ICY or not. You can use
ACLs with that to whitelist non-HTTP TLS services you want tunneled
through Squid, but send an error for everything else.
The HTTP(S), ICY or FTP services are controlled as normal through
http_access.

Amos