Qualys SSL Scan weak cipher suites which are secure according to ciphersuite.info

The information on ciphersuite.info is not presented in the clearest of ways. Let's have a look at their FAQ:

What does insecure, weak, secure and recommended mean?

Weak

These ciphers are old and should be disabled if you are setting up a new server for example. Make sure to only enable them if you have a special use case where support for older operating systems, browsers or applications is required.

Secure

Secure ciphers are considered state-of-the-art and if you want to secure your web server you should certainly choose from this set. Only very old operating systems, browsers or applications are unable to handle them.

Recommended

All 'recommended' ciphers are 'secure' ciphers by definition. Recommended means that these ciphers also support PFS (Perfect Forward Secrecy) and should be your first choice if you want the highest level of security. However, you might run into some compatibility issues with older clients that do not support PFS ciphers.

So to be frank: Weak means these have problems and should be avoided at all cost. Only enable these if you know you really really have to. Secure means they're not technically broken, but they also don't offer any desirable features. Recommended means these are the ones you should actually use.

I would disagree with their statement about incompatibility. The only clients that do not support modern ciphers are already outdated clients and no longer supported anyways. These clients should be dropped unless you have a very good reason to support them.

Why are these ciphers in particular considered weak?

As Soufiane Tahiri pointed out in his answer, CBC ciphers and RSA ciphers are not considered state-of-the-art anymore.

CBC ciphers have quite a lot of problems, such as the mentioned Lucky 13 attack, or other side-channel attacks. CBC also violates Moxie Malinspike's Cryptographic Doom Principle:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

GCM, for instance, does not violate this principle, so it is vastly preferred.

RSA on the other hand does not support forward secrecy, which is a VERY useful feature when it comes to cryptography. Basically, with RSA, the server sends its public key, the client generates a random secret, encrypts it with the public key and sends it back to the server. The server then decrypts it with its private key. The following graphic from the Cloudflare Blog illustrates it well:

While this looks simple and secure, it does have one glaring weakness: If an attacker captures the initial key exchange and later gets the private key in some way, the can decrypt the previously captured traffic.

Cipher suites which support forward secrecy work in a different way. Instead of transmitting the secret over the wire, a key exchange protocol like Diffie-Hellman is used, in which the actual secret to be used is generated through mathematical means. I'll leave it up to the reader to see how it works exactly. The advantage is that the secret is ephemeral, meaning that it exists only for one session and that's it. Even with access to the private key and the entire communication, the secret cannot be determined. Furthermore, if the secret key used in one session is compromised, other sessions are still secure.

So what does this all mean?

In simple terms: Don't use cipher suites that Qualis SSL scan claims to be weak. You have no advantages in doing so.

All cipher suites based on CBC are vulnerable to Lucky 13 (and not only)

Qualys SSL Labs considers all ciphers that use RSA key exchange as weak (they do not provide perfect forward secrecy)

These are all pre TLS 1.3 ciphers. TLS 1.3 has a huge cleanup;

1. RFC 8446 section 1.2 :

   "Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy."

   The non-forward secrecy key exchanges are no longer considered strong. With forward-secrecy, the previously exchanged keys are protected. For this, you also need to delete the previous keys, otherwise, there is no forward-secrecy.

   Currently, the RSA exists only for signatures in TLS 1.3.

2. CBC mode is vulnerable to padding oracle attack in which the server can be used as a decryption oracle to reveal all of the messages. This was demonstrated many times:

    2004. Serge Vaudenay introduced padding oracle
    2012. Steam Breaking Steam Client Cryptography
    2013. Lucky Thirteen attack
    2014. POODLE
    2016. Yet Another Padding Oracle in OpenSSL CBC Ciphersuites,

Even you are using TLS 1.2 and TLS 1.3 together, you are vulnerable to downgrade attacks like The 9 Lives of Bleichenbacher’s CAT: and POODLE. The CBC mode is also removed from TLS 1.3, which has only 5 cipher suites, with these IDs:

1. {0x13,0x01} - TLS_AES_256_GCM_SHA384
2. {0x13,0x02} - TLS_CHACHA20_POLY1305_SHA256
3. {0x13,0x03} - TLS_AES_128_GCM_SHA256
4. {0x13,0x04} - TLS_AES_128_CCM_8_SHA256
5. {0x13,0x05} - TLS_AES_128_CCM_SHA2

Stop using pre-TLS 1.3 and apply patches whenever available. If you are restricted to use TLS 1.2 then remove these cipher suites. GCM with forward secrecy (DHE or ECDHE) is available in TLS 1.2 as RFC 5288 and RFC 5289.