Blog: SSL

Recently we've been experiencing a problem with the Cisco AnyConnect client disconnecting and reconnecting shortly after the initial connection is established. Originally we thought that this was a bug in the client. Cisco recommended switching to an IKEv2 connection profile, but the disconnect problem was never resolved, even with updated versions of the client. During a recent remote session with Cisco support, the root cause of the disconnects was discovered.

In later versions of the AnyConnect client, there are two protocols in use:  SSL and DTLS. DTLS is a variant of TLS that uses datagrams which are sensitive to delay. After authentication, the client attempts to negotiate a DLTS connection. If that negotiation is unsuccessful, the client disconnects and reconnects using SSL only. DTLS uses UDP port 443. In our test environment, the remote access firewall is behind another firewall that was only allowing TCP port 443 through. After updating the firewall rule to allow UDP port 443 as well, the disconnects stopped occurring.

Multiple Microsoft articles indicate there is a future update to be released for Internet Explorer 11 that will disable SSLv3 by default. This is in addition to the posted workarounds and group policy settings that recommend disabling SSLv3 across all browsers to mitigate the POODLE vulnerability.

Since the Poodle vulnerability resulted in SSL v3 to be disabled in web browsers, it broke connectivity to APC devices configured to use SSL. [more]

Using Firefox, you can type in about:config in the web path to enter an advanced configuration mode. The default value of security.tls.version.fallback-limit and security.tls.version.min is “1”. Setting this to “0” will allow you to be able to connect again, but be careful about having SSL connectivity enabled.

I setup a Remote Desktop Gateway for a customer a few weeks ago. During the setup, I was prompted to create a certificate for the server, but it was just a self-signed certificate. I need a certificate signed from my internal CA for testing with my laptop outside of the network. I originally created a computer certificate, but when I tried to connect it would not allow me to connect because the remote desktop gateway address did not match and name on the certificate. This was obvious because the internal domain is a domain.local address and I was trying to access ts.domain.com. Also, a computer certificate does not allow for subject alternate names. A web server certificate is the type of certificate to use when adding subject alternate names, but I was unable to create one for the computer account.
The solution is quite simple, change the permissions on the certificate template. [more]

1. On your internal certificate authority, go to Start > Administrative Tools > Certificate Authority
2. Expand your CA from the list > Right click Certificate Templates > Manage
   
3. Right click Web Server > Properties
4. Select the Security tab. Grant Domain Computers (or the specific computer) Read, Write, and Enroll permissions.
   
5. Close all open windows.
6. You can now request a certificate from the computer account based on the Web Server template.
   

Interner Explorer 9.0 will display a warning if the view a website over SSL that is using a certificate signed by an untrusted certificate authority (CA).  This is often the case for self-signed certificates and it can become annoying.  Here's how to eliminate the warning:

1. Browse to the site whose certificate or certificate authority you want to trust.
2. When told "There is a problem with this website's security certificate.", choose "Continue to this website (not recommended)."
3. Select Tools->Internet Options.
4. Select Security->Trusted sites->Sites.
5. Confirm the URL matches, and click "Add" then "Close".
6. Close the "Internet Options" dialog box with either "OK" or "Cancel".
7. Refresh the current page.
8. When told "There is a problem with this website's security certificate.", choose "Continue to this website (not recommended)."
9. Click on "Certificate Error" at the right of the address bar and select "View certificates".
10. (if it is a self-signed certificate, skip to step 13) [more]
11. Click the Certification Path tab
12. Click the root CA
13. Click View Certificate
14. Click on "Install Certificate...", then in the wizard, click "Next".
15. On the next page select "Place all certificates in the following store".
16. Click "Browse", select "Trusted Root Certification Authorities", and click "OK".
17. Back in the wizard, click "Next", then "Finish".
18. If you get a "Security Warning" message box, click "Yes".
19. Dismiss the message box with "OK".
20. Select Tools->Internet Options.
21. Select Security->Trusted sites->Sites.
22. Select the URL you just added, click "Remove", then "Close".
23. Now shut down all running instances of IE, and start up IE again.
24. The site's certificate should now be trusted.

The most common application I see is with SSL VPN users, but it is also useful for accessing management interfaces (such as an ASA or a McAfee ePolicy Orchestrator).

