Ce problème ne sera pas résolu avec du cynisme. Nous pouvons y mettre fin et nous devons le faire. Il n’y a jamais eu un moment de l’histoire où autant de gens pouvaient être surveillés. C’est nouveau et c’est inacceptable.
In this podcast, Tor project developer Jacob Appelbaum outlines why and how state surveillance activities compromised the internet.
“Any information that you transmit over any network at all, if you do not do it in a secure way, if it is tied to you, there is a good chance that at least the metadata will be intercepted and examined by machines,” Appelbaum (photo) says.
“If you are a person of interest, it is probably the case that the full content will also be looked at.
“That is very concerning to me, I do think people should be careful about this precisely because it is not just about international terrorism. It is about political hegemony. That is a very scary thing.
“The data collection of the NSA and GCHQ and other agencies – what they are doing right now – is larger than any data collection ever in the history of humanity.The reality is that this amount of information exists and it will be used against people.”
Appelbaum, who addressed yesterday’s Parliamentary Assembly hearing on electronic state surveillance adds: “We have a right to free speech. To do that, we need to be free from surveillance. To do that, we need to have the ability to do this anonymously.”
“We need to get rid of this false choice between security and privacy. In reality, what we are talking about is dignity and liberty.”
Hi,
I wanted to write to highlight some important documents that have
recently been released by Der Spiegel about the NSA and GCHQ. We worked
very hard and for quite some time on these stories - I hope that you'll
enjoy them.
Inside TAO: Documents Reveal Top NSA Hacking Unit:
Part 1: Documents Reveal Top NSA Hacking Unit:
Part 2: Targeting Mexico:
Part 3: The NSA's Shadow Network:
NSA's Secret Toolbox: Unit Offers Spy Gadgets for Every Need:
Shopping for Spy Gear: Catalog Advertises NSA Toolbox:
Interactive Graphic: The NSA's Spy Catalog:
http://www.spiegel.de/international/world/a-941262.html
Neue Dokumente: Der geheime Werkzeugkasten der NSA:
NSA-Programm "Quantumtheory": Wie der US-Geheimdienst weltweit Rechner
knackt:
Der Spiegel 1 / 2014:
https://magazin.spiegel.de/digital/index_SP.html#SP/2014/1/124188114
http://www.spiegel.de/spiegel/index-7629.html
TAO slides:
NSA QUANTUM Tasking Techniques for the R&T Analyst:
Yahoo! user targeting and attack example with QUANTUM:
QUANTUMTHEORY and related QUANTUM programs:
If you'd like to detect the QUANTUM INSERT, I suggest reading about the
race condition details:
http://www.spiegel.de/fotostrecke/qfire-die-vorwaertsverteidigng-der-nsa-fotostrecke-105358-15.html
Details about the Man-On-The-Side with QUANTUM:
QFIRE (NSA-Geheimdokumente: "Vorwärtsverteidigung" mit QFIRE), TURMOIL,
TURBINE, TURBULENCE:
http://www.spiegel.de/fotostrecke/qfire-die-vorwaersverteidigng-der-nsa-fotostrecke-105358.html
MARINA:
More MARINA details:
Catalog of equipment covering around ~50 programs:
Other slides covering FOXACID and more:
NSA QUANTUMTHEORY capabilities list:
GCHQ QUANTUMTHEORY capabilities list:
OLYMPUSFIRE:
An overview of all of these articles is available in German:
Earlier this week, I also recently gave a talk titled "To Protect and
Infect: part two" at CCC's 30C3. In the talk I explain a number of these
topics - the video is a reasonable complement to the above stories:
https://www.youtube.com/watch?v=b0w36GAyZIA
There are quite a few news articles and most of them have focused on the
iPhone backdoor known as DROPOUTJEEP - they largely miss the big picture
asserting that the NSA needs physical access. This is a
misunderstanding. The way that the NSA and GCHQ compromise devices with
QUANTUMNATION does not require physical access - that is merely one way
to compromise an iPhone. Generally the NSA and GCHQ compromise the phone
through the network using QUANTUM/QUANTUMNATION/QUANTUMTHEORY related
attack capabilities.
An example of a vulnerable Apple user is shown:
"note: QUANTUMNATION and standard QUANTUM tasking results in the same
exploitation technique. The main difference is QUANTUNATION deploys a
state 0 implant and is able to be submitted by the TOPI. Any ios device
will always get VALIDATOR deployed."
They're not talking about Cisco in that slide, I assure you.
Details on VALIDATOR:
Welcome to 2014!
The truth is coming and it can't be stopped,
Jacob
La vidéo : https://www.youtube.com/watch?v=Cu6accTBjfs&feature=youtu.be&t=2h23m1s . "Surveillance is not an end toward totalitarianism, it is totalitarianism itself. Limited in scope for the moment, but when the Golden Dawn [party] in Greece has access to these systems, with their racist ideology, what will happen?"
duraconf - A collection of hardened configuration files for SSL/TLS services
Hopefully this will help you make a more informed choice about what cipher list
should be used for different applications. What you find here are recommended
configurations, you should seriously consider using these, but you have to make
some choices. When you pick a cipher list, you have a couple different options
of how you go about it:
-
make a very specific declaration of what is acceptable. This has the
advantage of being able to define very closely of what you want, but the
disadvantage of having to stay on top of the latest crypto advancements, with
every crypto library upgrade. -
make a general declaration of which cipher list to use. this has the
advantage of allowing you to rely on your crypto libraries to make
(hopefully) informed choices for you (and to deactivate known
bad/weak/recently broken) ciphers while you don't have the burden of ensuring
that they are always resulting in a good cipher suite. The disadvantage is
that you cannot fine tune what exactly you get in return. -
A mixture of being specific and letting your crypto library decide from
general statements. This can be useful if, for example, you find out that
some particular crypto has become too weak, for example you might use a
generic list but then exclude MD5, because your crypto libraries haven't
removed that yet. -
Decide on a threat model for possible attacks that may expose an important
private key. Ciphers are often offered in a mode that provides Perfect
Forward Secrecy. While there are performance considerations, if you run a
high security operation where traffic disclosure would be a serious problem,
it is an important property to consider.
Generally it seems safer to have the crypto library take the bulk of the
decision since it should be for the most part fire-and-forget, while the other
options require that you always stay up to date on things and tweak as needed.
For practical use, and for people who can afford to follow crypto news, a
mixture of both is surely a good idea. So start with the general cipher list and
when you become aware that something is bad then just add this specific part to
your otherwise general cipher list until the crypto library defaults get updated
to fix that.
Unfortunately, its not possible to come up with one cipher configuration that is
going to work for all configurations. There are many different programs that
implement different versions of libraries that have different ciphers
available. In fact, a different versions of the same program may be linked
against different libraries which have different ciphers available.
An important configuration issue for service operators and users is
understanding Perfect Forward Secrecy. Generally, PFS sessions are
computationally more expensive than connections without PFS properties.
It is extremely important to remember that using SSL and/or TLS does not ensure
that your traffic is encrypted for all time. Generally, SSL/TLS services offer
two general modes of operation - one mode is ephemerally keyed and the other is not.
A TLS server that only offers AES256-SHA is strong against an attacker who will
never recovery the secret key used by the server and who cannot break AES256.
However, if an attacker is able to recover the server's key, the attacker will be able
to retroactively decrypt all traffic that has been recorded when the AES256-SHA
cipher is in use. If that same server uses an ephemeral cipher such as
DHE-RSA-AES256-SHA, the attacker cannot recover previous encrypted sesssions
without breaking RSA and/or AES256 for each session.
In both cases, when the attacker has the private key, all future communications
with the server are unsafe. Clients generally deal with this by looking up a
revokation list or by using something like the OCSP. Realistically, they're in
a lot of trouble and that kind of trouble is out of scope. If you're in doubt
it's probably a reasonable thing to use DHE or EDH modes unless you have load
issues.
The cipher lists you will find here actually vary depending on which version of
the crypto library that you have. For example, if you were to find this list
recommended:
HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH
In one version of openssl this will mean the following list of ciphers:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
In a newer openssl, this list of ciphers will be different:
$ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv2:!MD5:@STRENGTH'
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
It is also worth noting that this is setting a policy, and your site may have
different policies, depending on your intended audience. There are many
questions to consider in determining a policy. For example, in the worst case,
when a client doesn't support the higher strength ciphers my server supports, do
I want to keep up the image that medium strength ciphers are secure enough in my
specific use case, environment and opponents? Or should I not allow anything but
the highest strength ciphers, and those clients that do not support them are
just denied? Its likely that in many cases there is no possibility of making it
clear to the user that their setup does not allow for secure use of your
services, and what their options are. I think, at least with apache, it
should be possible to redirect users whose setup doesn't provide a compatible
cipher suite, to an informational web page which explains further steps they can
and should take (i have no idea how)..
Unfortunately, in most cases, users will not get any message at all and they
will have no clue why they are shut out. This could result in unhappy users with
no idea of where to turn, and potentially a higher support burden.
Notes on format of cipher designations
Format of cipher designations differ, but in general they follow the format
described in ciphers(5). A few notes:
The order specified is the preference order, and the list is separated by
colons. The list can be specific ciphers (eg. RC4-SHA), a list of suites
containing a certain algorith (SHA1), or a cipher suite of a certain type
(TLSv1). There are also cipher strings which are a grouping of different ciphers
into a specific category (eg. HIGH).
When removing ciphers that you do not want, you have a choice between indicating
! or -, the difference is subtle but important. It's good practice to use ! if
you really do not want this class to ever get used, and to use - when you want
to allow them to be still used if you later added something to your existing
cipher list.
Finally, there is also the @STRENGTH parameter, which sorts the cipher list in
order of encryption algorithm key length.
Suggested reading
This is the video from the talks given by Christian Grothoff, Carlo von Lynx, Jacob Appelbaum and Richard Stallman in Berlin on August 1st. The talks are in English, even though the welcoming words are in German.
Disclaimer: The subject of these talks are GNUnet, Secushare, Internet Censorship and Surveillance, and Free Software. While the talks were hosted and recorded by the Pirate Party Berlin, no political statements or endorsements on behalf of the TU Munich or the GNUnet project or its sponsors are implied.
https://gnunet.org/sites/default/files/grothoff_slides_berlin.pdf
https://gnunet.org/sites/default/files/lynx_slides_youbroketheinternet.pdf
https://gnunet.org/sites/default/files/internetistschuld.webm