highlight CBC ciphers also on TLSv1.0/1.1/1.2

[leonardocuei]

by the README, seems highlighting CBC ciphers on SSLv3 is already done. Would it be possible to, somehow, highlight CBC ciphers on TLSv1.0/1.1/1.2 as well?

Thanks!

[rbsec]

Hi @leonardocuei

Currently CBC ciphers are left as white (unless they have known issues), whereas better modes like GCM are flagged as green. I'm certainly option to the idea though - there are a couple of open issues like #225 and #230 for potential changes to the warning levels on output.

@jtesta do you have a strong feeling either way?

[leonardocuei]

Hi @leonardocuei

Currently CBC ciphers are left as white (unless they have known issues), whereas better modes like GCM are flagged as green. I'm certainly option to the idea though - there are a couple of open issues like #225 and #230 for potential changes to the warning levels on output.

@jtesta do you have a strong feeling either way?

Got it ... tried scanning for TLSv1.0 on a test box, in which I know I have only CBC ciphers enabled, all ciphers are really left as white:

While scanning for TLSv1.2, I see those same TLSv1.0 ciphers as white, but I also see other two in white, and they even list GCM in their names, which I believe indicated they are not CBC by any means (I might be wrong ...)

Can a cipher be CBC and GCM at the same time?

[jtesta]

@jtesta do you have a strong feeling either way?

CBC doesn't have any practical issues to it, but it does have theoretical ones. Firstly, there's a history of implementation pitfalls, and while all supported implementations mitigated them, might there be more in the future? Secondly, it doesn't afford any built-in integrity checking like GCM or CCM. Authenticated encryption (AE) used to be considered fancy years ago, but these days its more considered to be standard... meaning non-AE ciphers are starting to look old & busted.

But LOOKING old & busted and BEING old & busted are two different things. Lately I recommend that new systems be set up with AE ciphers only, and I've been warming up to the idea of issuing minor warnings for non-AE ciphers (based on the rationale of modern-day best practices and the history of implementation flaws).

So I'd support flagging non-AE ciphersuites in sslscan. People setting up new systems can safely disable them without side-effects; this would also grant them some future-proofing as well.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[rbsec]

@leonardocuei, ah that's my mistake. Not all GCM ciphers are flagged as green - only the ones that support perfect forward secrecy (indicated by the DHE or ECDHE in their name) are flagged as green. There's not really any reason to be using non-FPS ciphers any more, but you can argue that non-FPS isn't really a weakness (as long as you're aware of the implications).

@jtesta that makes a lot of sense - I'd certainly prefer AE ciphers where possible, but I'm hesitant to flag them as yellow (which puts them in the same kind of category as things like RC4) when there aren't really any actual exploitable (even by TLS standards) issues with them.

[leonardocuei]

I was interested on finding which were the CBC ciphers on my servers because lots of 'security scanners' are now pointing CBC ciphers as insecure with medium or even high severity. I really don't know if there are any practical problem with them, I must confess. I'm chasing them because they were listed on some pentests of servers I'm the admin.

Maybe just changing the cipher names and adding the "CBC" in their names would be more than enough for clearly pointing them. How about that?

[leonardocuei]

@leonardocuei, ah that's my mistake. Not all GCM ciphers are flagged as green - only the ones that support perfect forward secrecy (indicated by the DHE or ECDHE in their name) are flagged as green.

OK, that explain why they weren't green, got it, thanks for the clarification.

[leonardocuei]

@jtesta ..... People setting up new systems can safely disable them without side-effects; this would also grant them some future-proofing as well.

The only real use I can think for keep them is to maintain support for old clients, which will likely imply on keeping TLSv1.0 active, in which CBC ciphers are the best anyway (the other ciphers are all RC4).

Besides from that case, I agree there's no need to keep them active (despite, as said, there's no practical attack on them yet)