Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Bring Out Your Dead: An Update on the PCI relevance of SSLv3

9108_4a7ed65c-8854-4868-af4b-877345c1f96c

In October, a tidal wave of discussion surrounding SSLv3 hit the information security community with the release of the POODLE attack vector. This served to heat up existing discussions about when and how organizations would give SSLv3 the final thump on the head and put it out of its misery.

Thankfully, many organizations seized the opportunity to drop SSLv3 support in their products and services. We expect it will be a while before the majority of products and services to completely drop SSLv3 support, especially for vendors that don't already have an established update regime in place.

But recent statements from the PCI SSC will accelerate the process. The best practice of removing SSLv3 in favor of TLS is quickly evolving into a compliance mandate that many organizations will need to start dealing with this month.

Before we get started, note that upgrading from SSLv3 to TLS 1.1 or greater does not require new certificates. For more on the topic of certificates, head over to the Trustwave blog.

"Strong Encryption"

In reading the PCI DSS, one term you'll notice throughout is "strong encryption" (2.1.1.d, 4.1, 4.1.1 and 4.2). The term was chosen to allow for its definition to evolve over time with the advent of new encryption attack vectors and the required counter measures. This is the case with SSLv3, and the PCI SSC decided in February that SSLv3 no longer meets the definition of "strong encryption." This means that once the PCI DSS is updated, organizations can no longer expect to remain compliant if they continue to use SSLv3.

The PCI SSC has decided that TLS 1.1 or greater does equal strong encryption. We are encouraging organizations who haven't already begun this transition to act now to remove SSLv3 support from all their services and not just those that are in scope for PCI compliance.

Low Hanging Fruit

Big changes in any technology configuration can affect end users, so we wanted to highlight areas where we believe most organizations should start in ridding their network environments of SSLv3.

Finding web browsers that support TLS will not be a significant challenge for most organizations since nearly all mainstream, currently supported web browsers have provided support for TLS for quite some time.

Many of the most popular web servers in use, including Apache, IIS, and Nginx have also supported TLS for a while now. There is also a plethora of guidance publicly available that addresses the removal of SSLv3 from those configurations.

Sticks in the Mud

While some areas are easy to address, organizations will struggle in other areas to get technology up to par. These areas include technologies where the upgrade cycle is typically very slow or where security isn't yet of great concern.

These areas include:

  • Point of Sale (PoS) Terminals
  • Network infrastructure devices
  • SSL VPN devices/services
  • Embedded devices
  • Non-browser client software (thick clients that use SSL)

These areas are challenging because their security life cycles tend to move slower than mainstream web servers and browsers. Also, these areas are generally not the first priority for organizations. That said, they are still an important areas for organizations to upgrade their SSLv3 configurations to TLS 1.1 or greater.

Knowing some services that will make the change slower than others, it's very important that organizations identify services that support SSLv3 so they can prioritize their efforts and determine which to address first.

How to identify SSLv3-enabled services?

Many network vulnerability scanners, especially ASV-certified scanners like Trustwave's TrustKeeper scan engine, already support the detection of SSLv3 services. Many organizations have already chosen to use this as a means to quickly pull together an inventory of SSLv3-enabled services and systematically upgrade or remove them from their Card Holder Data (CHD) environments.

Using the TrustKeeper scan engine, organizations can filter their results by the finding name "SSLv3 Supported" within their network scan results to build and maintain a working inventory, like so:

12194_de75b37b-9706-4109-9444-b99186f94fec

Another way for organizations to test for SSLv3 support on their systems is simply to connect to a service using OpenSSL's s_client functionality. This tends to be a bit more work because you need to know what services might support SSL and explicitly connect to them with openssl, like so:

  • openssl s_client -ssl3 -connect 192.168.1.1:443

If SSLv3 is supported, you will see "Protocol : SSLv3" present in the command output. If not, it will likely error and fail to connect indicating SSLv3 is not supported.

The manual route includes some challenges such as nuanced complexities with protocols that don't simply wrap the entire destination protocol in an SSL/TLS tunnel, e.g., SMTP, FTP-S, IMAP-S, and many others. For these protocols, you may need to supply additional command-line parameters to fully verify whether SSLv3 is supported, like so:

  • openssl s_client -starttls smtp -crlf -ssl3 -connect 10.70.33.110:25

Given these complexities, we strongly recommend that organizations make it easier on themselves by leveraging their existing vulnerability scanning technology to obtain and maintain their SSLv3 inventory.

Parting Thoughts

As mentioned before, many organizations' efforts to remove SSL configurations are already well underway. Those organizations that haven't started this process should know that upgrading from SSLv3 to TLS 1.1 or greater will soon become a PCI SSC mandate for organizations handling CHD. We look forward to providing further guidance and assistance to our customers and the community at large as they tackle this important transition.

References:

****UPDATE – April 14, 2015****

Today the PCI SSC has announced that the PCI DSS 3.1 update will be published and effective tomorrow.

This update makes the following summary clarifications about the use of SSLv3 and TLS 1.0 in PCI relevant environments:

  • New implementations must use alternatives to SSL and early TLS.
  • Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
  • Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration plan as an exception in the ASV Scan Report (in accordance with the ASV Program Guide).
  • Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and early TLS may continue to use these protocols as a security control after June 30, 2016.

****UPDATE – February 8, 2016****

The Payment Card Industry Security Standards Council (PCI SSC) announced in December that it is extending the migration completion date to June 30, 2018 for transitioning from SSL and TLS 1.0 communication protocols to a secure version of TLS (currently v1.1 or higher). The new date of June 2018 (replacing the June 2016 deadline) offers additional time to migrate to the more secure protocols, but waiting is not recommended. See the PCI SSC blog for more info: http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls.

Latest SpiderLabs Blogs

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More

Physical Address Strangeness in Spam

Ten years ago, Congress passed the "CAN-SPAM Act" (also known as theYou-CAN-SPAM Act, since it defined legal spam and supersedes any stricter state-antispam laws). One of the provisions of the act is...

Read More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising

During an Advanced Continual Threat Hunt (ACTH) investigation that took place in early December 2023, Trustwave SpiderLabs discovered Ov3r_Stealer, an infostealer distributed using Facebook...

Read More