[Ach] OpenVPN and ACH

L. Aaron Kaplan aaron at lo-res.org
Thu Feb 19 02:17:09 CET 2015


On Feb 18, 2015, at 8:34 PM, Reed Loden <reed at reedloden.com> wrote:

> Just to follow-up to what Thomas said...
> 
> I worry about throwing OpenVPN away so quickly... It's used by *lots* of people and companies, and it's not going away anytime soon.

+1 !
> I agree that until they have patches like https://community.openvpn.net/openvpn/ticket/301 landed that it's not going to be viably secure, but I worry about the complete lack of OpenVPN detail that people are going to either use the defaults or use random hardening guides that don't give the entire picture.
> 
> I think ACH should continue to mention OpenVPN with warnings about it being insecure until certain features/patches are added.

agreed!

> Basically, provide the best possible 'secure' config with what it supports today and continue to evolve that over time as OpenVPN improves. Mention to people the specific things it lacks in order to be properly secure as per ACH standards so they know the risks they are taking by using it.
> 

I think that's more sensible than removing it.
Better have it in there with warnings and explanations than not at all, since that then would leave plenty of interpretation space for users and actually lead to even less secure settings.

a.

> just my 2c,
> ~reed
> 
> On Wed, Feb 18, 2015 at 11:11 AM, Thomas Preissler <thomas at preissler.co.uk> wrote:
> On Wed, Feb 18, 2015 at 07:48:21PM +0100, Aaron Zauner wrote:
> > Hi,
> >
> > https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91
> >
> > I've since removed (commented-out) the OpenVPN section in our document
> > in commit 7b6fd17814acdbb2304ca3e84e99b02fe919abe6.
> >
> > If anybody is interested in maintaining and reviewing this, please speak
> > up. To the best of my knowledge OpenVPN is not suitable for our document
> > -- CBC-only support (not as a fallback) is a real threat to the
> > transport security. Hence I would not recommend using it myself and have
> > thus removed it from our document for the time being.
> 
> Considering that more and more people will use this document to
> 'securely' configure their server, but an increasing number of those
> won't necessarily understand the implications why certain services are
> configured that way.
> 
> For example, I read somewhere that quite a number of people just use
> certain 'recommendations' somewhere to configure their webserver, then
> go off to SSLlabs and when they get at least an A rating, they are
> happy - admitting they have no clue, what they have just reconfigured.
> 
> I believe that this should go in there, as it is not secure. And you
> gave good reasons why it cannot be secure.
> In general, I think it is not a matter of configuring encryption
> securely, it is also about getting the message out that certain services
> are inherently insecure. How else would they stop using it when they
> don't know about it? You could also see this as a wakeup-call for
> developers, maybe to work more closely with cryptographers.
> You also have now a note on SHA-1 in it...
> 
> Otherwise people will assume, OpenVPN default's are 'secure',
> configure it themselves with some random tutorial they found somewhere,
> or worse, use some exciting DES encryption - because that's what they
> remember.
> 
> 
> Kind Regards
> 
> Thomas
> 
> --
> www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415
> GPG Fingerprint:  CCBD 153A D257 CA7E A217  FDF7 5928 03D1 7588 9415
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20150219/33bf3d11/attachment.sig>


More information about the Ach mailing list