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, <j.witvl...@mindef.nl> wrote:
> 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-keys, but how about keys stored on smartcards?
>
> Those keys cannot be replaced L
>
>
>
> Hw
>
>
>
> *From:* Joe Patterson [mailto:j.m.patter...@gmail.com]
> *Sent:* dinsdag 8 april 2014 15:55
> *To:* Jakob Curdes
> *Cc:* openvpn users list (openvpn-users@lists.sourceforge.net)
> *Subject:* Re: [Openvpn-users] Does OpenVPN use the TLS heartbeat
> extension? (OpenSSL Security Advisory CVE-2014-0160)
>
>
>
> 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. But the frustrating thing here is that, as a client, it's hard to
> be certain that the server you are connecting to has been patched, or even
> if it has been, that its key was not compromised before it was patched.
>
>
>
> On Tue, Apr 8, 2014 at 9:48 AM, Jakob Curdes <j...@info-systems.de> wrote:
>
>
> 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 compromise the server's private key, plus usernames,
> passwords, and session keys of other clients of that VPN service.
>
> But I think this only holds if the ***Server*** openssl library is still
> vulnerable. The client never gets the server's private key, so it cannot be
> proliferated in this way. Naturally we all need to update the servers ASAP,
> but can we continue to use clients with old openssl DLL's?
>
> JC
>
>
> ------------------------------
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> electronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
>
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
