Set Minimum TLS to 1.2 but still failing PCI scan for TLS 1.0 being enabled

#1

We’re still new to Cloudflare and have been using it about a month now. Our ecommerce site recently failed a PCI scan because TLS 1.0 was enabled. I found the Cloudflare Cryto setting for “Minimum TLS Version” and set it to 1.2. A few days later we ran another PCI scan and once again failed due to TLS 1.0 being enabled.

Our server developers ran OpenSSL commands today and verified that we are seeing successful connections to CLoudflare over TLS 1.0, 1.1 and 1.2. They also ran the curl utility which did not return anything for TLS 1.0 or 1.1, but our AVS will not mark this as a pass since we can still connect with OpenSSL.

Out of curiosity, I also ran a scan on this site:
www.ssllabs.com

In these results, TLS 1.1 is not enabled, but TLS 1.0 is enabled. When I hover over the TLS 1.0 results on this page, I receive this message: “TLS 1.0 support observed only with client that does not support Server Name Indication.” Here’s a screenshot:

Can anyone provide some insight as to why TLS 1.0 still appears to be enabled via OpenSSL even though Cloudflare is set to minimum TLS 1.2? Is there another configuration setting I’m missing, or could it be that it take more than a few days for the minimum TLS setting change to fully take effect?

Thanks in advance!

#2

Cloudflare changes should take effect right away.

What’s the domain?

#3

Was brought earlier.

#4

Here’s our domain:
https://softstarshoes.com/

#5

Thanks! We’ll try this.

#6

That certainly seems to be a mis-read of the certificate. Dunno why, though. Their listing farther down doesn’t even mention 1.0. And this test also shows 1.2 and 1.3 only:
https://www.immuniweb.com/ssl/?id=cBAdpUcD

You also say you’ve set minimum to 1.1, but that doesn’t show up in either test.

#7

Minimum was actually set to 1.2.

#8

Sorry, you did mention 1.2 Minimum twice. I mixed that up with the linked post just a few posts up from my reply.

#9

No worries :slight_smile:

We’re using Clouldflare’s Pro subscription, so our devs think this explanation in the link shared by @adaptive may be our solution:

The “Minimum TLS Version” setting does not apply to Universal SSL on Pro domains because they share the IP space with other domains. This mean any changes to Universal SSL will affect other customer that did not opt in to disable TLS 1.0.

In order to disable TLS 1.0, you have the following option:

1.) Purchase a dedicated certificate then disable Universal SSL. This allows you to control the minimum TLS version as the certificate is dedicated to your zone.

2.) Upgrade to our Business plan. Business plan IP space is not shared with other zone, allowing you to control the minimum TLS of the Universal certificate.

3.) Use Cloudflare Workers to deny TLS 1.0 request. This allows granular control over which TLS version and cipher you want to allow.
ref: https://developers.cloudflare.com/workers/about/how-workers-work/
https://developers.cloudflare.com/workers/recipes/tls-version-blocking/

We’re going to try #1 and purchase a dedicated certificate, then disable universal SSL. I’ll follow up here if it works or not.

1 Like
#10

Well, atm i can’ t second that. This one is a free so, with Universal SSL. What i am not sure about is, if this is a glitch because I have a business site within the same account. But i don’t think so.

And as @mnordhoff stated in the same thread, shared IP shouldn’t be an issue.

#11

Did u try any other SSL test other than ssllabs. Try this https://www.cdn77.com/tls-test

#12

Does site ssl needs to be HIPPA compliant?

#13

could be ssllab bug in how it’s reporting the client simulations for TLS 1.0 connections as testssl test reports same for @mkarl17 showing TLS 1.0 but it properly lists the clients = IE 8 XP and Java 6u45 that are served via TLS 1.0 which shouldn’t be. @mkarl17 i’d contact Cloudflare support to get someone to look at it.

testssl --openssl=/usr/bin/openssl -p -c https://www.softstarshoes.com/  

###########################################################
    testssl       3.0rc5 from https://testssl.sh/dev/

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.1.1b  26 Feb 2019" [~79 ciphers]
 on test:/usr/bin/openssl
 (built: "Apr  3 10:50:23 2019", platform: "debian-amd64")


Testing all IPv4 addresses (port 443): 104.25.247.104 104.25.248.104
-----------------------------------------------------
 Start 2019-05-15 15:02:41        -->> 104.25.247.104:443 (www.softstarshoes.com) <<--

 Further IP addresses:   104.25.248.104 2606:4700:20::6819:f868
                         2606:4700:20::6819:f768 
 rDNS (104.25.247.104):  --
 Service detected:       HTTP


 Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

 Running client simulations (HTTP) via sockets 

 Android 4.4.2                TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305-OLD, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305-OLD, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      TLSv1.0 DES-CBC3-SHA, No FS
 IE 11 Win 7                  TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 IE 11 Win 8.1                TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 IE 11 Win Phone 8.1          TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 IE 11 Win 10                 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 12.1 (macOS 10.13.6)  TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    TLSv1.0 AES128-SHA, No FS
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-05-15 15:03:13 [  70s] -->> 104.25.247.104:443 (www.softstarshoes.com) <<--
1 Like
#14

That’s interesting. I wonder if your business site is making the difference, I didn’t mention it earlier, but I’m on the Pro account.

I tried toggling the minimum TLS version between 1.1 and 1.2 out of curiosity. I can verify it only takes a few minutes for the difference to show up in a TLS scan, but we still ended up with the same results.

#15

I tried this one and it showed TLS 1.0 and TLS 2.0 both as disabled. That seems good, along with the curl utility, but TLS 1.0 still shows up in ssllabs with the note "observed only with client that does not support Server Name Indication.” Since that scan is run by Qualys, who also runs our PCI Compliance scan, it seems to be the one that matters.

Does site ssl needs to be HIPPA compliant?

I’ll have to check with our dev about this.

1 Like
#16

Thanks for this! Unfortunately, since I’m on the Pro plan this forum seems to be my only source of Cloudflare support. Does anyone know another way to contact them?

#17

UPDATE: I purchased a dedicated SSL certificate today. At first it made no difference in the ssllabs scan. Then I found the option at the bottom of Cloudflare’s Crypto settings to disable Universal SSL. I disabled it so that we were only using dedicated SSL and ran the scan again. This time we passed!

1 Like
#18

from Community Tip - How Do I...Answers to Popular Questions

Contact Support
Login to Cloudflare and then contact Cloudflare Support

interesting though still feel that it’s a bug @cloonan might want to look at for Universal SSL with min TLS 1.2 set and still serving non-SNI clients via TLS 1.0.

1 Like
#19

Agreed. Our solution of purchasing a dedicated SSL works for us, but it still seems like there is a bug somewhere preventing the min TLS setting from working properly.

1 Like
#20

Hi @mkarl17, sorry for the issues with this and really appreciate the details. Did you follow the ticket links @eva2000 shared to loop in support? If you did and share ticket number, I can add in this conversation. (If not, to reach support follow those links and scroll to get more help to open a ticket.) I’ll dig some on the issue as well and see if it’s reported elsewhere.

Edit - Still digging, so far it looks like the steps @mkarl17 took are spot on as a work around for an issue with universal ssl. Now digging to see status of that.

Did find a good PCI article, I don’t know if it’s been shared on this site yet or not, https://support.cloudflare.com/hc/en-us/articles/202249734-Cloudflare-and-PCI-Compliance.

1 Like