Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
leonardocuei opened this issue Dec 8, 2020 · 7 comments
Open

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

leonardocuei opened this issue Dec 8, 2020 · 7 comments

Comments

@leonardocuei
Copy link

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
Copy link
Owner

rbsec commented Dec 11, 2020

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
Copy link
Author

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:

image

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 ...)

image

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

@jtesta
Copy link
Contributor

jtesta commented Dec 11, 2020 via email

@rbsec
Copy link
Owner

rbsec commented Dec 11, 2020

@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
Copy link
Author

leonardocuei commented Dec 11, 2020

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
Copy link
Author

@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
Copy link
Author

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants