OpenSSL Heartbleed Bug - TLS/SSL Vulnerability

[Hank3 0]

Will you add support for TLS-Auth? It would have protected against this:
"Client/server connections that utilize TLS auth, and the keys have been kept secure, are also safe, as they prevent a needed MITM attack needed to compromise the connection."

https://forums.openvpn.net/topic15526.html
 

[Staff 9971]

Will you add support for TLS-Auth? It would have protected against this:

"Client/server connections that utilize TLS auth, and the keys have been kept secure, are also safe, as they prevent a needed MITM attack needed to compromise the connection."

https://forums.openvpn.net/topic15526.html

 

 

Hello,

 

yes, TLS Auth shall be implemented. Stay tuned.

 

Kind regards

[choq 7]

This is an example how to inform members. This is great, and well done (airvpn) staff. Crystall clear. Thank you all.

[koloc-1458-261 0]

Yes, thank you to the airvpn staff for this quick response and your policy of transparency. Btw, maybe it is prudent in future to use the airvpn feature of tunneling VPN over SSH. As far as I know SSH uses the basic functionality of SSL, but without the TLS Heartbeat extension. Apart from this specific problem, I think mixing different instances of encryption could perhaps provide an additional layer of security.

[SaveSnowden 5]

 

 

• 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.

 

This is my question too. We think we are signing in to AirVPN to generate new keys, but how do we know we are not signing in to an NSA MITM to download new keys that they get a copy of as well? If the NSA got the server master keys then they will have the capability to perform a MITM (or at least decrypt) very easily. It looks like the only way to be assured is to download the new user keys through a medium that has not been compromised currently. Now if AirVPN explicitly revokes their old certificate, the NSA should not be able to get access to new data going forward.

 

Also staff should make sure that they have created a new public/private key pair. It is not enough to get a new certificate based on the same private keys, a new pair needs to be generated, and then a new certificate. Unfortunately we have no way of verifying which web services have actually generated new keys and which ones have just issued new certificated based on the old private key.

 

Edit: Where is the link to generate new client keys? I would like to reset mine.

[pfSense_fan 181]

 

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!!

I'm running pfsense 2.1 and i just checked the openssl version and it's 0.9.8y.

 

You are mistaken.

 

The core operating system used 0.9.8y, but each package used it's own packed version of OpenSSL. The webcnfigurator, OpenVPN and other packages were all vulnerable.

 

They have issued an update, and 2.1.2 has come out less than a week after the release of 2.1.1

 

Please update!

[Staff 9971]

This is my question too. We think we are signing in to AirVPN to generate new keys, but how do we know we are not signing in to an NSA MITM to download new keys that they get a copy of as well? If the NSA got the server master keys then they will have the capability to perform a MITM (or at least decrypt) very easily. It looks like the only way to be assured is to download the new user keys through a medium that has not been compromised currently. Now if AirVPN explicitly revokes their old certificate, the NSA should not be able to get access to new data going forward.

Hello!

 

Of course. It appears that you have not followed https://airvpn.org/topic/11298-openssl-heartbleed-bug-tlsssl-vulnerability/?do=findComment&comment=16461 in the last three days but we strongly recommend that you do that.

 

UPDATE 11.15 PM 08-Apr-14 CET+1 we changed the SSL certificate and private key of our frontend servers

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)

 

 

 

Also staff should make sure that they have created a new public/private key pair. It is not enough to get a new certificate based on the same private keys, a new pair needs to be generated, and then a new certificate. Unfortunately we have no way of verifying which web services have actually generated new keys and which ones have just issued new certificated based on the old private key.

 

Edit: Where is the link to generate new client keys? I would like to reset mine.

 

Of course. Please follow our recommendation. It is premature to allow generation of new private keys as long as the old certificate is not revoked (revocation ordered on 8-Apr, so it should go into effect real soon now) and anyway client private key leak is not such a big deal. Stay tuned, an important announcement is due in a few hours.

 

EDIT: announcement published https://airvpn.org/topic/11319-major-system-upgrade/

 

Kind regards

[aoeirntt 0]

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.com/p/tunnelblick/wiki/RlsNotes
• UPDATE 11-Apr 14 3 PM CEST IMPORTANT https://airvpn.org/topic/11319-major-system-upgrade/?do=findComment&comment=16533

Kind regards

 

Hi,

 

Can any of you please explain what the second bullet point above meens and how I can perform what it describes?

 

Thanks in advance!