----- Forwarded message from Ian Bowers
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@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