Re: [Openvpn-users] Openvpn security on VPS-es

[Stephan Alz]

 

Hello

 

I solved this, it wasn't because the Android client didn't support it but it cached in old settings certificate files somewhere. I use the standard openvpn app which comes up to number1 in the playstore.

I did try to reboot my phone multiple time but it didn't help. What helped was to uninstall the app completely then reinstall it and import the new ovpn files again.


Sent: Friday, September 26, 2014 at 3:05 PM
From: "Steffan Karger" 
To: "Doug Lytle" 
Cc: openvpn-users@lists.sourceforge.net
Subject: Re: [Openvpn-users] Openvpn security on VPS-es



On 26 Sep 2014 07:37, "Doug Lytle" <supp...@drdos.info> wrote:
>
> >> Well my problem with this additional tls-auth method is that the droid version does not support it yet:
>
> I don't have any problems with tls-auth using Feat-VPN on my Droid.
>
> http://www.featvpn.com/

Or use the original open source 'OpenVPN for Android' app, which is maintained by one of the openvpn core developers. Works just fine with tls-auth for me.

-Steffan
-- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users




--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Gert Doering]

Hi,

as far as "admin cannot sniff on vmware or kvm" - well, if the admin 
controls the hypervisor, he can see all the memory of your VM, and see
and control everything it does.

If he really wants, he can just flip a few bytes in your virtual
/etc/passwd, login as root into your VM, and sniff on the inside tun
interface.

Or grab the decrypted bytes from memory frmo the outside...

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpIUbXR8QtOR.pgp
Description: PGP signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Steffan Karger]

On 26 Sep 2014 07:37, "Doug Lytle"  wrote:
>
> >> Well my problem with this additional tls-auth method is that the droid
version does not support it yet:
>
> I don't have any problems with tls-auth using Feat-VPN on my Droid.
>
> http://www.featvpn.com/

Or use the original open source 'OpenVPN for Android' app, which is
maintained by one of the openvpn core developers. Works just fine with
tls-auth for me.

-Steffan
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Doug Lytle]

>> Well my problem with this additional tls-auth method is that the droid 
>> version does not support it yet:

I don't have any problems with tls-auth using Feat-VPN on my Droid.

http://www.featvpn.com/

Doug

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Stephan Alz]

 

Hello

 

Well my problem with this additional tls-auth method is that the droid version does not support it yet:

 

http://lgallardo.com/en/2011/09/12/openvpn-en-android-cyangenmod/

 

I would get: TLS Error: cannot locate HMAC in incoming packet from

on the devices if I would turn on this additional security feature.

 

About that the admins are able to sniff on tun devices that might be true for light paravirtualizations like OpenVZ but definitely not for kvm,vmware and the others.

Maybe that's why these are deemed to be *more secure*. Basically kvm uses the linux bridging (br0) device to bridge it's ethernet interface to, vmware has it's own bridge adapter but the point is that an admin cannot sniff on any internal tun/tap device of a guest and what comes out the main ethernet device those are already encrypted udp packets.

 

I wonder if regularily (monthly) regenerating all the certificates (rootca, server, clients) and replacing them on all the devices would help in this case or not.

 


Sent: Thursday, September 25, 2014 at 5:16 AM
From: "Steffan Karger" 
To: openvpn-users@lists.sourceforge.net
Subject: Re: [Openvpn-users] Openvpn security on VPS-es

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 24-09-14 11:21, David Sommerseth wrote:
> On 24/09/14 10:26, David Sommerseth wrote:
>> On 24/09/14 10:15, Gert Doering wrote:
>>>> But to get to the point, that if I setup openvpn on my
>>>> droplet and let's say an evil admin sniffing my traffic for 3
>>>> months with tcpdump then decides to decrypt that traffic what
>>>> tools does he have (if any to do this). At this point he has
>>>> a pcap file and the openvpn server certificates and keys.
>
>>> Now that is easy - OpenVPN does PFS, so the stored keys won't
>>> help decrypt sniffed session traffic.
>
>> If an attacker have sniffed the complete handshake and is in
>> possession of the keys, I believe it is a theoretical
>> possibility to compromise the key exchange handshake. Which
>> again gives you the access to the tunnel data. If the attacker
>> in addition have access to client keys, then this process goes
>> even faster. But it is correct that you don't get the raw key
>> out of the handshake.
>
> Gert and I have had a private discussion regarding if it is
> possible or not to break the session key. We both agree that it's
> not an easy task, and capturing data + having they key material
> alone isn't enough to break the session key.

I agree, OpenVPN does offer forward secrecy. At least when the setup
uses TLS-mode (like the howto of digitalocean the OP referred to).

