Thanks for the information. Ill appreciate any further insight on the
following: -
1. Should we uninstall and then re-install the 2.3.3 on all Windows clients?
Or should we install 2.3.3 without uninstalling previous version?
2. Our server is running on Windows as well. So we will need to install
Hi,
On Tue, Apr 08, 2014 at 01:46:43PM +0200, Fredrik Strömberg wrote:
> When can we expect a new version for Windows to be released?
http://openvpn.net/index.php/open-source/downloads.html
has openvpn-install-2.3.2-I004-*.exe now, which is 2.3.2 with OpenSSL
1.0.1g (and no other changes as comp
This apparently went out as HTML; Sorry about that. I've told my mail
client to use plaintext for the list.
You may have seen a subset of this on forums.openvpn.net; if so, sorry
for the dual posting, but I'm new to openvpn. This seems like a better
place.
Three cert-related issues:*
**
**
You may have seen a subset of this on forums.openvpn.net; if so, sorry
for the dual posting, but I'm new to openvpn. This seems like a better
place.
Three cert-related issues:*
**
**Documentation:*
I got *--cryptoapicert* to work with "SUBJ:" selectors. The
documentation for the "SUBJ:" form
To get to some features that I want from master, I'm trying to
cross-build for the Raspberry PI.
The host is a 32-bit x86 Fedora 20. It's a new VPS, so there's not much
cruft lying about.
The target is debian (Wheezy) as distributed by RPI
I have made no changes to build or build.vars; I do
I'll clarify my thoughts.
> Am 08.04.2014 15:13, schrieb Joe Patterson:
>> I think that what's being referred to here is that a VPN service with
>> multiple independent clients could have one nefarious client who used
>> a valid client key/cert to establish a session, then used that session
>> plu
Hi Erich,
On 08/04/14 18:03, Erich Titl wrote:
> Hi JJK
>
> at 08.04.2014 15:09, Jan Just Keijser wrote:
>> Hi Erich,
>>
>
> For simplicity I upgraded the client to 2.3.2 and I am seeing the same
> error.
>
> Tue Apr 08 16:58:09 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL
> (OpenSSL)] [LZO] [PKCS11
Hi JJK
at 08.04.2014 15:09, Jan Just Keijser wrote:
> Hi Erich,
>
For simplicity I upgraded the client to 2.3.2 and I am seeing the same
error.
Tue Apr 08 16:58:09 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)]
[LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Enter Management Passwor
Hi JJK
at 08.04.2014 15:09, Jan Just Keijser wrote:
...
>>
>> Anyone found a _real_ reason for this error?
>>
> openvpn (and openssl) will trust a self-signed certificate if it is used
> as a trusted CA cert; this is what the "ca " option is used for.
> Which machine is reporting the error? th
> As I understand this attack, it gives the attacker access to memory.
> Smartcard keys aren't stored in system memory, and I believe are generally
> not even directly accessible, so I would tentatively say that they are safe.
>
> -Joe
Yep. Keys stored on smart cards are not affected since not eve
As I understand this attack, it gives the attacker access to memory.
Smartcard keys aren't stored in system memory, and I believe are generally
not even directly accessible, so I would tentatively say that they are
safe.
-Joe
On Tue, Apr 8, 2014 at 10:31 AM, wrote:
> Just wondering...
>
> Thi
Just wondering...
This bleeding isn't only about openvpn, but all that uses an unpatch
openssl-lib.
On the heartbleed-bug-live-blog, they advice to regenerate private-key, and
request/replace ssl-certificate. Just in case.
That is all very well for people using self-signed certs and file based-k
Hi Erich,
On 08/04/14 15:56, Erich Titl wrote:
> Hi folks
>
> After a long absence from OpenVPN I am running into the self signed
> certificate error all of a sudden.
>
> Tue Apr 08 14:47:53 2014 UDPv4 link local: [undef]
> Tue Apr 08 14:47:53 2014 UDPv4 link remote: 212.41.199.16:1194
> Tue Apr 0
Hi folks
After a long absence from OpenVPN I am running into the self signed
certificate error all of a sudden.
Tue Apr 08 14:47:53 2014 UDPv4 link local: [undef]
Tue Apr 08 14:47:53 2014 UDPv4 link remote: 212.41.199.16:1194
Tue Apr 08 14:47:53 2014 TLS: Initial packet from 212.41.199.16:1194,
Very true. I mean, a malicious server could compromise clients, but I was
thinking more along the lines of malicious clients compromising servers,
which would require the server to be un-patched. If you run a server,
definitely patch. If you're a client, patch anyway, for reasons beyond
openvpn.
Am 08.04.2014 15:13, schrieb Joe Patterson:
> I think that what's being referred to here is that a VPN service with
> multiple independent clients could have one nefarious client who used
> a valid client key/cert to establish a session, then used that session
> plus this vulnerability to compr
I think that what's being referred to here is that a VPN service with
multiple independent clients could have one nefarious client who used a
valid client key/cert to establish a session, then used that session plus
this vulnerability to compromise the server's private key, plus usernames,
password
> Thank you James. I reached the same conclusion myself. I've been
> working on it since early this morning.
>
> This means that most consumer VPN services are at least vulnerable to
> getting their private TLS key stolen, and also usernames, passwords,
> session keys and so on. As you pointed ou
Thank you James. I reached the same conclusion myself. I've been
working on it since early this morning.
This means that most consumer VPN services are at least vulnerable to
getting their private TLS key stolen, and also usernames, passwords,
session keys and so on. As you pointed out, tls-auth i
19 matches
Mail list logo
