Problem:
Is VisiBroker 8.5 vulnerable to the POODLE attack? How to avoid this vulnerability??
The POODLE vulnerability is just one of a number of weaknesses within SSLv3. Reference https://www.openssl.org/~bodo/ssl-poodle.pdf, which makes the broad statement that “SSL 3.0 [RFC6101] is an obsolete and insecure protocol”. SSLv3 should therefore be avoided to preclude the possibility of POODLE (or other) attacks.
SSLv3 has been replaced by its successors TLSv1.0, TLSv1.1, TLSv1.2 but many TLS implementations remain backward compatible with SSLv3 to inter-operate with legacy systems. The protocol handshake provides for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used. However, even if a client and a server both support a version of TLS, the security level offered by SSLv3 is still relevant since many clients implement a protocol downgrade dance to work around server-side interoperability bugs.
The attack for this vulnerability requires an SSLv3 connection to be established, so disabling SSLv3 in client or server (or both) will completely avoid it. If either side only supports SSLv3 this becomes a serious issue.
If SSLv3 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability.
To work with legacy servers, many TLS clients implement a downgrade dance: in a first handshake attempt, retry (possible repeatedly) with earlier protocol versions. Unlike protocol version negotiation (if the client offers TLSv1.2, the server may respond with TLSv1.0) this downgrade can also be triggered by network glitches, or by active attackers. So if an attacker that controls the network between the client and the server interferes with any attempted handshake offerring TLS v1.0 or later, such clients will readily confine themselves to SSLv3.
Resolution:
The solution is to disable SSLv3.
In order to disable SSLv3, VisiBroker for C 8.5 SP1 and SP2 can be configured as follows:
The vbroker.security.client.socket.enabledProtocols and vbroker.security.server.socket.enabledProtocols properties may be used to control the protocol levels available for the handshake negotiation at either end of the connection. In order to preclude the possibility of SSLv3 (or lower) being negotiated, use one of these values:
- TLS_Version_1_0_With_2_0_Hello
- TLS_Version_1_0_Only
Please note that the default value for both vbroker.security.client.socket.enabledProtocols and vbroker.security.server.socket.enabledProtocols is "SSL_Version_Undetermined". This is safe as long as both client and server support TLS, for example if they are both VisiBroker 8.5, and neither end is configured to disable TLS.
With VisiBroker for C 8.5 SP2 plus HF1 (DECO 10390) the list of options for the OpenSSL security provider will be extended as follows.
The vbroker.security.client.socket.enabledProtocols and vbroker.security.server.socket.enabledProtocols properties may be used to control the protocol levels available for the handshake negotiation at either end of the connection. In order to preclude the possibility of SSLv3 (or lower) being negotiated, use one of these values:
- TLS_Version_1_0_With_2_0_Hello
- TLS_Version_1_0_Only
- TLS_Version_1_1_With_2_0_Hello
- TLS_Version_1_1_Only
- TLS_Version_1_2_With_2_0_Hello
- TLS_Version_1_2_Only
Please note that the default value for both vbroker.security.client.socket.enabledProtocols and vbroker.security.server.socket.enabledProtocols is "SSL_Version_Undetermined". This is safe as long as both client and server support TLS, for example if they are both VisiBroker 8.5, and neither end is configured to disable TLS.
For the VisiBroker 8.5 SP2 Certicom provider the recommended property values for disabling SSLv3 are as per VisiBroker 8.5 SP1.
For more information regarding these specific property values, please refer to the VisiBroker Security Guide appropriate to your version.
#securitypoodle
#Security
#VisiBroker
