[pfSense] Can pfSense be considered trusted? What implementations of VPNs can now be trusted?

Thu Oct 10 08:41:58 PDT 2013

----- Forwarded message from Ian Bowers <iggdawg at gmail.com> -----

Date: Thu, 10 Oct 2013 10:13:51 -0400
From: Ian Bowers <iggdawg at gmail.com>
To: pfSense support and discussion <list at lists.pfsense.org>
Subject: Re: [pfSense] Can pfSense be considered trusted? What implementations of VPNs can now be trusted?
Message-ID: <CAOtTuaoHDtm21xvTW941JTBgj3Wo93TxZ7X25ECFS7WPbi+_7Q at mail.gmail.com>
Reply-To: pfSense support and discussion <list at lists.pfsense.org>

On Thu, Oct 10, 2013 at 9:50 AM, Giles Coochey <giles at coochey.net> wrote:

>  Trying to get this back on-topic, I will change the subject however, to
> alleviate the issues the anti-tin-foil-hat-brigade have. (ps I am also
> top-posting on purpose as I believe the conversation below has near to no
> relevance to my questions, but simply is an argument as to whether these
> questions should be asked, to which I believe in the affirmative).
>
> I have various questions to offer for discussion  which have been
> bothering me since various security related issues that have appeared in
> the media recently: (see: https://www.schneier.com/crypto-gram-1309.html)
>
> Clearly, at the moment, open source security tools ought to have an
> advantage over closed-source tools. However, peer review of open-source
> code is not always complete, and there have been questions whether even
> algorithms have been subverted.
>
> 1. The random number generator - As pfSense uses FreeBSD this may well be
> a FreeBSD specific question, however, are there any ways within pfsense
> that we can improve the entropy pool that the random number gets its
> randomness from? Has anyone had any experience of implementing an external
> entropy source (e.g. http://www.entropykey.co.uk/) in pfsense?
> 2. Cipher Selection - we're not all cryptoanalysts, so statements like
> 'trust the math' don't always mean much to us, given the reports in the
> media, what is considered a safe cypher? I recently switched from AES-256
> to Blowfish-256, hashing from SHA-1 to SHA-512 and pfs group 2 to pfs group
> 5, and I reduced my SA lifetimes from 28800 to 1800. Could that be
> considered overkill? What Cipher's are others using? Have any of you, who
> have been made recently aware of the media coverage recently, also changed
> your cipher selection? What kind of changes did you make?
> 3. pfSense - In general do you consider pfsense secure?? As we are
> apparently told, asking whether the NSA has inserted or influenced the code
> in any way either in the pfsense code, or the upstream base (FreeBSD) is a
> question that we can't ask, as if it were the case then the NSA would have
> instructed someone in the know, to answer in the no.
>
>
>
>
1)  I don't have the expertise to talk about RNGs in such a way that I feel
confident that my response is something other people should actually listen
to.  The good ones are based on thermal noise or some other sort of "truly"
random source.  but flaws in the software that processes this can make it
less random.  This is a rabbit hole I've chosen not to dive down yet, but
made it a point to be aware of and follow along with as things unfold.  So
I'll defer to others here.

2) Apologies for answering out of order, but it's early and my brain is
working that way.  PFS group 5 is typically a good functional minimum, I
bump it up where appropriate, but I find in the higher PFS group I run into
interop issues when connecting to different vendors.  Most everything
supports groups 1, 2, and 5, but 5 is my minimum unless someone has a good
reason.  Cisco has a reputation for support of legacy protocols and
configurations (which is a double edged sword for sure), and even they are
saying groups 1 and 2 should not be used.  For SA lifetimes I'm ok with
28800 for phase 1, and 3600 for phase 2.  Phase 2 is really where you need
to mix it up frequently.  it's less important with phase 1.  Opinions on
this differ, but if you have PFS in play on phase 2, the lifetime of phase
1 becomes much less important.   But play it how you like it, modern CPUs
have the horsepower to renegotiate frequently.   For encryption ciphers I
rock AES-256 all day every day when I can.  I've done my homework on the
AES development and selection process, and I'm satisfied (for now) with how
open it was and how it was critiqued.   It's also the strongest encryption
cipher that with widespread support, and even on my home network I have
LAN-2-LAN tunnels to multiple vendors' gear.   roll that into how primitive
many remote access clients can be, and AES-256 typically comes out on top
as the best you can get and still have a good chance of your peer
supporting it.   As far as hashing, I'm still rocking SHA-1 for now because
I see abuse of the hashing algorithm for a functional attack as something
that would only realistically be used in a real-time man in the middle type
attack.  A lot of other cards have to have fallen down for this to become a
problem.  I'm under that kind of attack, I've got bigger problems.  That
being said, I can't think of a good reason NOT to bump up hashing either.
 so play it as you like it.

3) FreeBSD is very mature, and very well reviewed.  I've looked into
FreeBSD to my personal satisfaction.  OpenBSD may be abrasive as a
community at times, but their work product is pretty impressive in terms of
being clean and funcitonal.  I was very happy with how they handled that
whole IPSec fiasco in 2011.  I've been following pfSense for a while now,
and I've used it off and on for years.  I'm very satisfied by the quality
and oversight of the coding.   But by all means dig as long as your
curiosity holds out.  you can never be "100% sure" of the security of any
software, but "sufficiently sure" is absolutely worth looking into.

Ian

_______________________________________________
List mailing list
List at lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5