Spy Files 3

[hashtag 151]

Internet spying technologies now being sold on the intelligence market include detecting encrypted and obfuscated internet usage such as Skype, BitTorrent, VPN, SSH and SSL. The documents reveal how contractors work with intelligence and policing agencies to obtain decryption keys. The documents also detail bulk interception methods for voice, SMS, MMS, email, fax and satellite phone communications. The released documents also show intelligence contractors selling the ability to analyse web and mobile interceptions in real-time.

 

https://wikileaks.org/spyfiles3

[Staff 9751]

That's one of the reasons for which it's important to have Perfect Forward Secrecy. With a TLS re-keying at each new connection and every 60 minutes, it does not matter if somehow an adversary comes into possession of your user.key: even if that happens, your traffic between your node and the VPN server can't be decrypted.

 

Kind regards

[Royee 10]

thanks for the article, paranoia just increased by 50%

 

How can one setup perfect forward secrecy ?

[Staff 9751]

Hello,

 

it's enabled by default in our service. OpenVPN works in TLS mode with TLS re-keying at each new connection and every 60 minutes. 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 9751]

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

[24FWgGC 6]

I have a couple of questions in response...

 

1) If I would like to change my user.key, would I just login to the website, update my password, and then generate new config files?

 

2) According to NIST ( http://csrc.nist.gov/groups/ST/hash/policy.html ) it is recommended that federal agencies cease using SHA-1 as soon as possible, instead utilizing SHA-2. In checking the current release of OpenVPN, I find that TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 is supported, which would match your current configuration, except for adding the newer hash algorithm. Do you have any plans to implement such an upgrade? If so, would this upgrade also be implemented for the airvpn.org website security as well?

[Staff 9751]

I have a couple of questions in response...

 

1) If I would like to change my user.key, would I just login to the website, update my password, and then generate new config files?

 

Hello!

 

You can't change your user.key on your own. Please feel free to open a ticket if you wish to do so.

 

 

2) According to NIST ( http://csrc.nist.gov/groups/ST/hash/policy.html ) it is recommended that federal agencies cease using SHA-1 as soon as possible, instead utilizing SHA-2. In checking the current release of OpenVPN, I find that TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 is supported, which would match your current configuration, except for adding the newer hash algorithm. Do you have any plans to implement such an upgrade? If so, would this upgrade also be implemented for the airvpn.org website security as well?

 

No, it's not planned for 2013 because it's not necessary (on top of that, OpenVPN 2, 2.1 and 2.2 do not support natively ECC). It would require a massive conversion of all of our clients for nothing: we don't use SHA1 for packet encryption or authentication. We use HMAC SHA1 for packet authentication, which is a totally different beast. In order to try to find hash collisions in an attempt to inject forged packets, an attacker should first break HMAC to reach the underlying hash algorithm.

 

Kind regards