C Introducing Nukie – The Cookie Notice Nuker

obsigna

Profile disabled
On the systems which I use for web access, I got installed for years now a logout job which deletes all cookies and web storage entities – kind of tracking tabula rasa. With this in place, I cannot stay logged on to several sites, and I see the very cookie notices again and again. Because of just another GD-PR-Stunt yesterday, this started to happen now to me on the FreeBSD forums as well.

OK, enough is enough, finally I found a good use to Squid on my FreeBSD home server. It runs here as a transparent http/https proxy, and yesterday I installed on it a tiny url_rewrite_program which I named Nukie. Here is the C code:
C:
//  nukie.c
//  nukie
//
//  Compilation:
//    clang -g0 -O3 -march=native -Wno-parentheses nukie.c -s -o ~/bin/nukie
//
//  Created by Dr. Rolf Jansen 2018-08-02.
//  Copyright © 2018 obsigna.com All rights reserved.


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, const char *argv[])
{
   int  repeatedErr = 0;
   char requestSpec[8192];

   while (1)
   {
      if (!fgets(requestSpec, 8192, stdin))
      {
         clearerr(stdin);
         usleep(100000);

         if (++repeatedErr < 10)
            continue;
         else
            exit(1);
      }

      repeatedErr = 0;

      if (strstr(requestSpec, "https://forums.freebsd.org/js/xf/notice.min.js"))
         fprintf(stdout, "OK status=301 url=https://local.obsigna.com/Nukies/freebsd-forums-nukie.js\n");

      else
         fprintf(stdout, "ERR\n");

      fflush(stdout);
   }
  
   return 0;
}

In order the browser behind my Squid can load the notice nuker, I stored to /usr/local/www/apache24/local.obsigna.com/ the following JavaScript:
Code:
var notices = document.getElementsByClassName('notices notices--bottom_fixer js-notices');
if (notices !== undefined && notices[0] != undefined)
    notices[0].outerHTML="";

To /usr/local/etc/squid/squid.conf, I added the line url_rewrite_program /root/bin/nukie.

Nukie shall be comiled as user root:
clang -g0 -O3 -march=native -Wno-parentheses nukie.c -s -o ~/bin/nukie nukie

After restarting Squid on the home server, and when visiting forums.freebsd.org, the cookie notices are removed automatically.
 
Last edited:
Very cool. I can't seem to figure out a way around an error I get when I use bump/server-first flag with ssl_bump. I redirect traffic to squid using PF, and every time I visit a site using HTTPS I get:
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate.
Care to share your config?
 
Yes, no problem. Note, my Squid version is 4.1, and I built it from the ports with "Transparent proxying with IPFW", but this should not make a difference to your intallation with PF. However there is an important difference between the 4.x and the 3.5.x series of Squid. The latter does not resolve intermediate certificates, which could be an explanation for the error which you are seeing. So if you still got Squid 3.x installed, it would be really worth to upgrade to the latest one, and then try again.

Here comes my Squid 4.1 config file /usr/local/etc/squid/squid.conf
Code:
shutdown_lifetime     0 seconds

acl manager           proto cache_object
acl localnet          src 192.168.0.0/24
acl safari5           src 192.168.0.2 192.168.0.3 192.168.0.8
acl port_443          port 443
acl ports_80_443      port 80 443
acl CONNECT           method CONNECT

http_access           allow localhost manager
http_access           deny manager
http_access           deny !ports_80_443
http_access           deny CONNECT !port_443
http_access           deny to_localhost
http_access           allow localnet
http_access           deny all

http_port             localhost:3127
http_port             192.168.0.1:3127
http_port             127.0.0.1:3128 intercept
https_port            127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on cert=/usr/local/etc/squid/proxy-certs/proxy-ca.pem tls-dh=/usr/local/etc/squid/proxy-certs/dhparam.pem

acl step1             at_step SslBump1
ssl_bump              peek step1
ssl_bump              bump port_443

sslcrtd_program       /usr/local/libexec/squid/security_file_certgen -s /usr/local/etc/squid/dyn-certs -M 4MB
sslcrtd_children      8 startup=3 idle=1