Let me elaborate a bit. OpenVPN can run in two modes:
1. Static key mode (using '--secret '). This uses a pre-shared
static key, which is not rotated at all. An attacker with that key and
a pcap can decrypt all traffic since the last time you (manually)
rotated the key. Unless you know what you're doing and have good
reasons to use it, do not use this mode.

2. Dynamic key mode. This uses TLS to set up a secure channel over
which the actual data encryption keys are exchanged. This mode
protects you as much as TLS does. By default, OpenVPN connections use
a dynamic key exchange, like (Ephemeral) Diffie-Hellman or - for older
versions - Ephemeral RSA. The TLS session keys will then exist at most
(1) between two session negotiations for ephemeral DH, (2) for an
OpenVPN connection for non-ephemeral DH or (3) for the OpenVPN process
lifetime for ephemeral RSA.

For a scenario like the OP describes (pcap + current memory dump), the
attacker can only decrypt traffic for which the current in-memory key
has been used (see above).

Note that this scenario restricts the attacker to be passive (i.e.
just traffic / memory dumps). An active attacker could use a
man-in-the-middle position to attack the cryptographic handshake or
implementation, like David describes. That however does not enable her
to 'go back in time' further then the validity of the keys used during
the attack. Traditionally, we recommend to use OpenVPN's tls-auth
feature as an extra layer of protection against man-in-the-middle
attacks. In this scenario however, the attack already has access to
the tls-auth keys, so that won't help you here. (Still, use tls-auth,
it protects you from a lot of other bad stuff.)

This ended up as more text than I intended. I hope it clarifies more
than it confuses ;)

- -Steffan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUI4j9AAoJEJgCyj0AftKIBCoIAMLpmfGlnZ0rXcuw6yP7f62/
2TRxLSXtRJx/Z211F+s0+y7WOiFe18bkCfNXQI14RJJTLuX1JEZGNNTq4xI6Uhfo
p54q3VzfuYHbx7RwXe5oNxZGaFywiBL70AKT6Icjoqc4EzuYTJVy7N0NpeHV2CCq
TC0RiH3B6s4dhhauqc6ldeNv7Ltld36Lk5vgD5d/wfSJ/EaUOZnF/cgJbz1vzAhL
Xc/jF8+1OjhAAIPhz8M2eU+KKt7txfGJ8+Al4EiUGx2lC9LSgn2MdCNyAQL6W2e

Re: [Openvpn-users] Openvpn security on VPS-es

[Steffan Karger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 24-09-14 11:21, David Sommerseth wrote:
> On 24/09/14 10:26, David Sommerseth wrote:
>> On 24/09/14 10:15, Gert Doering wrote:
 But to get to the point, that if I setup openvpn on my
 droplet and let's say an evil admin sniffing my traffic for 3
 months with tcpdump then decides to decrypt that traffic what
 tools does he have (if any to do this). At this point he has
 a pcap file and the openvpn server certificates and keys.
> 
>>> Now that is easy - OpenVPN does PFS, so the stored keys won't 
>>> help decrypt sniffed session traffic.
> 
>> If an attacker have sniffed the complete handshake and is in 
>> possession of the keys, I believe it is a theoretical
>> possibility to compromise the key exchange handshake.  Which
>> again gives you the access to the tunnel data.  If the attacker
>> in addition have access to client keys, then this process goes
>> even faster.  But it is correct that you don't get the raw key
>> out of the handshake.
> 
> Gert and I have had a private discussion regarding if it is
> possible or not to break the session key.  We both agree that it's
> not an easy task, and capturing data + having they key material
> alone isn't enough to break the session key.

I agree, OpenVPN does offer forward secrecy. At least when the setup
uses TLS-mode (like the howto of digitalocean the OP referred to).

Let me elaborate a bit. OpenVPN can run in two modes:
1. Static key mode (using '--secret '). This uses a pre-shared
static key, which is not rotated at all. An attacker with that key and
a pcap can decrypt all traffic since the last time you (manually)
rotated the key. Unless you know what you're doing and have good
reasons to use it, do not use this mode.

2. Dynamic key mode. This uses TLS to set up a secure channel over
which the actual data encryption keys are exchanged. This mode
protects you as much as TLS does. By default, OpenVPN connections use
a dynamic key exchange, like (Ephemeral) Diffie-Hellman or - for older
versions - Ephemeral RSA. The TLS session keys will then exist at most
(1) between two session negotiations for ephemeral DH, (2) for an
OpenVPN connection for non-ephemeral DH or (3) for the OpenVPN process
lifetime for ephemeral RSA.

For a scenario like the OP describes (pcap + current memory dump), the
attacker can only decrypt traffic for which the current in-memory key
has been used (see above).

Note that this scenario restricts the attacker to be passive (i.e.
just traffic / memory dumps). An active attacker could use a
man-in-the-middle position to attack the cryptographic handshake or
implementation, like David describes. That however does not enable her
to 'go back in time' further then the validity of the keys used during
the attack. Traditionally, we recommend to use OpenVPN's tls-auth
feature as an extra layer of protection against man-in-the-middle
attacks. In this scenario however, the attack already has access to
the tls-auth keys, so that won't help you here. (Still, use tls-auth,
it protects you from a lot of other bad stuff.)

