SSL

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/

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.

SHA-1 based SSL Certificates are being Phased Out

Hello friends,

The following post is to advice some of you that run public facing websites which use SSL.  Google Chrome  will start giving users Warning messages when accessing sites that use SHA-1 based SSL Certificates.

By the way – This is scheduled to start happening in under a month form now. And if you are like me and test SSL on sites you manage and visit you would notice that many are now flagging SHA-1 is insecure and lowering your sites ratings on security.

What is SHA-1

The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be since at least 2005 — 9 years ago.

Why change it now?

Well its not that its new news. SHA-1’s use on the Internet has been deprecated since 2011. However change across the world takes a bit more time.  And with the advancement of computing technology the ability to create  Collision Attacks. So companies such a Google and Projects such as Firefox, oh and Microsoft are all Sunsetting SHA-1.

What do this mean for me?

This means you need to have your certificates re-keyed through your SSL provider using a certificate signing request (CSR) with a SHA-256 signing hash if you don’t want people to get browser warnings.

But IIS doesn’t offer this?

You are correct it doesn’t.  If you are using  IIS,  regardless of what version of Windows OS (2003-2012) you only can generate SHA-1 certificates. So its time to embrace the power of Linux or simply OpenSSL to get the job done.

So my advice is that you start making the change, so that you don’t have to deal with the embarrassment of your customers and site visitors asking you why your SSL enabled site is reporting warnings.

Warning Example:  This site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.

– Jermal

Ref Links:

https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

https://blog.digicert.com/what-is-sha-2-and-how-it-affects-you/

Online Tool(s)

Check your SSL Sites – https://www.digicert.com/sha1-sunset/

Secure Apache HTTPD from POODLE

If you are running Apache, as I do you may want to take steps to secure your system but making a slight adjustment to your configuration.

By adding the simply line:

The file location: /etc/apache2

The file name: apache2.conf

Remember to always backup a configuration file before making changes.

Once completed restart apache:  service apache2 restart or /etc/init.d/apache2 restart

 

Tech Short: Let’s test for POODLE or SSLv3

First thing that came to my mind when reading about POODLE was how can I test, followed by what to do to patch/fix this.

So the first thing is to test for the vulnerability. And from all I have read so far is that you are vulnerable if your servers support SSLv3. I am confident that many of the ones I manage do; so lets test this out.

First thing I did was log into my Greyhat Test Box, thank you Kali Linux. Note: this could be any Linux distribution I just wanted to plug those guys/and/gals.

At the command line we will be using the OpenSSL tools to test by typing the following:

If this connects you have SSLv3 enabled, if it failed then you will see:

So if you run a server check out the following links:

Microsoft:
https://technet.microsoft.com/library/security/3009008.aspx

Apache:
http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#msie

Tomcat:
http://tomcat.apache.org/tomcat-6.0-doc/apr.html#HTTPS

Nginx:
http://nginx.com/blog/nginx-poodle-ssl/

And for the end users, disable SSL 3.0 in your browser, avoid MITM attack by using a VPN connection and always, always use HTTPS.

 

Security News – POODLE Security Vulnerability

On Tuesday, October 14, 2014, Google researchers announced the discovery of a vulnerability that affects systems with SSL 3.0 enabled. This vulnerability has been named POODLE (Padding Oracle On Downgraded Legacy Encryption). Details are available at https://www.openssl.org/~bodo/ssl-poodle.pdf.

It has been strongly encouraged to discontinue the use of SSL 3.0.

Info Sources

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

 

Man-in-the-Middle (MITM)

You are on vacation or spending the weekend at the beach. Like normal your using your laptop or smartphone.  You may be computer savvy; so you don’t allow onlookers view you typing your secure passwords.

But its not those that you can see you need to worry about.

Its the person watching your network activity; logging every site you visit, logging you bank credentials,  email, home address , contacts (friend lists), and anything else s/he can obtain. The ultimate eavesdropper.

This persons mission; to steal data from you, about you. This is the man(or woman) in the middle (MITM).

The man-in-the-middle will use many tools and security vulnerabilities which are exploited to allow them to see your data as clear as looking at it on your screen.  More so they can see your passwords even when they are all dotted out from the naked eye.

The MITM can inject code into your session to redirect you to fake sites, they can even see what you are viewing in real time.

Attackers use non-secured log-ins to apps on your phone and web sites you visit to obtain data about you.

So how do I protect myself from this?

There are many solutions; the best methods are to always use applications (apps) on your phone that use secure connections to the services it connects to.  This may be a shock to you; many do not, and this is part of the problem.

Always use sites that are secured with HTTPS from start to finish.  Again, many do not, and this leaves you exposed.

If and when possible use a VPN (virtual private network) solution.

This is another form of protection as your communication is sent encrypted threw a network you trust to be more secure than the one you are presently on.

So best advice I can offer you is

  • Be aware of the sites you visit
  • Ensure the sites you use , are using SSL
  • Be sure the apps you choose to use, are using SSL
  • Get a VPN Solution
  • And change your passwords often
  • And don’t use the same password for everything

 

 

Firefox: Add a Trusted Certificate Authority

By default Firefox has its own certificate store from well-know and trusted commercial Certificate Authorities. So today when I pushed out an internal self signed certificate; Firefox did not reconcile it as valid.

To correct this issue I did the following:

  • Launched Firefox
  • Opened the options panel and selected Advanced
  • Selected View Certificates to access the Certificate Manager
  • Then by clicking Import and browsing to your exported CA Cert you can import the internal certificate.

I hope this helps.

 

 

 

SSL issuer certificate not found after installation

Ouch! With Go Daddy Certificates: I ran into this issue on a server when trying to apply a new Certificate and its intermediate Certificates The issue seemed to be from not having a complete Certificate Chain installed in my servers Certificate Store.

The solution to fix this issue was simple. Download and install the root bundles from here or here: https://certs.godaddy.com/anonymous/repository.pki

This in no way is the fault of Go Daddy; the Server I am hosting on; Server 2003 lacks the much needed certificate store updates so it doesn’t know about the newer root CA’s.

That said; Go Daddy is still the best in my book