1 of 1 people found this helpful
Yes, TLS1.0 + TLS1.1 support is needed. There are public servers with these version of SSL. I can see even servers with SSLv3 :-)
Thank you for your answer Lubomir. So they're just to make sure that we're able to "securely" talk to those public servers you mention. i'd think those servers and the TLS connections made with them might be seen as unsecure.
SSL3.0 is obsolete, no?
1 of 1 people found this helpful
Thought I'd chime in on this one since I now have three different cert-verify configurations. One I'm tailoring to look as much like recent browser versions as possible (the strongest), one requiring strong encryption, and one that still allows SSL v3 for (ick) destinations considered essential but not keeping up with security (oh, the irony).
The point is that you don't have to get one configuration to be exactly perfect for everything, as you can have more than one.
I am finding that there are destinations that won't accept any of these configurations--and be warned, that the error message still says it's an SSL 3 problem, when SSL 3 is not checked in the configuration. The TLS handshake failure doesn't really contain that information. So, it's a matter of hacking to see if I can figure out what will be accepted.
Anyway, I take it that some sites are implemented with MiTM detection now, to whatever extent that's possible. I'm still studying what is present in a client helo that could be considered a red flag. And, I suppose MiTM detection is good, but it makes things hard for those of us with DLP requirements. It's something I think the industry will have to better address in the future.
This is my current setup or I should say it's the setup that came with MWG out of the box for me. When does the alternative handshake take over? Is that if client and server are unable to agree on a cipher suite to use in the establishment of their SSL tunnel?
I've seen multiple instances of SSLv3 web sites or others that just don't negotiate well with a TLS 1.0 and up only environment (mostly because I've turned off alternative handshake or "Allow handshake and renegotiation with servers that do not implement RFC 5746" options)
My CA settings currently have "Perform unsecure renegotiations" AND "Allow legacy signatures in the handshake" de-selected. I hope that won't cause any issues but i haven't heard any rumblings. (Also can't remember if this was a default setting or not).
I see. Thanks for this idea. I've only created extra SSL Scanner based settings for testing purposes. Ideally, I'd like the MWG to also steer our users away from sites that lack the required security infrastructure in order to keep both the users and the company safe, but it seems that's an uphill battle with so many websites using outdated protocols.
I may have to look into the multi-setting config. What's the criteria in MWG for each setting though? Would you identify sites that are running old protocols, e.g. SSLv3, and then use those sites (URL, domain, etc) as criteria for the setting and then try to make the most secure connection possible, given what the site offers?
Right, you end up maintaining an exception list, and no destination goes on the exception list until they've been vetted for importance and risk.
Don't forget, there's a difference between allowing and requiring. Negotiation should result in the strongest combination that is common between the client helo and the server helo -- even if weaker aspects are allowed.
My recent looks at what current browsers are doing is that the using relatively short cypher-suite lists, leaving out a number that OpenSSL regards as strong. I've only seen a couple that might be seen as medium strong. If web sites aren't keeping up with these things, they're loosing users.
What I expect will be the most contentious will be old automated services that are past due for an update. Do what you can to force them to get their stuff updated. Any exceptions should loudly be declared TEMPORARY.