a quick word about this SSL 3.0 vulnerability and Exchange Server, as there is nothing specific to Exchange regarding our recommendations.
Microsoft Suggested Actions to mitigate or eliminate the SSL 3.0 vulnerability are to disable 3.0 usage on clients (browsers, devices) and servers, although this vulnerability is not a huge security threat, in the sense that the attacker must show up in the middle of a Client <-> Server SSL session to perform his attack and as per the below mitigation factor from the Technet’s vulnerability detailed description:
· The attacker must make several hundred HTTPS requests before the attack could be successful.
· TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.
Then, disabling the use of SSL v3 on the client will prevent all clients to use SSL v3.0 to establish SSL channels, these will use TLS instead; the consequence of this is for services (applications servers) who don’t support TLS, who only rely on SSL 3.0 for SSL encryption => clients/browsers without support of SSL v3.0 won’t be able to access services using SSL v3.0 only; they just won’t understand other SSL encryption protocols than SSL v3.0. Exchange Server supports TLS for SSL channel encryption and then can work without SSL v3.0 as it is doing by default.
So to understand the differences between both, here is the Technet’s description which is okay to take paste here (just to not reinvent the wheel):
What is SSL?
Secure Sockets Layer (SSL) is a cryptographic protocol that provides communication security over the Internet. SSL encrypts the data transported over the network, using cryptography for privacy and a keyed message authentication code for message reliability.
What is TLS?
Transport Layer Security (TLS) is a standard protocol that is used to provide secure web communications on the Internet or on intranets. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It also provides a secure channel by encrypting communications. TLS is the latest version of the Secure Sockets Layer (SSL) protocol.
So disabling SSL V3.0 on the Windows Server hosting Exchange server application won’t affect classical Exchange services, it will only prevent clients that cannot/don’t “speak” TLS (who speak SSL 2.0/3.0 only) to connect to Exchange services using SSL channel.
All the other clients such as Outlook and IE will continue to work seamlessly with the Exchange services.
Disable SSL 3.0 in Windows
You can disable support for the SSL 3.0 protocol on Windows by following these steps:
1. Click Start, click Run, type regedt32 or type regedit, and then click OK.
2. In Registry Editor, locate the following registry key:
HKey_Local_MachineSystemCurrentControlSetControlSecurityProviders SCHANNELProtocolsSSL 3.0Server
Note If the complete registry key path does not exist, you can create it by expanding the available keys and using the New -> Key option from the Edit menu.
3. On the Edit menu, click Add Value.
4. In the Data Type list, click DWORD.
5. In the Value Name box, type Enabled, and then click OK.
Note If this value is present, double-click the value to edit its current value.
6. Type 00000000 in Binary Editor to set the value of the new key equal to “0”.
7. Click OK. Restart the computer.
Note This workaround will disable SSL 3.0 for all server software installed on a system, including IIS.
Note After applying this workaround, clients that rely only on SSL 3.0 will not be able to communicate with the server.
Details about the POODLE attack on the SSL 3.0 vulnerability:
One of the security researchers says as well:
“The conditions that are required for the attack to be applicable are hard to obtain. In particular, the attacker needs to become a man-in-the-middle between the attacked client and server, and to generate, block and modify client messages to the server and vice versa.”
Testing your client vulnerability to Poodle attacks/hijacks:
Hope this helps you understand a bit better what’s up with Exchange and this SSL 3.0 vulnerability,