SSL

Check your website for Chrome distrust

Hey Friends,

The upcoming releases of Google Chrome September 2018 time frame is said to no longer trust certain Symantec, Thawte, GeoTrust, and RapidSSL SSL/TLS certificates. Chrome users will see “Not secure” in the address bar when connecting to websites using a distrusted certificate.

The folks over at Qualys wrote:

Google finalized their plans for staged deprecation of Symantec certificates. The process began in March 2017 when Google had announced on the Blink mailing list that they had lost confidence about Symantec’s certificate issuance policies and practices of recent years. The initial deprecation proposal was very strict and looked like it would completely paralyze Symantec, ending with limiting their certificates to validity time of less than one year.”

Ref:  https://blog.qualys.com/ssllabs/2017/09/26/google-and-mozilla-deprecating-existing-symantec-certificates

You can check your site for this issue by going to Symantec’s SSL Checker site: https://www.websecurity.symantec.com/support/ssl-checker

Preparing for Browser Distrust

On March 15, 2018, the beta of Chrome version 66 will be released and the legacy Symantec certificates will no longer be trusted (again, this only affects Symantec certificates issued before June 1, 2016). Chrome Beta is only used by a fraction of Chrome’s overall user base, but we still consider it significant enough that we are striving to replace affected certificates before that date. The “Stable” release—the main version used by consumers—follows a month later.

Firefox will distrust the same set of certificates later in the year. You are not required to take action for each specific browser—replacing your certificate once is all that’s needed.

These certificates must be reissued and replaced before the March 15 deadline in order to avoid untrusted certificate errors on Chrome beta, which will interrupt website service and obstruct visitors to your site.

The process for replacing affected certificates will be extremely similar to how you renewed or ordered certificates in the past. You’ll need to submit an order/certificate request, complete validation.

Replace Your Symantec SSL/TLS Certificates

This information keeps changing so here is a link to get the latest details as they are updated:

https://www.digicert.com/replace-your-symantec-ssl-tls-certificates/

 

OpenVPN Access Server on Ubuntu

I recently retired my OpenVPN Turnkey appliance and needed to get my VPN solution up and running again. I decided to go with installing OpenVPN Access Server on a clean install of Ubuntu Server to create a stable and lightweight Virtual Private Network (VPN) to access my network.

I chose to go with OpenVPN AS because it’s using the OpenVPN I know and trust, but it also has the value-added feature of an administrative server used for user and access management.

Setup is straight forward after a few small prerequisites are established.

Requirements:

  • Ubuntu Server – Running the latest version and updates. I am using 16.04.2-as my base
  • Root or possibly sudo access

Software:

Download the latest release of the OpenVPN AS Server
https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html

The direct Ubuntu installs here

 

The following steps can be used to download and install:

  1. Download the install package: wget http://swupdate.openvpn.org/as/openvpn-as-2.1.9-Ubuntu16.amd_64.deb
  2. Install the downloaded package: dpkg -i openvpn-as-2.1.9-Ubuntu16.amd_64.deb
  3. Change the password for the openvpn user: passwd openvpn

When the installation has completed, the Access Server web UIs will be available here:
Admin UI: https://<yourip>:943/admin
Client UI: https://<yourip>:943/

 

And just like that you now can take better control over your privacy, security.

Note: I did not go over the configuration of OpenVPN AS, I may do this in another post. I just wanted to run through the steps of getting this software installed.

 

Here is a short video on ‘what a VPN is’ – Thank you Qusai

Windows 2003, HTTPS Access Issues

One of the teams I support had run into some issues. Spending a lot of time investigating code and possible configuration problems. What they later suspected to be a policy issue, possibly a firewall, network issues turned out to be something entirely different.

Lets start with the symptoms:

  • Service request to a secured site stopped functioning, there were no know changes on the client (server) end. All attempts to connect to this site using the internet explorer failed.  However connections can be made to the site from the same network on other systems.
  • Windows updates did not resolve the issue
  • There was no proxy server or network firewall in the path from the client to the destination server hosting the services
  • Note: Port 80 (HTTP) web requests and even alternate ports listening on HTTP had all worked

 

Differential testing:

  • Attempted to access other known and popular SSL enabled sites and encountered the same issue
  • Attempted to connect to some SSL enabled sites which I had in a lab environment and they worked — OK, Good… SSL is working from this host.
  • But why?  I did some checking on the SSL Certificates, using some of the steps from one of my older posts: http://jermsmit.com/tech-short-lets-test-for-poodle-or-sslv3/

Example of the command used: openssl s_client -connect google.com:443

Discovery: I noticed that the Cipher types where different between those sites which worked using SSL and those that did not.

  • The sites that worked used SSL-Sessions with a Cipher of: AES128-SHA
  • The sites that no longer worked used SSL-Sessions with a Cipher of: ECDHE-RSA-AES128-GCM-SHA256, AES256-GCM-SHA384, etc.

It seems that all SSL sites using SHA2 256 or higher encryption where no longer supported.

 

Resolution: I started my search for a possible hotfix for this issue and I found it

The following KB post details this issue and provides the hotfix download to resolve the limitation on this older OS: https://support.microsoft.com/en-us/kb/968730

Note: Make sure to download the correct Platform version of the hotfix.

 

 

Please disable POODLE in IIS, here is how

Here we are again with POODLE

I’ve touched on it here: http://jermsmit.com/security-news-poodle-security-vulnerability/

Then secured up Apache here: http://jermsmit.com/secure-apache-httpd-from-poodle/

And even did some testing here: http://jermsmit.com/tech-short-lets-test-for-poodle-or-sslv3/

This time I am adding the steps used to secure-up some IIS Servers.

Lets Start:  *note* These steps apply to Server 2003, 2008, 2012

Requirements: 

  • Administrator Rights
  • Registry Changes
  • Reboot of Server

Steps:

  1. Log into server or remote access registry
  2. Once in the servers registry, navigate to the following key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server
  3. If the DWORD value Enabled exists set it to “0”else create it as such
  4. Reboot & and Test

One of many test sites: POODLE Scan – https://www.poodlescan.com/

 

*Update* 2017 – The following tool should help simply the process above: https://www.nartac.com/Products/IISCrypto

IS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2008, 2012 and 2016. It also lets you reorder SSL/TLS cipher suites offered by IIS, implement best practices with a single click, create custom templates and test your website.

Configuring Apache for Forward Secrecy

I was testing one of my SSL enabled sites after securing apache HTTPD from POODLE, when I noticed the following warning:

The server does not support Forward Secrecy with the reference browsers

To ensure I was operating at the best security level possible for my little site, I added the following to the apache2.conf (/etc/apache2/)

SSLProtocol all -SSLv2 -SSLv3  < added this when securing against POODLE
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”

By the way, if you are running NGINX you can add the following:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”;

After I completed the changes above, I tested again and things looked much better and my score went up.