co
The 8e6 R3000 filter inspects HTTPS traffic to extent that is possible with SSL encryption hiding what's going on with encapsulated HTTP traffic. If you use Wireshark and watch setup of SSL-enabled browser session, the fact it's HTTP encapsulated inside SSL/TLS tunnel is not viewable (ie. the tunneled protocol could be anything inside the SSL/TLS session).
See Wireshark packet capture below -- such is life with SSL (and any protcol that uses it... HTTPS, SMTPS, LDAPS, etc). In this example, we infer we're talking HTTPS because destination port is 443, but the traffic could be any TCP protocol that behaves over single destination port (example: SSH/one_port vs FTP/multiple_ports),
The HTTPS_Filtering feature of 8e6 R3000 allows you to enforce added layer of filtering. Here are the details on specific -- most commonly used -- settings of LOW and MEDIUM (screenshot below for reference):
LOW: R3000 will inspect destination server IP address -- will block if IP in blocked category.
MEDIUM (default): R3000 will inspect destination server IP address --and open separate HTTPS connection to same IP to pull server cert. Then will attempt to apply filter policy to hostname listed in SSL cert.
The implications for filtering SSL traffic:
- You can't use URL keywords to block HTTPS traffic (GET request embedded inside HTTP procotol -- not visible).
- You can't block specific SSL URL (beyond https://hostname.domain.com/). URL hostname pulled from SSL server cert -- R3000 HTTPS_Filtering setting of Medium or higher required for this).
I may have had to change HTTPS filtering to LOW -- suggest you insure set to MEDIUM. This setting does require that the R3000 has open HTTPS connection direct to Internet (ie. not blocked by firewall, etc).