The need for SSL Certificates should be considered when utilizing a non-registered domain such as “.dom” or “.local”.

http://support.godaddy.com/help/article/6935/using-intranet-and-reserved-ip-addresses-as-the-primary-domain-or-subject-alternative-name-in-ssls
Using Intranet and Reserved IP Addresses as the Primary Domain or Subject Alternative Name in SSLs

The Internet security community is phasing out the use of intranet and reserved IP addresses as the Primary Domain Name or the Subject Alternative Name in SSL certificates.

This is an industry-wide decision, not one specific to our company...

As a result of this decision, on July 1, 2012, we no longer accept new requests, process rekeys or renewals, or allow any management of Subject Alternative Names for certificates that contain intranet names or reserved IP addresses, and are valid beyond November 1, 2015...

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.

Windows 2008 and IIS 7.0 installs with Secure Sockets Layer (SSL) version 2 and “weak” cryptography ciphers turned on by default.  Having that turned on will likely turn up some problems in a penetration test.  Here are some common vulnerabilities names that might be identified in your penetration test results:

• SSL Server Supports Weak Encryption
• SSL Server Allows Cleartext Encryption
• SSL Server May Be Forced to Use Weak Encryption
• SSL Server Allows Anonymous Authentication [more]

Disabling 

Unfortunately, there is not currently an intuitive way to enable/disable the protocols and ciphers built into the Windows GUI.  You must edit your systems registry to get the job done.  Some of the registry keys and DWORDs will likely not be in the registry, so you will need to add them. It’s always a good idea to back up your registry before making changes just in case something goes wrong.  Click Start, click Run, Type regedit32 or type regedit, click OK, and then add/modify the keys listed below.

Here are the registry keys to turn off PCT 1.0 and SSL 2.0 and leave SSL 3.0 and TLS 1.0 turned on:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server
  • DWORD = 1
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
  • DWORD = 1

Here are the keys to turn off “weak” SSL ciphers:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128
  • DWORD = 0

Testing

The easiest way I’ve found to verify the protocols and ciphers are turned off is to use the free OpenSSL toolkit.  Here are some instructions for installing Cygwin with OpenSSL on Windows 7: https://www.conetrix.com/Blog/post/How-to-Install-OpenSSL-on-Windows-7.aspx.  Here are some instructions for installing OpenSSL on Ubuntu: https://help.ubuntu.com/community/OpenSSL#Practical OpenSSL Usage.  If you are using a Mac OpenSSL should already be installed.  Once you get it installed you can verify your registry changes worked.

Once you get it installed here is the commands you can use to verify that SSLv2 is turned off:

# openssl s_client –ssl2 –connect YOURSERVERNAME:443

If server does not support SSLv2 then you should see an error like the following two examples:

CONNECTED<00000003>
Write:errno=113

Or

CONNECTED<00000003>
1324:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

Here is the command to test for weak ciphers:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers then an error will be displayed similar to the error examples given above.

When changing some settings in Internet Explorer recently, I stumbled across the “Use SSL 3.0” and “Use TLS 1.2” settings under the Advanced tab of Internet Options.  For a long time, I have been running without SSL 2.0, TLS 1.0, and TLS 1.1 enabled, but I wondered if SSL 3.0 is even necessary anymore (TLS superseded SSL 3.0 in 1999).  So I unchecked the “Use SSL 3.0” check box.  I did the same in my Firefox settings.  I ran that way for at least a couple of weeks without any noticeable issues.  Then last week I was onsite at a bank and tried to use the Cisco AnyConnect SSL VPN.  It did not connect, so I tried it that night from the hotel.  It still did not connect.  The Cisco IPSEC VPN client worked perfectly.  After a couple of days of the AnyConnect client not working, I was about to send an email to one of our network engineers asking if anything had changed when I remembered the “Use SSL 3.0” setting.  After re-enabling SSL 3.0 in both IE and Firefox, the AnyConnect client worked.  Aside from the SSL 3.0 setting breaking AnyConnect, the more general GOTCHA is that the AnyConnect client uses at least some of the web browser settings when establishing its connection, so I now know to include them when troubleshooting the VPN.