SSL DPI

[NW4FUN]

Hello folks,

I'm looking to implement an SSL DPI function in order to policy some unwanted behaviour (ie. Snapchat.com).
I run Sensei that can block the Snapchat app, however its website can be easily accessed since traffic is encrypted and sensei fails to detect and block as it should.

Any pointers? I haven't found any solution through OPNsense's plugin repositories...

TYA in advance

[mimugmail]

You can force all dns traffic to opnsense and Block the dns name

[NW4FUN]

You can force all dns traffic to opnsense and Block the dns name

I'm not sure I'm following...

How do I do that?
How is this helping policing encrypted traffic?

[NW4FUN]

Any hint?

[tiermutter]

As example:
I am using adguard home running on my sense to do name resolution. Using filters you can block any unwanted DNS like snapchat.com.
To do this, it is required that adguard / your sense responds to any DNS request and that there is no way to bypass. This can be done by redirecting port 53 (DNS) to your sense / DNS resolver.
Aside from that, you need to ensure that your clients never can bypass it using DOT or DOH.
For DOT you can simply block port 853 (most clients will fallback to normal DNS).
For DOH it's a bit tricky, as it uses port 443. You will need to block 443 traffic with destination to DNS servers using an alias with according filter lists e.g. https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/master/doh-ipv4.txt

It will still be possible to use the IP address to connect to snapchat.com, so you may want to block access by IP creating an alias. Be aware that this may also block other traffic, e.g. if other websites are hosted on the same server; this will also apply to the use of DOH blocklists.

[cgone]

Another easy way is to do sni-inspection with nginx and using AdGuardHome to block:

Code Select Expand


    server {
        resolver 127.0.0.1;
        listen 1443;
        ssl_preread on;
        proxy_connect_timeout 5s;
        proxy_pass $ssl_preread_server_name:443;
    }

You put the ip-adress of your AdGuardHome installation at the 'resolver' directive and you need to do a port forward to 1443 for the client you want to filter.

nginx will extract the sni-part out of the stream and resolve the "real address" with the AdGuardHome (mostly to 0.0.0.0), which results in a denied connection.

[abulafia]

You could also block access to the Snapchat servers based on its ASN IPs.

[NW4FUN]

TYA for your input.

However, all those workaround seem to introduce more side issues than anything... :-\
Is there any native SSL inspection we can implement to achieve a cleaner result?

Apparently Zenarmor is planning to introduce that shortly, only for business licenses tho...
(https://www.sunnyvalley.io/plans)

[mimugmail]

TYA for your input.

However, all those workaround seem to introduce more side issues than anything... :-\
Is there any native SSL inspection we can implement to achieve a cleaner result?

Apparently Zenarmor is planning to introduce that shortly, only for business licenses tho...
(https://www.sunnyvalley.io/plans)

There isnt a free alternative, thats why commercial stuff costs money

[Fright]

achieve a cleaner result?

cleaner result would imply a sort of mitm i think
you can look at transparent proxy without tls termination (using only sni to make a decision) - but I'm sure it's not a complete solution.
for real dpi, you will have to terminate the tls and force clients to trust your root cert. imho )

[NW4FUN]

There isnt a free alternative, thats why commercial stuff costs money

That's not a fair comment buddy as I never mentioned I was looking for free stuff, as a matter of facts, I do pay for Zenarmor home plan; the problem is they've decided for some reason to enable (in the near future) full SSL inspection only for the BUSINESS plan leaving out both FREE, HOME and SOHO plans.

[NW4FUN]

achieve a cleaner result?

cleaner result would imply a sort of mitm i think
you can look at transparent proxy without tls termination (using only sni to make a decision) - but I'm sure it's not a complete solution.
for real dpi, you will have to terminate the tls and force clients to trust your root cert. imho )

Hey Fright, thanks for your comment. A transparent proxy (Squid) is what I'm implementing to achieve that result, however I have three challenges ahead of me now:

1. WhatsApp file transfer (pics, docs, vocals, etc) is being blocked despite I've tried to whitelist both WhatsApp.com and WhatsApp.net
2. I cannot find any documentation on house to trust self signed certificates on WatchOS (Apple Watch)
3. I am unable to get Wireguard's road warriors going through the proxy

Any clue?

[mimugmail]

There isnt a free alternative, thats why commercial stuff costs money

That's not a fair comment buddy as I never mentioned I was looking for free stuff, as a matter of facts, I do pay for Zenarmor home plan; the problem is they've decided for some reason to enable (in the near future) full SSL inspection only for the BUSINESS plan leaving out both FREE, HOME and SOHO plans.

It's not fair but reality. People working on free stuff in their spare time need time for this and money, if you want to continue working on open source and earn money, you need some kind on income. Thats why there is a business edition in OPNsense too.

Just wanted to say, there is no good alternative for it.

[Fright]

@NW4FUN
Hi)

1. WhatsApp file transfer (pics, docs, vocals, etc) is being blocked despite I've tried to whitelist both WhatsApp.com and WhatsApp.net

I don't know if this applies specifically to whatsapp data transfer, but I see a general issue with the allowing a specific app traffic with DPI: what if an application that claims to be secure really tries to be? in this case, the app (for example) will not use system trusts, but will only trust the CAs used by the application's servers. in this case, the connection will not be successful (mitm CA is not trusted by the app). possible solution - pass this traffic before the DPI (based on a block of addresses, for example)

2. I cannot find any documentation on house to trust self signed certificates on WatchOS (Apple Watch)

did not work with the watchOS, i would not be surprised if it only works with a preset trusts.

3. I am unable to get Wireguard's road warriors going through the proxy

I didn't catch it here. encapsulate udp traffic in the tcp stream and send it through a proxy? why?

I do not think that any (paid?) solution can solve all the caveats. probably it will try to use a combination of technologies (IPS with app signatures, dns lists, plain ip blocks etc.) but it won't be a perfect (clean?) solution. the next idea would be to move to a whitelisting strategy (everything that is not allowed is denied)  ;)