[jitsi-dev] Disable SSL 3.0


#1

Hi,
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.

http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks

According to statistics from
https://xmpp.net/reports.php
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
FIPS 140-2.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Fedor


#2

Hi,

Interesting question. I'd like to pose a related question: The IRC
library currently used initiates an SSL context instance via the
identifier "SSL". I was wondering about whether or not 'SSL' is the good
choice here. Current Java API (Java SE 7, that is) documentation advises
'TLSv1' as the "protocol", which they say is also most widely available
over Java implementations.

Given that this is pretty closely related to this question, I will keep
an eye out for the outcome.
Also, does anyone have any suggestions specifically for IRC?

Danny

Hi,
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.

http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks

···

On 01/14/2014 01:55 PM, Fedor Brunner wrote:

According to statistics from
https://xmpp.net/reports.php
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
FIPS 140-2.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Fedor

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Interesting question. I'd like to pose a related question: The IRC
library currently used initiates an SSL context instance via the
identifier "SSL". I was wondering about whether or not 'SSL' is the good
choice here. Current Java API (Java SE 7, that is) documentation advises
'TLSv1' as the "protocol", which they say is also most widely available
over Java implementations.

I agree that we should disable SSL3, but given that we still need to support
Java 6, I'm not sure if we can do that yet. Someone was working on making
this configurable (including the accepted ciphers), but I don't know if and
how that progressed.

Given that this is pretty closely related to this question, I will keep
an eye out for the outcome.
Also, does anyone have any suggestions specifically for IRC?

Well, yes: don't obtain an SSLContext or TrustManager yourself, but use the
CertificateService. Otherwise we can't handle invalid certificates
gracefully or even check whether the certificate matches the server we're
connecting to.
Actually, this is kind of mandatory.

Danny

Ingo


#4

Interesting question. I'd like to pose a related question: The
IRC library currently used initiates an SSL context instance via
the identifier "SSL". I was wondering about whether or not 'SSL'
is the good choice here. Current Java API (Java SE 7, that is)
documentation advises 'TLSv1' as the "protocol", which they say
is also most widely available over Java implementations.

I agree that we should disable SSL3, but given that we still need
to support Java 6, I'm not sure if we can do that yet. Someone was
working on making this configurable (including the accepted
ciphers), but I don't know if and how that progressed.

JSSE: a Java implementation included in the Java Runtime Environment
supports TLS 1.1 and 1.2 from Java 7, although is disabled by default
for client, and enabled by default for server.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
https://en.wikipedia.org/wiki/Transport_Layer_Security

Java 6 supports SSL3 and TLS 1.0

Ciphers in Java 6:
http://www.techstacks.com/howto/java6_ssl_cipher_strength.html

There are unresolved issues with stronger DHE primes also in Java 7,
this affects forward secrecy.
https://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

Given that this is pretty closely related to this question, I
will keep an eye out for the outcome. Also, does anyone have any
suggestions specifically for IRC?

I have no statistics about supported TLS version on IRC servers.

···

On 14.01.2014 19:21, Ingo Bauersachs wrote:

Well, yes: don't obtain an SSLContext or TrustManager yourself, but
use the CertificateService. Otherwise we can't handle invalid
certificates gracefully or even check whether the certificate
matches the server we're connecting to. Actually, this is kind of
mandatory.

Danny

Ingo

_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

This is good to know. This particular case is in the irc library that I
use, so the code is not actually mine. I will keep this in mind, though.
Guess that's one more for the good ol' TODO list :stuck_out_tongue:

Danny

···

On 01/14/2014 07:21 PM, Ingo Bauersachs wrote:

Interesting question. I'd like to pose a related question: The IRC
library currently used initiates an SSL context instance via the
identifier "SSL". I was wondering about whether or not 'SSL' is the good
choice here. Current Java API (Java SE 7, that is) documentation advises
'TLSv1' as the "protocol", which they say is also most widely available
over Java implementations.

I agree that we should disable SSL3, but given that we still need to support
Java 6, I'm not sure if we can do that yet. Someone was working on making
this configurable (including the accepted ciphers), but I don't know if and
how that progressed.

Given that this is pretty closely related to this question, I will keep
an eye out for the outcome.
Also, does anyone have any suggestions specifically for IRC?

Well, yes: don't obtain an SSLContext or TrustManager yourself, but use the
CertificateService. Otherwise we can't handle invalid certificates
gracefully or even check whether the certificate matches the server we're
connecting to.
Actually, this is kind of mandatory.


#6

This is good to know. This particular case is in the irc library that I
use, so the code is not actually mine. I will keep this in mind, though.
Guess that's one more for the good ol' TODO list :stuck_out_tongue:

Try to talk to them to provide an API to set a TrustManager. If they won't
do it, we need to patch the library ourselves. It's a pain, but we already
do it for Smack too.

Danny

Ingo


#7

That's the plan, indeed.

Danny

···

On 01/15/2014 09:16 PM, Ingo Bauersachs wrote:

This is good to know. This particular case is in the irc library that I
use, so the code is not actually mine. I will keep this in mind, though.
Guess that's one more for the good ol' TODO list :stuck_out_tongue:

Try to talk to them to provide an API to set a TrustManager. If they won't
do it, we need to patch the library ourselves. It's a pain, but we already
do it for Smack too.