There is a new SSH problem, the RSA_EXPORT cipher suites should be detected.
Dev Version now respond to Freakattack
<customer name removed>
Export 40 = red / insecure
@Ivan Dev 1.14.6 did not mark Export 40 as insecure, yet
E.gQualys SSL Labs - Projects / User Agent Capabilities: IE 6 / XP
The RSA_EXPORT cipher suites are currently marked as WEAK.
I think they can no be considered as INSECURE.
Tracking the TLS FREAK Attack
I have tested a device that offers RSA_EXPORT suites.
Warning! Your client is vulnerable to CVE-2015-0204. Even though your client doesn't offer any RSA EXPORT suites, it can still be tricked into using one of them. We encourage you to upgrade your client.
Wow, what a stupid test. My client offers three 56-bit suites and four 40-bit EXPORT suites.
That awkward moment when an oline-banking server forces 56-bit encryption and supports EXPORT.
Qualys SSL Labs - Projects / SSL Server Test / online.akbank.de
<see ssllabs-results attached>
That is a perfect example of why we need grades lower than an F ...
How does any bank get away with such a shocking lack of security?? It's not even a bank in the developing world, but one of the world's biggest economies.
FYI, the UA Capabilities page has now been updated to mark 512-bit export ciphers insecure: Qualys SSL Labs - Projects / User Agent Capabilities: IE 6 / XP
How about Export 56bit they are scored as "weak" in DEV.Should they not might also be insecure ? (and 112bit 3DES scored as weak ?)
and 112bit 3DES scored as weak ?
Please explain. This is the last secure cipher for Internet Explorer on Windows XP (not taking into account that XP doesn't support PFS), and I hope there are no issues.
The long story is that this should have been caught by the changes in the rating guide in January 2014, but I failed to implement it properly. It's now documented as a bug and fixed in the development version.
I must have missed something, why are all cipher suites using DHE now marked as weak?
They should only be marked as weak if the server uses a DHE temporary key size below 1024 bits, in which case it looks like this:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 768 bits (p: 96, g: 96, Ys: 96) FS WEAK 256
DHE with key sizes of 1024+ are not being marked as weak for me.
Well that explains it, although it appears to actually affect all key sizes <= 1024, and not only those less than 1024.
Rolling out 4K dh param file now ...
4k is too slow, use 2k
I'll use 2K only if you promise that you won't deprecate 2K keys in the next 12 months
Even if 4096-bit RSA is used on all my servers? Nice try, someone has replaced Ivan with an NSA guy .
Is that on the dev server? I would expect a 768-bit suite to be red/insecure. Suites with DH params >= 1024 and < 2048 should be orange. If that's not the case on your server, please send me the hostname. Thanks.
Suppose you wanted to TAG all devices with "Weak Protocols" here is one method you could try with Groovy scriptlets and TAGS in Qualys.
Create a TAG with the scriplet below and it will tag any device offering any of those methods.
Add as many as you want and it will return on the first hit.
// Skip testing on non-VM hosts.
if(asset.getAssetType()!=Asset.AssetType.HOST) return false;
protocols = asset.resultsForQid(38116L);
if(protocols.contains("SSLv3_PROTOCOL_IS_ENABLED")) return true;
if(protocols.contains("SSLv2_PROTOCOL_IS_ENABLED")) return true;
if(protocols.contains("TLSv1_PROTOCOL_IS_ENABLED")) return true;
It would probably be nice if FREAK test is added in "Protocol" section in the bottom of SSL test. I performed SSL test for many servers on development SSLtest-server and non of them was having problem. I looked at "Protocol" section and no info was there about FREAK, so I thought FREAK was not implemented by SSL test yet. So my suggestion add FREAK at "Protocol" section.
after it was found 3DES 168bit is only like 112bit this is less than the minimum suggested 128biteven https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf says <128bit should only get 20% (but currently 112bit seems to be ignored and get 80% like 128bit)
says <128bit should only get 20%
This is true for 0, 40 and 56 ciphers, but not for 3DES. Chrome, Firefox and SSL Labs state it is 112-bit. Internet Explorer and GlobalSign — 168-bit. Currently, there is a huge power consumption issue. What about security (other than 112 VS 168 meet-in-the-middle)? I am really interested.
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf3DES is not stronger than 112 bits.So it might be considered as weak (if 40/56 are insecure) but this is a suggestion onlySo maybe the Rating Guide forgot the 112bit when mentioned <128 = 20% cause target 40/56 only
I combined some score related Topic here
suggestions to update the scores
just noticed ssltest (1.15.1) incl freaktest and fixed weak (1024) DH key score is now not dev any longerSSL Server Test (Powered by Qualys SSL Labs)
I know I'm late to the party, but we should not forget a SSL/TLS scanner is not so much for features but for security. From security point of view 3DES is not weak at all. It provides a 168bits brute force protection which is deep, very deep, into the secure realm. The 112 bits only refers to the fact that a theoretical attack exists where you can exchange, and note not eliminate but exchange, calculations for storage. The idea is that one pre-calcules one of the three DES layers and 'only' brute forces the other two. As Adm Selec indocates this is the meet in the middle attack.
But besides the fact one still needs to crack 112 bits (which is still even for super computers not possible) one also needs massive, and we are talking large data center size, storage. Hence this is mostly an academic exercise and not a practical attack. (For attackers that don't have access to such large storage, one should even argue 3DES is stronger than AES 128 when strictly looked in terms of brute force protection.)
So 3DES should not be flagged as weak, as it simply isn't. It is in fact the recommended cipher for servers that must still support older clients that don't yet support AES.
The only reason AES is prefered towards 3DES is that the latter is slow. On a typical software implementation we are easily talking 4 times slower. As Adm Selec indicates, that has power effects as well. But flagging 3DES as 'weak' would reduce the test from a security test to a feature test. I personally hope Qualys never goes there.
Retrieving data ...