US and UK spy agencies defeat privacy and security on the internet

[hashtag 151]

US and British intelligence agencies have successfully cracked much of the online encryption relied upon by hundreds of millions of people to protect the privacy of their personal data, online transactions and emails, according to top-secret documents revealed by former contractor Edward Snowden.

 

http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security

[hashtag 151]

How to remain secure against NSA surveillance
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Bruce Schneier's response to the article.

[Staff 9973]

On top of that, this is an answer given on some tickets a few minutes ago, as a reply to worried inquiries following the new articles on The New York Times and other publications.

 

Hello!

[Looking deeper into papers and more technical articles, already available] NSA can decrypt only encrypted data for which NSA already has the keys (through back doors or just by getting the keys) or for weak, obsolete ciphers.

That's why it's very important to use services (like ours ) which do not possess your key and comply to Perfect Forward Secrecy. For example, when your OpenVPN client establishes a connection to one of our servers, a new TLS key is negotiatied (Diffie-Hellman/Perfect Forward Secrecy) AND and a new TLS re-keying occurs every 60 minutes.

Additionally, AirVPN is based on OpenVPN, which is free and open source, and have been and is being under intensive crypto-experts peer-reviews since its birth more than 10 years ago. No backdoor has ever been found.

We run OpenVPN with the following ciphers:

OpenVPN Data Channel: AES-256-CBC
OpenVPN Control Channel: HMAC SHA1
RSA keys: 2048 bit size
OpenVPN in TLS mode (Perfect Forward Secrecy: re-keying at each connection and re-keying every 60 minutes)

Now let's assume that NSA (or any other very malignant adversary) breaks into your system or into our secret backend servers and obtain your user.key (the user.key is not kept in the VPN servers, and the location of the backend servers is unknown to everyone except the Air founders; the clients and the VPN servers never communicate directly with the backend servers). Now, the user.key is used to authenticate your client, but the TLS key is re-negotiated. So NSA or that malignant entity could use our VPN with your account, assuming that they get also the certificates (so they can save 7 EUR a month and get a free ride with our service ), but it would not be able to decrypt your communications with our servers.

 

Kind regards

[Staff 9973]

Some additions in order to be more precise:

 

You can lower the re-keying time, if you wish so, with the directive

reneg-key

