I have checked the SSL behavior in Jitsi. Jitsi is currently
supporting SSL3.0 and TLS1.0 for encrypted connections. Because an
active attacker can force Jitsi to downgrade TLS1.0 to SSL3.0
connection we should disable SSL3.0.
According to statistics from
TLS 1.0 protocol is supported on 99.5% of public XMPP servers
TLS has a variety of security measures:
* Protection against a downgrade of the protocol to a previous (less
secure) version or a weaker cipher suite.
* Numbering subsequent Application records with a sequence number and
using this sequence number in the message authentication codes (MACs).
* Using a message digest enhanced with a key (so only a key-holder can
check the MAC). The HMAC construction used by most TLS cipher suites
is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).
* The message that ends the handshake ("Finished") sends a hash of all
the exchanged handshake messages seen by both parties.
* The pseudorandom function splits the input data in half and
processes each one with a different hashing algorithm (MD5 and SHA-1),
then XORs them together to create the MAC. This provides protection
even if one of these algorithms is found to be vulnerable.
- From a security standpoint, SSL 3.0 should be considered less
desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key
derivation process; half of the master key that is established is
fully dependent on the MD5 hash function, which is not resistant to
collisions and is, therefore, not considered secure. Under TLS 1.0,
the master key that is established depends on both MD5 and SHA-1 so
its derivation process is not currently considered weak. It is for
this reason that SSL 3.0 implementations cannot be validated under