![]() It will tunnel SSH over your HTTPS proxy, transparently. Using sslh is possible to use the same port for HTTPS, SSH, OpenVPN, XMPP and plain HTTP, all at the same time.Īnother option is corkscrew. No matter what kind of passive inspection you employ, users will avoid it.Ĭonnecting to the site to see if there's a website will not work. If you employ a hard rule on webshells, stunnel and remote access, and really enforce it, your users will be less inclined to poke holes on the wall.īut if you want the more frustrating path, there's some bad news: you cannot do that without interception. You cannot stop users with tech, or infrastructure, or configuration. This is a problem to be solved with policy, not technology. This is especially true in complex networks with a variety of different clients and only few time to manually analyze if a specific uncommon fingerprint should be allowed in general, to a specific target or should be blocked. It can cause false positives and it can fail to detect stunnel instances. To make it clear: this is just heuristics. But the variety of server configurations which are reflected in the TLS stack is much larger than on the client side, so this is probably not as effective as analyzing the ClientHello. Similar passive analysis could be done for the server side.Of course, a client could in theory replicate another clients ClientHello perfectly to hide itself. Nothing new and lots of information can be found about this. ![]() which protocol version, which ciphers are offered in which order, which extensions are used and which order etc. TLS stacks and also applications using TLS often leave a usable fingerprint in the ClientHello, i.e.What could be tried is analyzing the TLS handshake itself: no certs can be installed) and also exclude any kind of traffic pattern analysis there is not much left. Is there really any practical way to stop this, considering that keeping HTTPS working is crucial? We also cannot install software or certs onto user's devices. ![]() My question is - what would be a way to actually detect the usage of stunnel and block it? Let's assume that methods of analysis such as looking at patterns of data ( hmm, a lot of data exchange is unusual over an HTTPS connection, so this SSL tunnel must be used for something else) are unavailable.
0 Comments
Leave a Reply. |