Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Juniper SRX Branch - Blocking HTTPS websites using the AppFW (application-firewall) feature - Part 1

Juniper SRX Branch - Blocking HTTPS websites using the AppFW (application-firewall) feature

Tools and utilities used:
- Juniper SRX210-HE
- Junos 12.1X44-D15
- FreeBSD 7.4
- OpenSSL 1.0.1 ( version is necessary for SNI extension)
- Nginx
- tcpdump
- setfib

In order to generate client-to-server and server-to-client traffic from one FreeBSD 7 box without jail and any kind of virtual machines (it's a Pentium 3 box), I had to use different routing tables (or forwarding tables) for client and server. For this, support for multiple FIBs needs to be compiled in the FreeBSD kernel.

Network diagram below:

Note1: Juniper High-End SRX devices support SSL Forward proxy (man in the middle) and can do Layer 7 inspection on the SSL traffic before encryption back to server/client, but branch devices can only do Layer 7 inspection on clear text protocols (unless a 3rd party proxy is used to terminat the SSL, but that's not the point of this article).
Note2: However, protocol TLS v1.0 and above has an extension called SNI (Server Name Indication and all modern browsers support it), where the TLS/HTTPS client that chooses TLS protocol sends in the client hello packet also the name of the destination domain. This SNI extension allows multiple HTTPS domains to be hosted on one public IP address. Without this, only one HTTPS virtual host could be bound to an IP address and this is because the domain information was contained in the encrypted HTTP GET/POST request and the webserver had to first decrypt to get the domain. In order to decrypt the HTTPS connection, it needed to know the SSL parameters (certificate, ciphers, etc) and it couldn't do that without knowing the virtual host ( beacuse all web servers have different configurations for different domains - virtual hosts)... With SNI, the client tells the web server in clear text what domain it intends to connect to via HTTPS and the webserver can load SSL settings for that domain before decrypting it (Cool, ha ?).


Here's a wireshark snapshot of the Server Name Indication extension to TLS1.0 protocol:

The "Client Hello" packet is the first packet sent from the client (Browser) to the HTTPS Server after TCP 3 way handshake is done (in normal situations) and it initializes the SSL/TLS handshake.

Step 1: Preparing the FreeBSD interfaces and Forwarding Information Bases as well as the HTTPS server (nginx).

Good. I have 4 FIBs to play with, but I'll need only two.

I'll be using interfaces vlan120 (fib 1) and vlan121 (fib 2):

So FIB1 routing table will have a route to 10.1.121.2/32 (HTTPS client) to gateway 10.1.120.1 (SRX-1) and FIB2 routing table will have a route to 10.1.120.2/32(HTTP server) to gateway 10.1.121.1(SRX-2).

Nnginx configuration needs to be instructed to listen on the specific IP and fib (See http://nginx.org/en/docs/http/ngx_http_core_module.html and search for "setfib"):

Let's do a test tcptraceroute (why tcptraceroute ? for obvious reasons) from client towards server:


Step 2: SRX-1 configuration (this box will do the layer7 inspection with Application Firewall feature):
SRX-1 interfaces:

Defining a custom nested application for the HTTPS domain that needs to be blocked:


Security zones:


Application-firewall ruleset that matches the nested application for domain "backbook.com" (nothing against this domain, seems unregistered at the moment of this writing) as well as security policy that permits traffic with L7 inspection by AppFW: