HN user
Upload a package to PyPI or Node.js that emits specially crafted console output as part of its installer.
If someone runs my installer without checking the contents, why would I need UTF-8 bugs to get code executed?
(Not meant to downplay this bug, but the example made me wonder...)
Note that this is specifically OpenVPN on Windows, since the Windows installers ship with their own openssl dll (and as already said by the other commenter, a new installer was made available around the time of your post). All other platforms simply use the system library.
Thanks for elaborating.
The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent.
I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack.
To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question.
For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters.
Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it is a problem with smaller groups.
It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe.... exists.
This draft /does/ encourages use of larger keys, but also encourages the use of common parameter groups. The weakdh.org site mentions the use of common groups is a reason for this attack to be feasible. It also advises sysadmins to generate their own parameters. To me, that makes using common groups sound like a bad move.
The problem is, I lack proper knowledge to assess whether using common groups really is a bad move, even when using larger group sizes... Anyone here who can?
You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do).
OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--...
This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.
You should do that for all your vulnerable peers (i.e. clients too), and restart the daemon to make it load the updated library. Then generate new keys for all of them.
While there are vulnerable clients out there, you should consider your (vpn) network compromised.
Yes, this has been introduced in the original heartbeat extension commit (01-01-2012):
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=bd69...