If you import the SSL Scanner rule set from library you have the client and server cipher lists already included that we recommend.
Example ("Default Certificate Verification"):
Is RC4 support really recommended though? The reason I ask is that our compliance group is complaining about the results from badssl.com which shows support for RC4 and DH1024.
RC4 is placed at the end of the list and the cipher list is sorted by strength (order of encryption algorithm key length).
It is more a fallback (if the server rejects ALL other before).
It would be nice to have McAfee's recommendation, but I think it's important to know what is being done for the more secure browsers on the Internet, such as Chrome and Firefox.
I posted the following elsewhere (as a cipher-suite spec example), but it really belongs here:
I recently did a workup of a cipher-suite spec. for our configuration. This it based on cipher-suite listing provided at: Qualys SSL Labs - Projects / User Agent Capabilities: Firefox 49 / Win 7
After tinkering with openssl cipher command, this is what I came up with:
Note that minus-sign in the spec. is a little different than the exclamation point. To get the best match, I had to use a minus on ECDH and then add ECDHE back in. You can't do that the the exclamation point.
So, I believe this excludes all CBC (Cipher block chaining) suites which now have a weakness, but it also seems to exclude all plain vanilla DH suites.
Note that there were a couple of cipher suites available in the latest Firefox and Chrome version that are not available in Web Gateway. I don't remember what they were, but it's easy enough to figure it out if anyone's interested.
Hi John! Thanks for the information. I guess in it's most basic form you would want to strike a balance between security and still being able to access the sites that are required for business.
It looks like you took the approach of finding out what your users browsers support natively and then tailoring the MWG server side ciphers to match. Is that correct?
As for McAfee's recommendation it looks like mkutrieba is a member of the McAfee tech support team so I'm assuming his recommendation (the default for the SSL scanner ruleset) is what they would normally recommend. Doesn't seem like its good enough for our internal compliance folks though. They're not only complaining about MWG server side supporting RC4, DH1024 and 3DES, but also mixed-script and various HTTP-input methods. Might be easier to just unplug...
Google and Firefox have been working really hard to give us security. With each new version, the cipher-suite specs get further trimmed down to exclude any weak or vulnerable ciphers. That report gave the BlueCoat proxy the highest grade, noting that BlueCoat's proxy has a feature that passes the cipher-suite list from the browser through to the server. MWG wasn't reviewed, but if you really wanted to keep up with the choices that Google and Firefox are making, then you should replicate their security settings in your proxy settings, and update those settings each time Google and Firefox update their specs. Is everybody doing that?
Worst case, is that that some proxies don't block or coach basic certificate security problems, like the first five at badssl.com. Browsers block for those things, and you have to click through or add an exception for site you want to trust.
If a proxy does nothing to alert or protect a user from a self-signed certificate, then the user could be stumbling into a malicious HTTPS site, and the browser says "Secure" (Chrome), for what is the proxies certificate.
Every time Chrome and Firefox up the security controls but a proxy isn't updated to keep up with that, the users are left in ignorance that the publicly know security in their browser isn't really doing what it's supposed to--because a proxy is effectively weakening that security silently.
People are going to be blindsided.
... and the complexities of this and the need to keep up with discovered vulnerabilities and weaknesses, that old recommendations from support desks are outdated and not good enough. This is something that needs to be addressed by TLS experts. And, yes, your security team is working from the risk assessment of your organization. I won't tell you to go against them. If anything, exceed them. If a web service doesn't work with what exists in the latest versions of Chrome and Firefox, then users should have to open a ticket to get it looked at. I don't like to be rough on users, but it breaks a sacred trust to have a proxy that hides it's weaknesses from users, leaving them vulnerable to being blindsided.