Overview

The SSL/TLS cryptographhic protocols are used to ensure confidentiality, integrity and authentication of data communications, for instance between a customer and a company during a transaction in a web shop on the Internet. Without the invention and dominant usage of SSL/TLS, confidential communication like money transfers and online shopping wouldn't be possible today. Correct implementation and configuration of SSL/TLS are therefore vital for establishing a trustful relation between online businesses and their customers.

In 2009 researchers found a design flaw in the SSL/TLS protocol which could be exploited maliciously to inject data between two endpoints - effectively breaking confidentiality, integrity and authenticity.

Very soon after the discovery of this design flaw, the protocol was re-designed to ensure security. Virtually all vendors implementing SSL/TLS swiftly followed the redesign and patched their products. Most of the products have patches available since early 2010. But how many customers have actually implemented these patches?

Review

CIRCL used a sampled list of .lu domains to check the status of implementation. This report shows that more than a quarter of the tested .lu domains are not updated yet. Additionally, even more domains present an expired certificate to their users/customers/visitors. This shows that appropriate certificate management is challenging. For instance, the renewal of certificates in time is critical. The question that remains is: can users of such websites cope with such challenges? How do they react if an expired certificate is presented to them?

Our objective is to raise awareness around of SSL/TLS security. We want to give answers to common questions, explain the backgrounds and show strategies to resolve or mitigate the threat. This includes the questions:

• Is my site vulnerable to this attack and how can I check if it is?
• What do I have to do to secure my server?
• Is my certificate expired, and if not, when does it expire?
• Are there any other weaknesses in my certificate handling (e.g. mismatch between name of server and name in certificate)

These questions, when properly answered, not only strengthen trust and confidence in your Internet business and in Luxembourg as a business location.

What is SSL/TLS?

• The acronyms
  • SSL: Secure Sockets Layer (SSLv3 → TLSv1)
  • TLS: Transport Layer Security
• The TLS and the SSL protocol provide
  • Authentication services (both peer entity and data origin)
  • Connection confidentiality services
  • Connection integrity services
• This means
  • Establish a secure connection between communicating peers (authentic and confidential)
  • Securely transmit application data between the two hosts
• Standards
  • TLS v1.2 - IETF RFC 5246

What is SSL/TLS renegotiation?

• Allows either the client or the server to initiate renegotiation
  • a new handshake that establishes new cryptographic parameters
• Optional feature, but support recommended (RFC 5246)
• Use cases
  • Long-living connections where the certificate changes in the meantime
  • IIS initiates renegotiation if a negotiated but non-authenticated client requests a restricted server resource so that the client could authenticate itself with the certificate.

What is the CVE-2009-3555?

• The TLS and the SSL protocol does not properly associate renegotiation handshakes with an existing connection
• Allows man-in-the-middle attackers to insert data into HTTPS sessions
  • (and possibly other types of sessions protected by TLS or SSL)
• Type: Design error in SSL
• Affected Software: almost all implementations of SSL
• Publicly disclosed in November 2009
• Protocol fixed in February 2010, IETF RFC 5746
• Disabling the renegotiation completely might be an option too

How does the attack work?

• By sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context
• Possible attacks
  • Downgrade attack (from HTTPS to HTTP),
  • Control content from server to client
  • Control content from client to server (example below)
  • Stealing, modifying secure cookies/sessions
• Example:
  • Man-in-the-middle attacker sends attack string:

    GET /transfer?currency=euro;amount=10000;account=IBAN666 HTTP/1.1
    X-Ignore-This:
    

  • Victim sends valid request:

    GET /transfer?currency=euro;amount=20;account=IBAN1234 HTTP/1.1
    Cookie: victimscookie
    

  • Due to renegotiation, sessions are glued together:

    GET /transfer?currency=euro;amount=10000;account=IBAN666 HTTP/1.1
    X-Ignore-This: GET /transfer?currency=euro;amount=20;account=IBAN1234 HTTP/1.1
    Cookie: victimscookie
    

Prerequisite

• Man-in-the-middle situation, such as might happen in public networks or compromised systems
• Vulnerable SSL/TLS server software that supports insecure renegotiation
  • SSL/TLS not patched
  • SSL/TLS insecure renegotiation not turned off
• Two known attacks used the vulnerability: Twitter SSL login attack

Software implementing IETF RFC 5746

• Microsoft SSL components (starting from MS10-049 patches)
• IBM Java (starting from Java version 5.0 SR12)
• Apache HTTPD (starting from 2.2.15 and 2.3.6)
• OpenSSL (starting from 0.9.8m and 1.0.0a)
• Zeus WebServer (starting from 6.0r7)
• nginx (starting from 1.0.0)

Status in Luxembourg

• Set of 13944 DNS registered .lu domains
  • Resulting URLS: 8977 (64%)
  • Timed-out: 3223 (23%)
  • No SSL on port 443: 1744 (13%)
• 8977 Resulting URLS (100%):
  • Not vulnerable: 6506 (72%)
  • Vulnerable: 2471 (28%)
• Bonus: 8977 SSL enabled websites
  • 2576 expired certificates (29%)

SSL connectivity statistic

Vulnerable - not vulnerable statistic

Expired certificates

Problems the user/customer might discover

The SSL/TLS vulnerability is not visible for the user/customer of a website. But there are other possible misconfigurations or administrative lapses that affect the user's experience in relation to SSL/TLS certificate management, because the user will be notified about an irregularity and he/she is prompted for an action. Following cases are possible:

• Expired certificate (already mentioned)
  • Solution: renew certificate with Certificate Authority
• Self-Signed certificate
  • Solution: get the certificate signed by a qualified Certificate Authority, if required by your Security Policy
• Mismatch between fully qualified domain name (FQDN) and FQDN in the certificate [1]
  • Solution: create certificate containing a name matching the FQDN of the server

CIRCL's SSLcheck tool

CIRCL created a tool, accessible online at http://sslcheck.circl.lu to check for all of the afore mentioned problems, just by entering the server's fully qualified domain name and port, accompaigned by the solution of a captcha (to limit requests sent out by the server):

• SSL/TLS vulnerability
• Expired certificates
• Self-signed certificates
• Name mismatches
  This test is not perfect: it is possible to check domains that are not supposed to support SSL, but which are served from a server infrastructure with multiple virtual hosts. It could be that in this case only one or some of the virtual hosts are configured to support SSL properly.

Copyright 2008 - 2011 CIRCL Computer Incident Response Center Luxembourg (smile gie) PGP signature of this page