cache_mem             512 MB
cache_dir             aufs /var/squid/cache 10000 16 256
coredump_dir          /var/squid/cache

refresh_pattern       -i (/cgi-bin/|\?)  0    0%    0
refresh_pattern       .                  0   20% 4320

request_header_access User-Agent deny safari5
request_header_add    User-Agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9" safari5

tls_outgoing_options  cipher=HIGH:!aNULL:!AES128:!SSLv2:!SSLv3:!TLSv1
tls_outgoing_options  cafile=/etc/ssl/cert.pem
tls_outgoing_options  options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE

url_rewrite_program   /root/bin/nukie
 
I managed to upgrade squid to 4.1, but no luck. I am still getting the same "Your connection is not private" error regarding the certificate. The certificate isn't valid for some reason.
 
Transparent HTTPS proxies do work by intercepting the encrypted traffic for the client, and then ...
  1. validade the public certificate from the server,
  2. decrypt the traffic in order to get it's hands on the contents of the message,
  3. do whatever filtering was configured,
  4. generate a temporary public certificate+private key pair in the name of the server and sign it with the proxy's local CA instance, which is usually (and even better to be) a private, self-signed certification authority,
  5. re-encrypt the traffic with said temporarily faked private server key,
  6. and finally pass the manipulated an re-encrypted content to the client.
For step 1 we need to install security/ca_root_nss, and inform the public CA store to Squid with the following setting tls_outgoing_options cafile=/etc/ssl/cert.pem.

For step 4 we need to setup Squid's SSL Cert Daemon (sslcrtd) with the command sequence:
mkdir -p /usr/local/etc/squid/dyn-certs
/usr/local/libexec/squid/security_file_certgen -c -s /usr/local/etc/squid/dyn-certs -M 4MB
chown squid:squid -R /usr/local/etc/squid/dyn-certs

In addition we need to create the proxy's self-signed local certification authority, for this see my post https://forums.freebsd.org/threads/...r-connection-is-not-secure.62656/#post-361942

Now, for the client's browser accepts the faked server certificate, which has been signed by the self-signed local CA of the proxy, we need to inform to the browser the public CA certificate of this very proxy's CA to be trusted.

Depending on the client's platform, this part is easy (macOS or iOS Safari) to medium complicated (Chrome or Firefox) to obstaculous (Windows). Anyway, without declaring to your browser that it may trust the proxy's CA, it will continue to complain about non-secure connections, or even in case of HSTS refuse to connect at all.
Bildschirmfoto 2018-08-04 um 12.52.01.png
 
Thanks for your support it was really helpful. I recreated my .pem and .crt files using your instructions and recreated the ssl cache database. However, I am still getting an "invalid ca authority" error when I try to use squid with https in both firefox and chromium. It is especially troubling if I have to manually import a cert on every client host that uses this proxy (which is all devices, including ipads). I wonder if there's something I'm just not doing correctly in order to make my local CA valid on each client or its a limitation of the operation. Either way, I appreciate the support. If you have any other suggestions, I'd like to hear them. Otherwise, thanks again.
 
You would need to import the certificate of the proxy on every client which you want to use the transparent HTTPS proxy. This is the way how it works. If it wouldn't be like that, then for example in a public WLAN everybody could setup a transparent HTTPS proxy and would be able to intercept complete HTTPS sessions without the WLAN visitors would be aware of. We don't want that, do we?

Installing the certificate on an iPad is particularly easy. Send it an e-mail with the certificate attached, then on the iPad, tap on the attachment and confirm that you want to trust and install the certificate, ready. On Windows this is quite complicated though.
 
You would need to import the certificate of the proxy on every client which you want to use the transparent HTTPS proxy. This is the way how it works. If it wouldn't be like that, then for example in a public WLAN everybody could setup a transparent HTTPS proxy and would be able to intercept complete HTTPS sessions without the WLAN visitors would be aware of. We don't want that, do we?

Installing the certificate on an iPad is particularly easy. Send it an e-mail with the certificate attached, then on the iPad, tap on the attachment and confirm that you want to trust and install the certificate, ready. On Windows this is quite complicated though.

I suspected as much. Thanks again for your help. I will give that a shot and see if it resolves my issue.
 
Back
Top