©2018 by packetaddict.com. Proudly created with Wix.com

Search
  • Michael Weeks

SSL Interception - or Training Your Admins to Cut-Corners

Updated: Feb 10, 2019

More and more Security vendors are moving to SSL interception on products. After pushing organizational certificates to browsers as Trusted CAs they tout beautiful visibility for full pcap or in-line devices. Yes as an Incident Handler and Intrusion Analyst I personally love to see this type of data - the name of my site is packetaddict.com as an example, every environment that I've seen implement this type of detective measure has not been able to do it with jeopardizing something critical to internet security - trust.

Before things like certificate pinning monitoring traffic was doing something as simple as uploading the private certificate to your monitoring tool, such as wireshark or tcpdump but now the only sure-fire way to get the traffic without extreme negative impact to the user is to implement a full proxy to an inline device where the entire stack is recreated with the internal certificate provided to the browser. For a normal user this is pretty standard (other than some privacy concerns), but for a sub-set of the population interception will encourage them to circumvent security to get their job done. Administrators and developers (and frankly cyber security personnel) will opt to ignore any certificate issues when not using a browser for network connections.

wget --no-check-certificate https://www.google.com

This will train these privileged users to ignore these types of errors and just avoid them at all costs. For those of you using linux systems if you are diligent internet user you should download the organizational CAs to - http://www.vinc17.net/unix/cacert.en.html


1. Download/copy the certificates into a directory, e.g. ~/etc/certs.


2. Generate the hash values with the c_rehash command and the directory as argument. For instance: c_rehash ~/etc/certs. With the official c_rehash utility from openssl, all the certificates must have the .pem extension; to support the .crt extension as well, which is commonly used, one must either use Debian's c_rehash script or replace /\.pem$/ by /\.(crt|pem)$/ in the script.


3. Add the certificate directory to the configuration files of curl and wget. For instance, in the ~/.curlrc file:


4. capath = "/home/user/etc/certs:/etc/ssl/certs"

(note that the ~ and $HOME forms are not supported) if /etc/ssl/certs is the default directory (containing the certificates installed on the system); this is valid at least for curl 7.21 to 7.35. And in the ~/.wgetrc file (at least for wget 1.13 to 1.15):


5. ca_directory = ~/etc/certs


For all my wintendo buddies out there:


Ignore SSL certificate errors by adding the following to your script:

[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

- Not the right way, the right way is to actually add a CA to your script.


You can do it with this github - https://github.com/Jaykul/Tunable-SSL-Validator

Post in your PowerShell environment variable:

Install-Module TunableSSLValidator

bool TunableValidationCallback(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)


You should be able to do this once on your system and then you will be good to go. That way all of us annoying IR folks can look at your packets without you compromising security.





23 views