[squid-users] TeamViewer and other http tunneled connections

Amos Jeffries

2016-02-01 09:44:25 UTC

Post by Markus
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...

Post by Markus
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...

Post by Markus
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.

Post by Markus
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