to be inserted in the .ovpn configuration file (note: this option is not available in the Air client, you'll need to run OpenVPN GUI or OpenVPN directly).

You can NOT increase the re-keying time (3600 seconds), because that would need a modification on server side configuration. If you do so, your connection will be lost after the first 3600 seconds.


We use "method 2":

In method 2, (the default for OpenVPN 2.0) the client generates a random key. Both client and server also generate some random seed material. All key source material is exchanged over the TLS channel. The actual keys are generated using the TLS PRF function, taking source entropy from both client and server. Method 2 is designed to closely parallel the key generation process used by TLS 1.0.
Note that in TLS mode, two separate levels of keying occur:
(1) The TLS connection is initially negotiated, with both sides of the connection producing certificates and verifying the certificate (or other authentication info provided) of the other side. The --key-method parameter has no effect on this process.
(2) After the TLS connection is established, the tunnel session keys are separately negotiated over the existing secure TLS channel. Here, --key-method determines the derivation of the tunnel session keys.

Please see the OpenVPN manual for more details.

Kind regards

[degas432 0]

So in lay terms, what you are saying is that the NSA cannot break AIR VPN encryption. Is that correct please? TIA.

[Staff 9973]

@degas432
 
Yes, we're saying that, but we're saying even more.
 
We're also saying that if (just to make bad science fiction, because all the elements point to the contrary) NSA could break the encryption for ONE of your keys AND discern AND capture the packets stream of a client for THAT key, it could decrypt ONLY the packets stream included in the time frame between two TLS re-keyings (see also on Wikipedia "Perfect Forward Secrecy").
 
An interesting discussion is here http://crypto.stackexchange.com/questions/579/how-can-we-reason-about-the-cryptographic-capabilities-of-code-breaking-agencies
 
one paragraph of one of the posts is particularly worth to be quoted. It's one month old but it was prophetic in light of the most recent leaked documents:

Reading the slides for PRISM the cost of the program is way too low to include any sort of computationally intensive pursuits. It's not a far leap to infer PRISM being a key sharing effort. Several accounts seem to indicate the NSA are actively subverting security on the standards level or in collusion with software developers. If either proposition is true, any serious cryptographer needs to use systems where every component is known and excludes closed source operating systems and software black boxes.

 

One side note as a figurative example: being worried about NSA decrypting your one-hour AES-256 traffic while at the same time running Windows is like being worried exclusively about an asteroid hitting your head when you walk at night alone in San Pedro Sula while happily waving 10000 dollars in your hand.

Kind regards

[degas432 0]

Thanks very much for this response and the great work you do.

 

Can I ask you what operating system you recommend.

 

Is Linux better for example.

 

TIA

[dwright 25]

So, suppose my VPN connection was vulnerable to decryption, would using the SSL version with STunnel provide an extra layer of protection? Even if it's not really a significant risk, as you explain.

[Staff 9973]

Hello!

 

Yes, it's an additional encryption layer. Unnecessary as you said, if the magic of the attacker could decrypt OpenVPN ciphers before we're all dead, instead of million of years, the additional SSL would be no match as well.

 

Kind regards

[#!@root88 0]

Thanks very much for this response and the great work you do.

 

Can I ask you what operating system you recommend.

 

Is Linux better for example.

 

TIA

 

If you're on Windows, I wouldn't trust it as there is no way of viewing the source code, so they could have have backdoors built in. Also, I wouldn't trust Microsoft as far as I could throw them.

 

Linux is making leaps and bounds lately, and I recommend Linux Mint if you're a new user. You can then move onto other Linux distros. I started with Mint, and now I'm using an Arch-based distro which for me is a lot faster. You could also look into FreeBSD if you want a full OS, but your hardware might not work on it. The best thing to do is to download virtualbox and test them before you install them. Have a look at the following sites.

 

http://distrowatch.com/

https://prism-break.org/

[Anthony.Dellabarba 0]

Thanks for all this information members and staff.  I read the TorrentFreak article yesterday and it did make me wonder.  Feel a little better after reading comments above and still feel secure with this VPN provider.  Everybody have a great day.

 

Ref: http://torrentfreak.com/nsa-can-spy-on-vpn-traffic-and-other-encrypted-communication-130906/

[vashtanerada 0]

Thanks very much for this response and the great work you do.

 

Can I ask you what operating system you recommend.

 

Is Linux better for example.

 

TIA

 

Disclaimer, I'm a Linux and FOSS fanboy.

 

But I also work with RSF protecting bloggers and journalists who risk their lives. Because open source can be checked for weaknesses and backdoors in a way that commercial software (OSX, Windows) cannot, you gain some confidence with Linux and BSD, especially if you compile your own. For that, I recommend FOSS operating systems, just be careful what proprietary software you install -- many Linux drivers are closed source, so it's not impossible that say, a video or wifi driver could betray you. Sometimes it's difficult to run a purely FOSS system; either for drivers, or for closed software that we all depend on daily (Flash, Adobe Reader, etc.).

 

This, I believe is what Snowden had in mind when he said [much mathematically sound] crypto can be trusted, but that weak endpoint security may make comms security alone not enough.

 

That said, we can have precisely zero confidence in Win or OSX (or IOS, and the closed bits of Android), but we have half a fighting chance with Linux and BSD (and Firefox OS or Ubuntu Touch). Linux Mint will include some closed source drivers and comes pre-compiled (by whom?), but you can have more confidence with them than their closed source alternatives.

 

I agree with previous poster that Mint (and others) are a great start and offer more privacy. After that introduction, you may wish to try something even more trustworthy. I'm working up to OpenBSD myself, but am not there yet.

 

Bottom line, you don't have to be in the top 1% of secure users overnight. Every step we take in the privacy direction makes our past data and leaks more and more obsolete by the second. Just by asking the question, we're no longer the low-hanging fruit.

[AV_AVPN 0]

In response to

 

"But I also work with RSF protecting bloggers and journalists who risk their lives. Because open source can be checked for weaknesses and backdoors in a way that commercial software (OSX, Windows) cannot, you gain some confidence with Linux and BSD, especially if you compile your own. For that, I recommend FOSS operating systems"

 

While I hope that FOSS is more secure I'm not sure that can be taken as a given. For everyones consideration, I offer this post that John Gilmore recently submitted to The cryptography mailing list. You can find a archived version with additional discussion Here:http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html

 

 

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"

John Gilmore Fri, 06 Sep 2013 17:49:35 -0700

 

 

Speaking as someone who followed the IPSEC IETF standards committee
pretty closely, while leading a group that tried to implement it and
make so usable that it would be used by default throughout the
Internet, I noticed some things: * NSA employees participted throughout, and occupied leadership roles
in the committee and among the editors of the documents

* Every once in a while, someone not an NSA employee, but who had
longstanding ties to NSA, would make a suggestion that reduced
privacy or security, but which seemed to make sense when viewed
by people who didn't know much about crypto. For example,
using the same IV (initialization vector) throughout a session,
rather than making a new one for each packet. Or, retaining a
way to for this encryption protocol to specify that no encryption
is to be applied.

* The resulting standard was incredibly complicated -- so complex
that every real cryptographer who tried to analyze it threw up
their hands and said, "We can't even begin to evaluate its
security unless you simplify it radically". See for example:

https://www.schneier.com/paper-ipsec.html

That simplification never happened.

The IPSEC standards also mandated support for the "null"
encryption option (plaintext hiding in supposedly-encrypted
packets), for 56-bit Single DES, and for the use of a 768-bit
Diffie-Hellman group, all of which are insecure and each of which
renders the protocol subject to downgrade attacks.

* The protocol had major deployment problems, largely resulting from
changing the maximum segment size that could be passed through an
IPSEC tunnel between end-nodes that did not know anything about
IPSEC. This made it unusable as a "drop-in" privacy improvement.

* Our team (FreeS/WAN) built the Linux implementation of IPSEC, but
at least while I was involved in it, the packet processing code
never became a default part of the Linux kernel, because of
bullheadedness in the maintainer who managed that part of the
kernel. Instead he built a half-baked implementation that never
worked. I have no idea whether that bullheadedness was natural,
or was enhanced or inspired by NSA or its stooges.

In other circumstances I also found situations where NSA employees
explicitly lied to standards committees, such as that for cellphone
encryption, telling them that if they merely debated an
actually-secure protocol, they would be violating the export control
laws unless they excluded all foreigners from the room (in an
international standards committee!). The resulting paralysis is how
we ended up with encryption designed by a clueless Motorola employee
-- and kept secret for years, again due to bad NSA export control
advice, in order to hide its obvious flaws -- that basically XOR'd
each voice packet with the same bit string! Their "encryption"
scheme for the control channel, CMEA, was almost as bad, being
breakable with 2^24 effort and small numbers of ciphertexts:

https://www.schneier.com/cmea-press.html

To this day, no mobile telephone standards committee has considered
or adopted any end-to-end (phone-to-phone) privacy protocols. This is
because the big companies involved, huge telcos, are all in bed with
NSA to make damn sure that working end-to-end encryption never becomes
the default on mobile phones.

John Gilmore

[Staff 9973]

Hello,

 

side note: in 2010, when AirVPN was being born, we discarded PPTP (that was an obvious choice) and after a careful evaluation we picked OpenVPN and discarded IPsec as well. There are even additional considerations about IPsec, on top of those that you have kindly reported, which convinced us to prefer OpenVPN.

 

Kind regards

[vashtanerada 0]

While I hope that FOSS is more secure I'm not sure that can be taken as a given.

 

I hope I didn't give the impression that FOSS is a magic bullet. It's not, and I only say we have a fighting chance with it compared to closed-source.

 

On the topic of IPSec, I've found it exceedingly difficult to find IPSec VPNs that are not commercial vendor-supplied, either as libraries or full solutions. My hands are tied at the office where Cisco rules and OpenVPN is a tough and incompatible (with other businesses/partners) sell. I can only hope that that will change now or soon the same way that TOR use has doubled in the past month. Fortunately, FOSS and OpenVPN are much more accessible to those who still choose to risk a blog when their freedom from harassment, at very least, is at risk.

 

I absolutely assure them as much and more than I assure you now, that there are herds and herds of smarter and near-infinitely funded infosec people working for every country's TLA agencies than I can hope to match even as a pro and hobbyist. We can only share what we know. Let's hope that people who need it will become as good or better than us, whether we're CYA as a whistle-blower, a journalist, HIV+ and looking for support, a doctor, an NGO in hostile territory, or just staying off the radar for a Breaking Bad download.

 

I hate that we can't trust our own computers anymore. It is a sad day.

[Staff 9973]

Hello,

 

as an important side note that we forgot to mention, the airvpn.org web site does support Perfect Forward Secrecy through both Diffie-Hellman (DHE) and Elliptic Curve (ECDHE) keying, provided that you do not use an obsolete browser. It also supports TLS 1.2.

 

You can check any web site, for example, through the SSL Labs web site to see all the features:

 

https://www.ssllabs.com/ssltest

 

Enter the web site you wish to check and wait for the full test to be performed.

 

Kind regards

[amazeballs 2]

Hi, bit of a noob question:

I can see that you use a 2048 Bit RSA key which is great and a 256bit AES cipher (also great), however I was just wondering about the level of encryption on the connection.  Do you use Elliptic Curve Cryptographic security on the symetric cipher?

 

Cheers!

[bubbba 3]

Is there a way to use this via DD-WRT in the OpenVPN config? I tried adding it to 'Additional Config' box just as I had it in my .ovpn files but that didn't seem to work. It worked great in the .ovpn file just by adding "reneg-key 120".

 

Thanks...

[amnesty 18]

You can check any web site, for example, through the SSL Labs web site to see all the features:

 

https://www.ssllabs.com/ssltest

When I test a site, does it matter (in your opinion) who the Certificate Issuer is (issued by a U.S. company or not)?

 

Would running OpenVPN on a DD-WRT router (appliance) be more secure than OpenVPN on a single (Win, OS X and/or Linux) system?

 

Tnx for your service

[McLoEa 25]

Thank you for this discourse folks,I was getting concerned that the NSA,GCHQ et al had our encryption keys and could tap in whenever they want to but the reminder that Open VPN is an open source program has partially laid my mind to rest.

I do still have concerns about the software and maybe even the processor manufacturers though but those arguments belong on a different forum I guess.