This ended up as more text than I intended. I hope it clarifies more
than it confuses ;)

- -Steffan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUI4j9AAoJEJgCyj0AftKIBCoIAMLpmfGlnZ0rXcuw6yP7f62/
2TRxLSXtRJx/Z211F+s0+y7WOiFe18bkCfNXQI14RJJTLuX1JEZGNNTq4xI6Uhfo
p54q3VzfuYHbx7RwXe5oNxZGaFywiBL70AKT6Icjoqc4EzuYTJVy7N0NpeHV2CCq
TC0RiH3B6s4dhhauqc6ldeNv7Ltld36Lk5vgD5d/wfSJ/EaUOZnF/cgJbz1vzAhL
Xc/jF8+1OjhAAIPhz8M2eU+KKt7txfGJ8+Al4EiUGx2lC9LSgn2MdCNyAQL6W2eu
vohQqq9wBql83zNRaboMMtOg3DD8mADKF2SFYUFqP0c9COrAAe4GuUCY5lBTZnQ=
=b1aU
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/14 10:26, David Sommerseth wrote:
> On 24/09/14 10:15, Gert Doering wrote:
>>> But to get to the point, that if I setup openvpn on my droplet 
>>> and let's say an evil admin sniffing my traffic for 3 months
>>> with tcpdump then decides to decrypt that traffic what tools
>>> does he have (if any to do this). At this point he has a pcap
>>> file and the openvpn server certificates and keys.
> 
>> Now that is easy - OpenVPN does PFS, so the stored keys won't
>> help decrypt sniffed session traffic.
> 
> If an attacker have sniffed the complete handshake and is in 
> possession of the keys, I believe it is a theoretical possibility
> to compromise the key exchange handshake.  Which again gives you
> the access to the tunnel data.  If the attacker in addition have
> access to client keys, then this process goes even faster.  But it
> is correct that you don't get the raw key out of the handshake.

Gert and I have had a private discussion regarding if it is possible
or not to break the session key.  We both agree that it's not an easy
task, and capturing data + having they key material alone isn't enough
to break the session key.  But I believe with that information it is
in theory possible to mount an attack, when weaknesses in the
Diffie-Hellman key exchange are discovered and utilised.

Some papers on these issues related to weaknesses in DH:
 (CVE-2011-5095,
CVE-2011-1923)



What I'm actually saying is that no packets passing over the Internet
is safe forever.  There will always be weaknesses discovered which can
be used.  So the important aspect of encryption isn't to make it safe
forever, but to protect it as long as possible as the data has value
for an attacker.  In this regard, I'm one of those who don't think the
word "Perfect" in PFS is appropriate, because it never will be 100%
perfect.

However, one more point we've forgotten to mention, which is fare more
important:  random data

You must have good quality of the random data when generating
private/public keys and dhparams.  Otherwise the keys can more easily
be compromised.  And you should as much as possible avoid generating
keys on virtual machines, as the random data on those machines often
can be weaker.

These are a few of the papers on this topic:





- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQijTMACgkQDC186MBRfrqNbwCcCdEDgymFROwsF4T/Ai64yoNZ
058An1gMF1VkAHUbOFc9gUoOEbWOoLjU
=nv1k
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/14 10:15, Gert Doering wrote:
>> But to get to the point, that if I setup openvpn on my droplet
>> and let's say an evil admin sniffing my traffic for 3 months with
>> tcpdump then decides to decrypt that traffic what tools does he
>> have (if any to do this). At this point he has a pcap file and
>> the openvpn server certificates and keys.
> 
> Now that is easy - OpenVPN does PFS, so the stored keys won't help
> decrypt sniffed session traffic.

If an attacker have sniffed the complete handshake and is in
possession of the keys, I believe it is a theoretical possibility to
compromise the key exchange handshake.  Which again gives you the
access to the tunnel data.  If the attacker in addition have access to
client keys, then this process goes even faster.  But it is correct
that you don't get the raw key out of the handshake.

- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQigC0ACgkQDC186MBRfrrwGwCbBxX3NGm6CqsaHTSdJjO+gRqS
8HsAmwet8HLyrGFnEQUuHml/y62/wxvI
=flwL
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/14 09:50, Stephan Alz wrote:
[...snip...]
> There isn't much point of encrypting the droplet's filesystem when 
> the key can easily be dumped out of memory.
> 
> But to get to the point, that if I setup openvpn on my droplet and 
> let's say an evil admin sniffing my traffic for 3 months with 
> tcpdump then decides to decrypt that traffic what tools does he 
> have (if any to do this). At this point he has a pcap file and the
>  openvpn server certificates and keys.
> 
> I only refer to the encrypted traffic between the droplet and my 
> computer. Obviously if I use this droplet to route all my traffic 
> through it then he can sniff all the outgoing un-encrypted traffic
>  to the internet.
> 
> The reason why I ask this is because IPSec provides Perfect
> Forward Secrecy which if it's turned on would make it impossible to
> decrypt that sniffed traffic later, even if the attacker have all
> the keys.

As long as a server admin can access your openvpn (or IPSec keys, for
that matter), any traffic sniffed and saved can be compromised.  There
are no ways around that.

Any server-admin can access your file systems outside of your VM if
the disk isn't encrypted (libguestfs/guestfish, f.ex).  And if the
disk is encrypted, it is the RAM which is still possible to dump, but
that will be harder to extract the keys from as the location of the
keys isn't necessarily that obvious (but it is doable).

PFS is a hard thing to accomplish, and it doesn't help when some
vendors claim to have PFS which may in fact be a misguided statement.
 I'm not cryptologist, so I'm on thin ice here.  But how I understand
it, if OpenVPN is properly configured with unique certificates to all
servers and clients, using your own securely setup CA, and with
- --reneg-* and --tls-auth options enabled, then OpenVPN provides a
fairly good level of PFS.

But there are many pitfalls which is easy to fall into, which again
may break PFS.  Some might even call it PFS without --tls-auth, as
well.  If removing key re-negotiations will again break PFS.  So it's
not an easy yes/no answer, due to the flexibility of OpenVPN.


- -- 
kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQifwEACgkQDC186MBRfrqShACffpda6Sh17eSad+T+3tcYZ7EP
SmIAn3G+wi8KTaqUx/vfK6KUDDi1KzG5
=rlhH
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Gert Doering]

Hi,

On Wed, Sep 24, 2014 at 09:50:35AM +0200, Stephan Alz wrote:
> With the widespread of the cheap vps cloud services lately I wonder what 
> protection does openvpn offers ... well against the server administrators.

If the server admin has root, he can sniff on the tun interface, or
grab keys from openvpn memory - so "not much protection".

[..]
> But to get to the point, that if I setup openvpn on my droplet and let's say 
> an evil admin sniffing my traffic for 3 months with tcpdump then decides to 
> decrypt that traffic what tools does he have (if any to do this). At this 
> point he has a pcap file and the openvpn server certificates and keys.

Now that is easy - OpenVPN does PFS, so the stored keys won't help decrypt 
sniffed session traffic.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpFm719mbTj9.pgp
Description: PGP signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] Openvpn security on VPS-es

[Stephan Alz]

Hello,
 
With the widespread of the cheap vps cloud services lately I wonder what 
protection does openvpn offers ... well against the server administrators.
 
https://www.digitalocean.com/community/tutorials/how-to-secure-traffic-between-vps-using-openvpn
 
It's obvious that no virtualization technology, whether it is openvz, kvm, 
vmware, virtualbox offers security against those who have full control of the 
host machine. Some of these virtualizations deemed to be *more secure* in 
comparisons like kvm over openvz but the bottom line is that a servers 
administrator can make a snapshot of the vps (droplet) any time, have access to 
all the files and the vm's memory.
 
There isn't much point of encrypting the droplet's filesystem when the key can 
easily be dumped out of memory.
 
But to get to the point, that if I setup openvpn on my droplet and let's say an 
evil admin sniffing my traffic for 3 months with tcpdump then decides to 
decrypt that traffic what tools does he have (if any to do this). At this point 
he has a pcap file and the openvpn server certificates and keys.
 
I only refer to the encrypted traffic between the droplet and my computer. 
Obviously if I use this droplet to route all my traffic through it then he can 
sniff all the outgoing un-encrypted traffic to the internet.
 
The reason why I ask this is because IPSec provides Perfect Forward Secrecy 
which if it's turned on would make it impossible to decrypt that sniffed 
traffic later, even if the attacker have all the keys.
 
 
Thanks
 

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users