[jitsi-dev] It's not about random vs. urandom. The real security threat are rogue CAs.


#1

Hi,

thanks for the discussion about which random source (/dev/random
or /dev/urandom) to use. The discussion was helpful and
enlightening.

It is good to discuss this.

As with many things a balance has to be found between what security
feature gives you the biggest bang for the time spend implementing
it.

In the absence of any academic or practical attack to compromise a
DH or DSA key generated from a /dev/urandom source we shall assume
that the Jitsi communication is secure for the foreseeable future.

How your jitsi communication is compromised right now is the way how
TLS certificates are handled. (All XMPP clients suffer from the same
problem and Jitsi is not an exception).

There is a lot we learned from the Snowden files and what happened
since 2007.

Example with Jitsi using TLS:

Etisalat, a major telecommunication operator in the United Arab
Emirates, has the power to generate a valid X.509 certificate for
jabber.google.com without google knowing about it.

All XMPP clients currently accept this 'rogue' certificate.

Etisalat can intercept the TLS connection to jabber.google.com without
any warning shown by the XMPP client. The reason for this is that Jitsi
verifies the jabber.google.com TLS X.509 certificate against any of the
installed Certification Authorities (CA).

I mention Etisalat here because we know from the Etisalat-Blackberry
incident from 2007 that Etisalat is a trusted Certification Authority
(e.g. their ROOT Ca key is shipped with windows) and has abused its
power by signing a Blackberry/RIM firmware update and infecting 143.000
of blackberry customers with surveillance software.

The XMPP client is trusting a bad player.

(If you are currently transiting via Dubai Airport you might want to
turn of Jitsi).

But this is not about Etisalat. The SSL Observatory project estimates
that there are currently around 800+ different 'companies' in 52+
different countries with different econimical and geopolitical
interrest that can generate a rogue certificate for jabber.google.com.

Anyone of those has the power to generate a rogue certificate for any
XMPP-server in the world.

All of those have the 'trust' anchored with a CA that is installed
and comes with our OS.

Anyone of those has the (techincal) ability to intercept the TLS
connection without Jitsi showing a warning to the user.

We know from the various leaks (snowden and wikileaks spyfiles) that
TLS Proxies have been purchased by governments with a rather
questionable track record of Human Rights abuses and a lack of
respect for private communication.

We know that government sponsored pervasive Internet surveillance
happened during the 2011 revolutions all around the world.

We know that citizens got arrested, tortured or worse for wrongly
assuming that their Internet communication was secure. XMPP
was no exception.

If you ever want to save somebody's life then fixing this
problem is your best shot.

Fixing this problem gives you the biggest security improvement for
the time spend developing it.

Certificate Pinning solves this problem.

https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08

Certificate Pinning is in the last stages of becoming an RFC. It's
not there yet but chrome and other browser manufactures have already
implemented it.

It would require a protocol change in the XMPP protocol (the server
would have to offer two certificates: an actual certificate and
a backup certificate).

There is an intermediate solution which works without protocol changes:

Certificate Pinning Light

The client cut 'pin' a server certificate to a host-name the same way that
ssh clients 'pin' the host key to a host-name (known_hosts).

There is a lot of activity on making the s2s XMPP connections secure. More
about this at https://github.com/stpeter/manifesto. It's a great step by
mostly
those who operate the XMPP backend network.

The c2s XMPP connection is the last leg where security can make a real
difference.

regards,

ralf


#2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the absence of any academic or practical attack to compromise a
DH or DSA key generated from a /dev/urandom source we shall assume
that the Jitsi communication is secure for the foreseeable future.

One shouldn't wait till there is a practical attack by some academics to
attack this "theoretical" attack. This should be considered bad
practice, why go with a 1024 bit RSA key (no formal proof) when one can
have a 4096 bit RSA key?

In anycase, DSA is actually a pretty messed up, if not entropy is being
used or depleted using a bad random source it suffers from an algebraic
attack. I would advice the Jitsi developers to read the following
blogpost:
http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/

I quote Jacob Appelbaum here: "if the RNG goes badly, a single message
signed with DSA will leak enough information for an attacker to recover
the private key. The theory goes that the RNG won't go badly and so,
we're all good. I am not a fan of this strategy."

And neither am I a fan of this strategy. If we are going to favor speed
over security, we might as well ship Jitsi with only SSLv2 enabled
right? What's the purpose then. Either you provide SSL and OTR and
implement it well or you completely remove it, there is no middle
solution here.

While I would like to see certificate pinning implemented, it should be
a discussion in a separate thread :slight_smile:

All the best,
Jurre

- --
Developer at https://www.useotrproject.org/

···

On 11/22/2013 12:09 PM, Ralf Skyper Kaiser wrote:


#3

How your jitsi communication is compromised right now is the way how
TLS certificates are handled. (All XMPP clients suffer from the same
problem and Jitsi is not an exception).

That would only be true in the absence of OTR. We try to make it
relatively evident a user that a conversation is not considered
protected unless OTR is in use.

Certificate Pinning solves this problem.

I think you are overselling this a bit.

Certificate pinning is an extra measure. It is not a complete solution:

1. It still requires you to trust CAs the first time you connect somewhere.
2. It does nothing to guarantee end-to-end privacy and protect your
communication from any of the XMPP servers along the way.

OK, so that said, I am not objecting to certificate pinning in anyway.
Again, I do believe it is a handy extra measure so we will look at
this sooner or later (whoever wants this to happen sooner rather than
later: patches are welcome).

···

On Fri, Nov 22, 2013 at 12:09 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:


#4

Hi,

>
> How your jitsi communication is compromised right now is the way how
> TLS certificates are handled. (All XMPP clients suffer from the same
> problem and Jitsi is not an exception).

That would only be true in the absence of OTR. We try to make it
relatively evident a user that a conversation is not considered
protected unless OTR is in use.

I was not clear and you are right that your private messages can be
protected with OTR.

My comment above was regarding the buddy list and meta data. Regardless if
OTR is used or
not this data can be intercepted by a rogue CA.

> Certificate Pinning solves this problem.

I think you are overselling this a bit.

Certificate pinning is an extra measure. It is not a complete solution:

1. It still requires you to trust CAs the first time you connect somewhere.
2. It does nothing to guarantee end-to-end privacy and protect your
communication from any of the XMPP servers along the way.

yes, you are right. Pinning is not a complete solution and I'm sorry if I
presented it as such. Pinning solves one
particular security problem which is actively being exploited on the
Internet.

(It solves that a rogue CA can intercept c2s traffic assuming that a client
has previously connected to the jabber server (e.g. a 'known host')).

It also raises the bar for the attacker. A client can only be attacked
before the first connect to the
jabber server. Once the attack is in place the attacker must continue this
attack indefinitely or
the attack will be discovered as soon as the attacker stops attacking.

The attacker also can not tell which client has the certificate pinned
already and who connects for the
first time. This means the attacker would risk that the attack is
discovered.

DNSSEC further mitigates the first-connect problem.

OK, so that said, I am not objecting to certificate pinning in anyway.

Again, I do believe it is a handy extra measure so we will look at
this sooner or later (whoever wants this to happen sooner rather than
later: patches are welcome).

Cool. I wish I could provide some code and patch instead of just blaring on
about it :confused:

regards,

ralf

···

On Fri, Nov 22, 2013 at 12:11 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Fri, Nov 22, 2013 at 12:09 PM, Ralf Skyper Kaiser <skyper@thc.org> > wrote:

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