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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
