Fwd: The real security threat are rogue CAs.

[Ralf Skyper Kaiser]

Discussion on jitsi ml but it might be relevant for pidgin as well.

---------- Forwarded message ----------
From: Ralf Skyper Kaiser <skyper at thc.org>
Date: Fri, Nov 22, 2013 at 11:09 AM
Subject: It's not about random vs. urandom. The real security threat are
rogue CAs.
To: Jitsi Developers <dev at jitsi.org>


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/support/attachments/20131122/0aef5104/attachment.html>