What happens to those of us not in control of or own servers come end of May when most of Cloudlflare's TLSv1.2 cyphersuites end up failing our ratings on https://www.ssllabs.com due to semi-new POODLE variants?

dash-crypto
#1

As I initially posted this within another posting, and still have yet to receive a satisfactory answer, I’ve created this new topic:


Continuing the discussion from SSLlabs checker results


#2

I presume you are referring to the Qualys blog post. It states that they will F grade sites that have listed vulnerabilities. You can test what this will look like on their Dev site (https://dev.ssllabs.com/ssltest/analyze.html?d=intr0.com)

Using the dev test site, your intr0.com site and some of my own get A+ ratings. For the specific vulnerabilities most sites I tested show as ‘Unknown’. One of my hosts with a custom certificate shows as not vulnerable.

If you have an enterprise account you can request a specific set of cipher suites. (see https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites/)

1 Like
#3

Thanks for the link to their development version; however, and this is of most import, the particular ciphersuites are WEAK. At the end of the month, the weak ciphersuites will result in failing grades. While I appreciate that Enterprise customers are able to select which ciphers they wish to use, I highly doubt most sane persons would consider paying that sort of premium beyond what they’re already paying simply to have Cloudflare give a darn about the ciphersuites they enable and their vulnerability to new attack vectors. The reason the “unknown” is stated is for one reason: the deadline given to allow servers to deal with the issue. If anyone has an answer that does not include either becoming an Enterprise customer, I’d appreciate it.

(Attachment publicKey - [email protected] - ca04f762bf69348d05e30d2bde125b4e2d10e361.asc is missing)

#4

[[Citation needed]]

#5

Recently new vulnerabilities like Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL and Sleeping POODLE were published for websites that use CBC (Cipher Block Chaining) block cipher modes. These vulnerabilities are applicable only if the server uses TLS 1.2 or TLS 1.1 or TLS 1.0 with CBC cipher modes.

SSL Labs identifies cipher suites using CBC with orange color and with text WEAK. This change won’t have any effect on the grades, as it only means that SSL Labs discourages the use of CBC-based cipher suites further.

SSL Labs will start giving “F” grade to the server affected by these vulnerabilities from end of May 2019. For now, SSL Labs will give only a warning for affected servers:

⁃	Zombie POODLE (Invalid padding with valid MAC)

⁃	GOLDENDOODLE (Valid padding with an invalid MAC)

⁃	0-Length OpenSSL (Invalid Mac/Valid Pad, 0-length record)

⁃	Sleeping POODLE (invalid padding with valid MAC)

https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities

Additionally, this is not something only about which a single security company has been warning. How many citations do you need before you believe another paid use of Cloudflare?

(Attachment publicKey - [email protected] - ca04f762bf69348d05e30d2bde125b4e2d10e361.asc is missing)

#6

The Qualys article says the following:

SSL Labs identifies cipher suites using CBC with orange color and with text WEAK. This change won’t have any effect on the grades

Yes there are weak cipher suites, but they are generally needed to support current browsers, apps and devices. However, they will not alter the SSLLabs rating.

#7

Citation Needed.

I’d prefer to no longer continue what is an essentially useless debate. No solutions have yet been offered, only misleading statements. Your statement that cipher block chaining is necessary to support current browsers it is flatly incorrect and misleading to anyone reading it.

#8

Shouldn’t a site that’s going to be affected show the Dev scan warning from the blog post?

1 Like
#9

Unknown is the default value when the test starts and it is equivalent to Failed
Regards,
Nauman Shah

#10

Moreover, as further evidence re: unknown, I’m attaching screenshots of the most recent scan of my Cloudflare domain - https://intr0.com/

And a domain served via GitLab’s Netlify integration (which is a free site) - https://intr0.cf/

#11

This was already asked. Unkown is equivalent to failed.

(Attachment publicKey - [email protected] - ca04f762bf69348d05e30d2bde125b4e2d10e361.asc is missing)

#12

Thanks for the clarification. I’m attaching a screenshot for my test domain on a free plan. It has one of the newer sni certs from Cloudflare. My Pro plan site with the old snlXXXXX cert shows Unknown.
https://dev.ssllabs.com/ssltest/analyze.html?d=b8a.me&s=104.27.159.123&hideResults=on

#13

I just looked at the intr0 domain scan. You’re paying for one of the dedicated certificates with custom hostnames? It looks pretty new, too. I don’t feel like forking out $5 or $10 to experiment with dedicated certificates. Have you asked Cloudflare Support about this?

I’m going to hazard a guess that paid plans and certs include “legacy browser support” which is the cause of this failure. But that’s just a guess.

#14

What’s interesting is that I am only using the dedicated cert, so my domain/subdomains are not using one of the the older snlXXXXX certs. That being said, if I enable the universal free cert, TLSv1.0 is auto-enabled, despite my minimum TLS version that is set. That was an issue I encountered in the past that was only remediated by disabled the universal cert. In regards to the dedicated cert, nowhere does it state, unless I disregarded it at the time, anything about legacy browser support. I am open to suggestions moving forward. Thank-you.

Not so far for reasons of past experience.

#15

My free plan test site linked above is set to TLS 1.2 minimum and 1.3 is Enabled+0RTT

My Legacy Browser support comment for paid certs is a theory based upon Paid Plans including legacy browser support. Maybe someone else has seen this documented somewhere.

#16

After digging through the related docs, apparently paid certs do have built in support for legacy browsers. That in itself is fine but to not offer a way for people who do pay for certs to disable legacy browser support seems contrary to paying for certs. I’m going to have to run a test using another domain as you did and see the results. :v:t3:

1 Like
#17

Does this part of the crypto tab help:

#18

I’m not an enterprise user.

#19

https://www.ssllabs.com/ssltest/analyze.html?d=fucknazis.cf&hideResults=on

It’s a bit crazy that free certs offer better protection than paid certs…

#20

Me neither, that’s on my business account.