-
Notifications
You must be signed in to change notification settings - Fork 33
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
Cipher strength is only key-dependent #8
Comments
I'm not a cryptologist and I know many others are not as well. I like the idea of a cipher "strength" evaluation but it's error prone. I feel uncomfortable evaluating strength of these ciphers myself. The idea of a simple evaluation system is attractive me and my reason for looking the Mozilla project. See Improvement 1 of the feature map for the next release I include, Improvement 1, Improve Analysis of Ciphersuite strength evaluation Ideally, I would like source somewhere that lists all IANA cipher suites with a strength indicator I can include for DeepViolet. This way I don't have to guess or track the opinion of every cryptologists. Also I like your recommendation about including key length. Is there any other source besides Mozilla you recommend? |
I didn't take a look at your feature map, sorry. Besides Mozilla's recommendations, I do not know a list of all IANA ciphers and security evaluations, so I'd stick with Mozilla's database. When writing the bug report, I forgot to mention that the handshake protocol is also important for security. For example, SSLv3 is deprecated because it's considered insecure (RFC7568). Therefore, evaluating the security of the connection (handshake + hashing + cipher + cipher mode) rather than the academic security of a cipher may be a better approach. |
Good catch, I will add this to my list as well. I knew this area needs some improvement. |
Not sure what your interests are in DV or how your using it. But if your interested, take a look at the next round of features for delivery. I'm interested to know if you think the list looks interesting to you. Beta 5 |
I'm not sure what you are meaning with this. I'm integrating DV into a project I'm working on, but it's not a required or important feature. Maybe I can find some time to work on the connection security evaluation. If you are interested I can also take a look at your code before releasing your next Beta. |
Since you have some understanding of DeepViolet, I'm interested in your thoughts on how I could improve the project features and make it more useful to everyone. If you don't have any immediate thoughts it's ok. Either way, I appreciate your interest in the project. |
Well, the ultimate goal would be to provide a tool with the same capabilities as Qualys SSL Labs SSL Server Test. I'd leave the overall rating and evaluation to the user, but provide features like a heartbleed check and so on. I came across DeepViolet because it's written in Java and Apache licensed, so it was suitable for integrating it in a larger-scale enterprise project. Personally, I wouldn't spend any time on user interfaces (or split them to separate projects only accessing the API jar) but that's up to you. All other features from the feature map seem reasonable to me. |
Qualys labs is my inspiration. Ivan and his team have done a wonderful job building that scanning suite. There is a lot of investment in that tool so I'm not sure DeepViolet will ever be as good as the Qualys scanning tool. However, your comment about DV being Java based tool and Apache license is interesting. The OWASP ZAP project reached out to me about including DV for the same reason, Overhaul HTTPS Info Addon #2532. They mentioned to me there's not a lot of good Java TLS/SSL tools. Hard to say when/if ZAP integration will happen but if so perhaps it could simulate some interest on this project - exciting stuff. Once again, thanks for your interest and suggestions. ;o) |
I'm going to call this issue closed. |
DeepViolet reports
RSA_WITH_RC4_128_SHA(0x5)
as a strong cipher. During the past years a few attacks against RC4 applicable in real world scenarios came up and the cipher is therefore considered broken. SHA1 is neither considered a good choice nowadays. Security evaluation of algorithms should not only include key length, but also a black list of broken/insecure ciphers and hash algorithms. At least the documentation forgetStrengthEvaluation()
should clearly state that this evaluation is currently only key-size dependent and does not take the cipher/hashing algorithm into account.The text was updated successfully, but these errors were encountered: