Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
Sign up to join this community
There are firewalls out there that analyze the traffic that goes through and block it if it is not wanted. How good do these firewalls work with encrypted traffic, e.g. HTTPS or IMAP over SSL?
An example: Can a firewall distinguish between HTTPS traffic on port 443 and, lets say, secured Remote Desktop traffic over 443?
In your specific example, yes it is possible.
HTTPS starts a TLS session with the remote.
TLSv1 Client Hello
Secure RDP starts an RDP session that negotiates a TLS secured connection between the two ends of the session.
X.224 Connection Request (0xe0)
Because the session-start protocols are different, a stateful firewall should be able to discriminate between an HTTPS connection starting up and something else.
For the generic case, a Firewall won't be able to detect something like SSH-over-HTTPS since the SSH traffic is hidden inside the HTTPS traffic. The only way it could detect it is through heuristic analysis of the traffic patterns, but I don't know of anything that does that.
For IMAP, there are two modes of securing it. One is via SSL, another is via TLS. The SSL method looks just like an HTTPS connection just on a different port, and if the remote port is the same then there isn't much it can do about it. TLS, on the other hand, is negotiated between both ends of the conversation so the session-startup is markedly different and easily detected.
The key thing to keep in mind is that SSL creates a TCP wrapper through which traffic is passed. Many protocols include a method of negotiated security inside the protocol itself that leverages much the same technologies the wrapper uses, but uses a different session startup method which makes it differentiable.
Some firewall/proxy products can perform an “authorized man-in-the-middle attack” on TLS connections; e.g., Squid calls this feature “SSL Bump”. A proxy server which does this will have full access to the plaintext data transmitted inside the TLS session. However, a client behind such a proxy will get a different server certificate (provided by the proxy itself instead of the real server), which will cause TLS errors or warnings unless the client is configured to expect such certificates (by adding the proxy CA certificate to the list of trusted root certificates).
