* Jaya Nageswar: > We have a library which is built on top of openssl 0.9.8 (now incorporated > the openssl 0.9.8zc related changes for TLS_FALLBACK_SCSV) for handling > cryptographic and SSL functionality. By default the SSL protocol is set to > SSLv23 at both client and Server.That means The client and Server can > support SSLv2, SSLv3 and TLSv1 protcols. However an explicit protocl > (SSLv2/SSLv3/TLSV1) can also be set at both client and Server.
Do you automatically disable TLSv1 in case of a connection error (this is sometimes called the “downgrade dance”)? If not, your library simply cannot use TLS_FALLBACK_SCSV, and it does not have to. > As per my understanding We can overcome the POODLe vulnerability by > disabling SSLv3 protocol or setting the TLSv1 as the default protocol at > client and Server. It is already the default (over SSLv3) because it is the more recent protocol version. > 2. In general, if we have SSLv23 protocol at both client and Server, How > does the protcol negotiation happens? I have been reading that the client > sends a client_hello message along with the other protocols supported and > the cipher suites. The Server then sends its supported protocols/cipher > suites and selects the highest protocol supported by client and Server in > the order. Is my understanding correct? Correct. If both ends support something newer than SSL 3.0, then the connection will use that. This version negotiation is cryptographically protected, so if an attacker attempts to interfere with that, the connection will fail (and not silently revert to SSL 3.0). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
