Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I always used the simple trick to bypass most firewalls which prevented me from using any ports. I simply opened ssh on one of my servers on port 443 and tunneled all traffic through there.

However I am now on a network which got firewall that I never saw in before and I didn't even know it's possible.

On this network you can use 443 port only for legitimate webserver traffic. If I open ssh, or anything else on port 443 and try to connect there from this network, it gets killed immediately. If I start apache on that server, it works.

How is this even possible? Are there some super sophisticated firewalls that are even able to analyze encrypted traffic to verify it is legitimate https traffic? How?

share|improve this question
4  
Its called SPI, higher end equipment can do more advanced inspection and terminate unwanted connections. – Linef4ult Jan 11 at 12:15
    
You could create a whitelist and only allow that traffic the problem is that legitimate webserver traffic is subject to change in that, ip addresses can reassigned, so what might be Microsoft today might be Google tomorrow. You are better off using a secure tunnel to communicate with your servers, and creating a whitelist of clients that are allowed, then determine the procedure to add additional clients int he future (because that list will change). – Ramhound Jan 11 at 12:56
    
You could use e.g. Obfsproxy to obfuscate the SSH traffic as harmless HTTP(S) traffic. – Michael Jan 11 at 19:37

Yes, and they don't need any magic here, just trivial matching on the TCP packet contents. Even though SSH and TLS (SSL) encrypt their payloads, the protocol headers themselves are still distinguishable and very different from each other. For example, a SSHv2 connection always starts with the client sending SSH-2.0-(client name and version). Similarly, even though your firewall cannot really know whether the TLS connection carries HTTP inside, it can recognize TLS itself.

Such inspecting of layers above TCP generally falls under "Deep Packet Inspection", a relatively common feature.

One obvious way to bypass this is to tunnel SSH inside TLS – for example, using stunnel, haproxy, or sniproxy. (In addition to plain tunneling, where port 443 is dedicated to SSH-over-TLS, they can also multiplex SSH / HTTP / other protocols over the same port based on SNI and ALPN.)

While this wouldn't always defeat really sophisticated traffic analysis, it would still bypass most filters which merely check "does this look like a TLS header".


And then there's the annoying kind of firewalls – the ones which intercept TLS to decrypt and re-encrypt all traffic. These can actually see inside TLS, and can pass HTTP requests while blocking everything else. (Note that some antivirus programs also do the same thing.) You can recognize this kind by looking at the server certificates; all proxy-generated certificates look the same, and often don't pass validation, while real certificates are issued by various different CAs.

share|improve this answer
1  
So SSH does its own, application-level security, rather than being just another protocol over TLS (which by default, it doesn't use)? – Medinoc Jan 11 at 16:09
2  
@Medinoc: Yes, it implements similar features (in the SSHv2 "transport" and "authentication" layers) and doesn't need TLS for anything. – grawity Jan 11 at 16:26
    
Is there any reliable way to recognize these sniffing firewalls? I don't like the idea that someone intercept my passwords while using https. I didn't even know it's possible until now. – Petr Jan 11 at 17:24
2  
POST / HTTP/1.0 base64garbage HTTP/200 200 OK base64garbage makes a transport protocol – Joshua Jan 11 at 18:51
3  
@Petr Extending grawity's remarks, if it's an employer owned computer the certs were probably installed before they gave it to you; and the MITM firewall will be configured so that if you're not using their cert no https traffic will be allowed so your choices are comply with policy or have no https. OTOH in that case checking the cert will probably say something like "verified by Employer Name" and something similar in the CA name if you drill deeper. eg on my work computer it's bluecoat.companyname.com (where bluecoat is the brand of the firewall being used). – Dan Neely Jan 11 at 21:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.