32 replies to this topic

[Samad]

Hi there, I thought I'd direct the AirVPN staffs attention towards this newly discovered bug in certain versions of OpenSSL.

 

Description: http://heartbleed.com/

Reddit Netsec Discussion: http://www.reddit.co...tealing_server/

 

Are AirVPN users vulnerable to this exploit, and if so will you be implementing Fixed OpenSSL?

 

Thanks, you guys are always awesome!

[pfSense_fan]

Since the patched version of OpenSSL was only released today, it's fair to say that everyone using the affected versions is at risk.

 

That being said, from the article you linked to:

 

Does Perfect Forward Secrecy (PFS) mitigate this?

Use of Perfect Forward Secrecy (PFS), which is unfortunately rare but powerful, should protect past communications from retrospective decryption. Please see https://twitter.com/...280081897467905 how leaked tickets may affect this.

 

AirVPN uses perfect forward secrecy, so we have at least that net of safety going for all of us.

[kopimist]

(Standard disclaimer: Note that everything below is according to my understanding of the issue. I am not a cryptography expert, and am basing these suggestions on the description I've read so far about this bug. Feel free to correct if I am wrong!)

 

Please note that PFS would only protect past session data which was not otherwise compromised.

However, if due to the heartbleed bug the server's private key was leaked a motivated attacker could abuse this by performing a man-in-the-middle attack on future sessions.

Since, according to the linked article, the heartbeat request can be performed in the handshake phase of the protocol, it is my understanding that an attacker would not even have to be a client of AirVPN.

It would also be technically feasible for client's private keys to have leaked if an attack was performed.

 

In this scenario, I think the first priority would be to have AirVPN validate their current setup to see if the required upgrades have been performed on all servers. Furthermore, a new private key should be generated for the server (preferrably, if individual Certificate Authorities are used, a new CA should be also generated to sign the server certificate/key, and the new CA certificate should be distributed. This would break current clients from connecting, however, it would give an indication if an attacker is still trying to perform a MITM attack with old stolen key material. Maybe this can be skipped, however, if there is a good way to configure the client to no longer accept the server's old certificate), so future communications are protected.

 

Furthermore, AirVPN should offer users the ability to generate a new private key for connecting to the service (by downloading a new configuration, etc.).

[dwright]

I saw a few posts in different places about a new OpenSSL vulnerability that's been discovered. I know OpenVPN uses OpenSSL, but it's still unclear to me whether it's affected as I don't know which version it employs and which are affected.

 

I'll post some relevant links and hope someone who understands these issues chimes in:

 

http://www.zdnet.com...led-7000028166/

 

https://blog.torproj...g-cve-2014-0160

 

http://heartbleed.com/

 

[Edit] I originally put this as the first post in a new thread but it was merged into this one, which is why it may look silly

[dwright]

Staff, can you please give more detail about why that is?

[xpomul]

Good news: our OpenSSL branch is not affected by the vulnerability. No action from us or from you is required.

 

So you're still using squeeze?

 

@dwright

I suspect they still use an older version of openssl, probably 0.9.8 which lacks the complete feature of TLS-heartbeat and so isn't vulnerable.

[Staff]

Hello!

Warning: this document could be updated by the technical staff if necessary. Please consult it again in the near future.

After a deeper analysis we would like to inform you about problems, solutions, what we did and what you need to do, in compliance with our transparency policy. The OpenSSL 1.0.1a-->f vulnerability is huge, but several factors in our infrastructure design made the menace a minor threat, without any potentially catastrophic consequence.

• some of our OpenVPN servers used a vulnerable OpenSSL version. They have been all updated and upgraded between 3 PM and 6 PM 08-Apr-14 CET+1. The non-updated VPN servers running branches of OpenSSL like 0.9.8 were not and are not vulnerable. Assuming that an attacker could steal your user.key on those servers or directly from your system (in case you ran a vulnerable OpenSSL version), the worst damage is that he/she will connect with your account in the future (see below for a solution to this problem). He/she will not be able to decrypt your OpenVPN Data Channel. Various factors help mitigate the problem even on those vulnerable VPN servers: the attacker could not perform an attack through the exit-IP address (he/she should have known the entry-IP) and Perfect Forward Secrecy does not allow the attacker to decrypt your data

• the primary frontend (the web site you normally visit) used a vulnerable OpenSSL version which has been upgraded at 3 PM 08-Apr-14 to a non-vulnerable version. All sessions were reset. The vulnerability allowed an attacker to dump a memory portion of the server which could disclose information useful to exploit future access of those users using browsers or web clients not supporting DHE or ECDHE: Internet Explorer 6, Internet Explorer 8, YandexBot 3, or browsers manually forced NOT to use Perfect Forward Secrecy.

• the backend servers and other vital parts of the infrastructure were not and are not vulnerable, since they were NEVER running a vulnerable OpenSSL version

What we have already done:

• we replaced on every part of the infrastructure the vulnerable OpenSSL versions (if any) with non-vulnerable ones between 3 PM and 6 PM 08-Apr-14 CET+1
• we changed in advance all administrative accounts passwords (this was not strictly necessary, but it has been performed anyway)
• we updated the internal SSL certificates
• we reset connections of clients connected to VPN servers running OpenSSL vulnerable version and rebooted the server to make sure that no old dynamically linked SSL version was still used by OpenVPN
• we performed attacks against our servers, even with the help of independent attackers as peer review, to check that the vulnerability has been resolved
• we have ordered the revocation of the frontend web server previous SSL certificate (this will go into effect in 72 hours according to authority policy)
• UPDATE 11.15 PM 08-Apr-14 CET+1 we changed the SSL certificate and private key of our frontend servers
• UPDATE 12.40 AM 09-Apr-14 CET+1 we released a new package for Windows with OpenVPN using non-vulnerable OpenSSL

What we will additionally do:

• we're going to add the option to generate new user.key from the client side, with no more need of our manual intervention, just in case someone wishes to use our service for free with your account
• UPDATE 1.50 PM 9-Apr-14 CET+1 We are planning a major change in the system with new RSA and DH keys, new certificates and more. The operation is complex and will cause interruptions to the service. You will need to re-download configuration files, certificates and keys, re-configure DD-WRT/Tomato/pfSense etc. so we are planning it with care. A discussion about it is still ongoing and will go on probably for hours, so we can't provide more details. Please stay tuned.
• UPDATE 11-Apr 14 3 PM CEST IMPORTANT https://airvpn.org/t...ade/#entry16533

What YOU need to do:

• change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFS
• change your user.key when this option will be available
• Windows users only download and install new package with OpenVPN using non-vulnerable OpenSSL https://airvpn.org/windows Allow Air client to upgrade OpenVPN version if required
• OS X Tunnelblick users only download and upgrade to new Tunnelblick with non-vulnerable OpenSSL http://code.google.c...k/wiki/RlsNotes
• UPDATE 11-Apr 14 3 PM CEST IMPORTANT https://airvpn.org/t...ade/#entry16533

Kind regards

[iwih2gk]

I wanted to add a warning here.  Our RAW Airvpn connection is intact.  I hope Air staff is OK with me adding this to protect our members.

 

I have seen many folks starting to use pfsense as their connection security.  The latest pfsense 2.1.1 and also 2.1.0 are ABSOLUTELY AT RISK.  The correction for this is a complete re-do update at the pfsense end.  Not a little patch on their part.

 

If you are using pfsense version > 2.0.3 you are at risk, without question.

 

 

EDIT:  I see you already addressed our concerns here. I deleted the rest of this post.  Thank you for being so on top of things!!

[pfSense_fan]

Thank you Staff, this is the reply some, if not many of us, were looking for.

 

This is what needed to be done.

[pfSense_fan]

I wanted to add a warning here.  Our RAW Airvpn connection is intact.  I hope Air staff is OK with me adding this to protect our members.

 

I have seen many folks starting to use pfsense as their connection security.  The latest pfsense 2.1.1 and also 2.1.0 are ABSOLUTELY AT RISK.  The correction for this is a complete re-do update at the pfsense end.  Not a little patch on their part.

 

If you are using pfsense version > 2.0.3 you are at risk, without question.

 

It is not just pfSense, but any OpenVPN client that does not have the updated OpenSSL in it. This includes any consumer grade router with pre-installed OpenVPN, which would require firmware updates. It would also be the case for any software based client that is not yet updated. The question is, does this vulnerability affect only the server, or can a client cause this heartbeat issue even if the server does not have it?

 

At any rate pfSense looks to be fast-tracking a 2.1.2 release, with a note there will be no pre-release.

 

I would also like to read/see a little detail expanded upon by Air mgmt.  e.g. - when I am connected using Linux through Ubuntu, I would like to know if anything on my end needs a change.  When I get home I will look over my openvpn configuration.  I simply use ubuntu's manager Air's cert's to connect.  My firewall is solid.

 

The members are just looking for a little TLC and reassurance that our connections don't need adjusting.  If they do, thats fine.  Much better than a surprise later that we have been compromised for months and never saw it coming.

 

I agree, but that is for another post.

[dwright]

Great response, thanks for this staff!

[trekkie.forever]

What about OpenVPN clients like the AirVPN/Tunnelblick client for PC/Mac and the iOS OpenVPN client. If they use a vulnerable version of OpenSSL, how does that affect the fact that the servers are not running vulnerable versions of Open SSL?

 

Thanks.

 

 

What YOU need to do:

• change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFS
• change your user.key when this option will be available

[Staff]

What about OpenVPN clients like the AirVPN/Tunnelblick client for PC/Mac and the iOS OpenVPN client. If they use a vulnerable version of OpenSSL, how does that affect the fact that the servers are not running vulnerable versions of Open SSL?

 

Thanks.

 

 

What YOU need to do:

• change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFS
• change your user.key when this option will be available

 

Hello!

 

The attacker should perform attacks against your node, not ours. Assuming that the attacker knows your real IP address, then the attacker can try to exploit the Heartbleed vulnerability. Please upgrade to Tunnelblick 3.4beta22 build 3789 which implements OpenSSL 1.0.1g.

 

http://code.google.c...k/wiki/RlsNotes

 

About Android and iOS, openvpn-connect does not use OpenSSL, it employs PolarSSL which (as far as we know) is not affected by this vulnerability.

 

Kind regards

[trekkie.forever]

What about the AirVPN client for Windows? I assume you are working on a fix for it and will be released soon?

 

Thanks.

 

 

 

What about OpenVPN clients like the AirVPN/Tunnelblick client for PC/Mac and the iOS OpenVPN client. If they use a vulnerable version of OpenSSL, how does that affect the fact that the servers are not running vulnerable versions of Open SSL?

 

Thanks.

 

 

What YOU need to do:

• change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFS
• change your user.key when this option will be available

 

Hello!

 

The attacker should perform attacks against your node, not ours. Assuming that the attacker knows your real IP address, then the attacker can try to exploit the Heartbleed vulnerability. Please upgrade to Tunnelblick 3.4beta22 build 3789 which implements OpenSSL 1.0.1g.

 

http://code.google.c...k/wiki/RlsNotes

 

About Android and iOS, openvpn-connect does not use OpenSSL, it employs PolarSSL which (as far as we know) is not affected by this vulnerability.

 

Kind regards

[trekkie.forever]

Check your favorite website for the vulnerability here

 

http://filippo.io/Heartbleed/

[Staff]

Check your favorite website for the vulnerability here

 

http://filippo.io/Heartbleed/

 

Even nicer: https://www.ssllabs....ml?d=airvpn.org

 

Kind regards

[24FWgGC]

I noticed that OpenVPN has released an update for the client side as well. I'm reading mixed information online that this could also target the client side of a connection.

Should everyone update the client installed on their computer as well?

 

https://openvpn.net/...-downloads.html

[the ineffable me]

As it's not been explicitly said:  review any cryptocurrency services you're into;  even the Bitcoin core wallet requires a security update:  https://bitcoin.org/en/release/v0.9.1

[NaDre]

What about the AirVPN client for Windows? I assume you are working on a fix for it and will be released soon?
 
Thanks.
 
...

 

I believe that the AirVPN client is just a wrapper around the standard OpenVPN client. A new release of the OpenVPN client with the fixed release of OpenSSL was released today/yesterday. See here:

http://openvpn.net/i.../downloads.html

 

Quoting, "The I004 Windows installer includes OpenSSL 1.0.1g, ...". The I004 version was released April 8, 2014, as you can see by looking at the full set of releases of OpenVPN here:

 

http://swupdate.open...unity/releases/

 

I believe that the installation of the AirVPN client involves running the OpenVPN client installer. So if you do not want to wait for a new package from AirVPN, you could just update the OpenVPN client yourself.

[xpomul]

• some of our OpenVPN servers used a vulnerable OpenSSL version. They have been all updated and upgraded between 3 PM and 6 PM 08-Apr-14 CET+1. The non-updated VPN servers running branches of OpenSSL like 0.9.8 were not and are not vulnerable. Assuming that an attacker could steal your user.key during the handshake on those servers, the worst damage is that he/she will connect with your account in the future (see below for a solution to this problem). He/she will not be able to decrypt your OpenVPN Data Channel. Various factors help mitigate the problem even on those vulnerable VPN servers: the attacker could not perform an attack through the exit-IP address (he/she should have known the entry-IP) and Perfect Forward Secrecy does not allow the attacker to decrypt your data

 

I don't understand completely.
The Heartbleed bug would have made it possible not only to steal the user-private-keys but more importantly the server private key.

Are these revoked and replaced for the at time vulnerable systems and are you issuing CRLs for them?

 

An attacker who gained posession of the private key in the two years the vulnerability existed could otherwise still pose as you and so perform MITM.