OpenSSL 1.1.x & TLS 1.3

Looking under the hood, it looks like OpenSSL 1.1.1a is the default install on FreeBSD 12.0-RELEASE base. We use Squid 4.4 & Apache 2.4.37 both of which had to be recompiled.

Just a few notes if you share a similar configuration:

  • build /usr/ports/security/openssl111/ or use pkg 
## modify /etc/make.conf to reflect

DEFAULT_VERSIONS+=ssl=openssl111

## modify httpd.conf to reflect something similar to these:

SSLProtocol -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3 
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA

Once all modifications are finalized, restart Apache and fire up https://www.ssllabs.com/ssltest/ to verify.

To verify with Squid, use

$ squid -v
Squid Cache: Version 4.4
Service Name: squid

This binary uses OpenSSL 1.1.1a 20 Nov 2018. For legal restrictions on distribution see https://www.openssl.org/source/license.html

Please note the above configuration purposely disables SSLv3 & TLSv1.0-1.1 – only TLSv1.2 and 1.3 are enabled with corresponding ciphersuites. All other connections will fail.

Alaska – The Last Frontier

Danskoya (Norway), Hokkaido (Japan) and Alaska (USA) are three places I’d like to visit someday with my wife & kids.

The serenity, blistering cold, vast spaces of wilderness, tributaries of flowing rivers & lakes, majestic coastlines, the rich history of local natives are just some of the reasons why I am drawn to these remote places.

I don’t spend a lot of time watching television. But if I do, I set aside time to enjoy documentary shows about Alaska on the Discovery Channel, PBS and other stations.

The blog post title is one of those shows alongside “The Last Alaskans”, “Life Below Zero”, “Alaskan Bush People” and many others.

What I find most fascinating with these shows are the endless stories about survival in the outdoors, family and ancestral history, team work with family members & neighbors, passed on traditions and rituals and most importantly – being responsible by taking advantage of opportunities to the fullest.

—
yours truly, @warehouseninja

Bootable USB Drives with Rufus

written by Pete Batard, this neat tool helps you create bootable USB drives of various types of operating systems. It supports .img and .iso source files just to name a few.

The software is free & open-source and can be downloaded from https://rufus.ie/

At Danskoya.com, we utilize Rufus to create & maintain bootdisks for Windows 10 and FreeBSD. It has proven to be very valuable for all our hardware/software deployments.

WebRTC in Firefox & Chrome

If you don’t need WebRTC, you can disable it:

In Firefox, type about:config in the URL bar then search for media.peerconnection.enabled, highlight it then right-click and select Toggle to set the Value to false

In Chrome, install the WebRTC Leak Prevent plugin by Aaron Horler and set the IP-handling policy to Disable non-proxied UDP (force proxy)

To test both browsers for IP-address leaks, use https://whoer.net

VirtualBox, FreeBSD, Squid & Reverse SSH Tunnels

Update: 4/23/20 – if Squid 4.11 chokes with http_port 1.2.3.4:listening_port and /etc/rc.conf is configured for DHCP, modify it to http_port listening_port and the reverse tunnel should work again.

***

Update: 4/10/20 – just quick note that using “localhost” with these reverse tunnels will not work if SSHD, Squid or some other service is configured to use a specific IP address. Use the format “-R local_port:1.2.3.4:remote_port” where 1.2.3.4 is the correct and actual IP address.

There has been countless articles written about these subjects. Regardless, I want to share my own experience.

***

  1. Install VirtualBox for Windows 10
  2. Install FreeBSD as a Guest OS
  3. Install & configure Squid
  4. Configure VirtualBox to run FreeBSD headless

Once that is up and running, get a solid VPS from Vultr, install FreeBSD as guest OS and use it as a jump host.

The basic idea is to create a reverse SSH tunnel (1st -R option) from the machine that runs VirtualBox/FreeBSD (sitting behind NAT) to your Vultr/FreeBSD VPS. The reason being is that there’s no way to SSH (forward tunnel) into the VirtualBox/FreeBSD endpoint directly.

Don’t forgot to setup a key-based authentication w/ no passphrase between the two endpoints.

Here’s the full command:

/usr/bin/ssh -i /path/to/sshkey -N -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -R 2020:localhost:3030 -R 4040:localhost:5050  username@1.2.3.4 -p 5678

Let’s break it down:

2020 is a port (Vultr/FreeBSD) that will forward requests to port 3030 of Squid (VirtualBox/FreeBSD)

4040 is a port (Vultr/FreeBSD) that will forward requests to port 5050 of SSHD (VirtualBox/FreeBSD)

1.2.3.4 is the IP address and 5678 is the SSHD listening port (Vultr/FreeBSD)

When the local Squid instance running under Vultr/FreeBSD is used as an HTTP forwarding proxy, by default, you’ll be seen by web sites under the IP/hostname you’ve assigned it to. The fun part is that you can configure it to forward proxy requests through the reverse SSH tunnel (2nd -R option) to the VirtualBox/FreeBSD/Squid endpoint using a child <-> parent relationship. And as a result, your web browsing sessions will be seen by web sites under the public (internet facing) IP/hostname of the VirtualBox/FreeBSD/Squid endpoint.

cache_peer 127.0.0.1 parent squid_port 0 no-query no-digest
never_direct allow all

The code above must be added to the Squid configuration file running on your Vultr/FreeBSD VPS. “squid_port” must reflect the actual port number Squid is configured to listen to (default is 3128).

In my example, the parent Squid is on Vultr/FreeBSD, the child Squid is on VirtualBox/FreeBSD. Both endpoints MUST have Squid running and listening. Don’t forget to apply lock-down as usual.