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 suite server preference misidentified #10

Closed
exploresecurity opened this Issue Oct 28, 2014 · 4 comments

Comments

2 participants
@exploresecurity
Copy link

exploresecurity commented Oct 28, 2014

Had a discrepancy between SSLyze and SSLscan over preferred cipher suite for SSLv3. SSLyze thought it was RC4-SHA, SSLscan thought it was DES-CBC3-SHA. Running OpenSSL with -ssl3 returned DES-CBC3-SHA. Also running openssl s_client -ssl3 -cipher DES-CBC3-SHA:RC4-SHA and then openssl s_client -ssl3 -cipher RC4-SHA:DES-CBC3-SHA both returned DES-CBC3-SHA. So it looks like SSLscan was right. Looking into this with Wireshark I can see that individually DES-CBC3-SHA was tested but, when it came to determining preference, DES-CBC3-SHA was missing from the full list sent up in the Client Hello so the server couldn't choose it. I'm afraid I can't provide the target server as it was part of a pentest.

@exploresecurity exploresecurity changed the title Preference misidentified Cipher suite server preference misidentified Oct 28, 2014

@nabla-c0d3

This comment has been minimized.

Copy link
Owner

nabla-c0d3 commented Oct 28, 2014

The cipher suite preference test is not 100% reliable anyway (and on SSLscan as well) because the server may not have a preference set, in which case it will pick the first cipher within the client's list of supported cipher suites. It's an indication but not something you should rely on.
What does SSL Labs say for the server you're testing?

The reason why DES-CBC3-SHA isn't sent within the preference test is that specific servers will not reply at all if the client hello is larger than 255 bytes (due to a bug in a specific brand of load balancers). To reduce the size of the hello, I had to disable some stuff including specific cipher suites.

@exploresecurity

This comment has been minimized.

Copy link

exploresecurity commented Oct 29, 2014

Thanks for the reply. SSLyze would know if the cipher suite chosen was the one at the top of the list and could then send a second Client Hello with that cipher suite further down the order to check. On the point of the buggy load balancers (life is never easy, is it?) a further Client Hello could be sent. If a preference seemed to be expressed from the first set, that cipher suite could be included with the remaining set. I guess this all adds overhead and you may have chosen to skip this kind of work in favour of speed, as in the majority of cases SSLyze should get it right.

@nabla-c0d3

This comment has been minimized.

Copy link
Owner

nabla-c0d3 commented Oct 29, 2014

Yes I thought of adding the exact check you described but that's pretty much at the bottom of my TODO list...

@exploresecurity

This comment has been minimized.

Copy link

exploresecurity commented Oct 29, 2014

I thought as much! Thanks for continuing to maintain the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment