On 9/10/07, Denny Page <[EMAIL PROTECTED]> wrote: > Scott/Chris, > > Agree that the padlock it is not a security issue. It does represent a > serious performance issue however. > > I installed the pfSense developer system > (http://pfsense.untouchable.net/downloads/developers/pfSense-1.2-BETA-1.iso.gz) > to see what would be required to build a corrected version. I was further > surprised to find that the OpenSSL in the development environment > (/usr/src/crypto/openssl/cryptio/engine/eng_padlock.c) > already has the patch installed. > > I have no prior experience with the pfSense developer environment, so please > forgive me if this is a stupid question: Is there any reason that the fix > appears to be present in the 1.2 Beta developer source but not in the 1.2RC2 > binary distribution? > > Or am I just horribly confused... > > Denny > > > > On Sep 10, 2007, at 09:33 , Chris Buechler wrote: > > It's not a security issue regardless, it could be a performance issue where > you can't take full advantage of the padlock functionality if indeed that > fix is not already in FreeBSD. I doubt if a 2+ year old fix isn't already > included in FreeBSD 6.2, though since we don't support it, it doesn't > matter. > > > Scott Ullrich wrote: > We do not use padlock as of yet. You are safe. > > Scott > > > On 9/9/07, David L. Strout <[EMAIL PROTECTED]> wrote: > > > > Ticket #1447 > > In browsing the ticket system I came accross this ticket and wondered if I > should be concerned with this. I have recently switched all of my > roadwarrior VPN users over to OpenVPN and have several sites using site2site > OpenVPN tunnels. I read the associated technical documentation as well as > Googled for a remedy to this issue. > > My concern is this, I have just spent many months converting all of my users > and explaining to them the insecurities w/ using PPTP and getting them all > to buy into the "ovpn methodologies" and I just want to inform them > acordingly if there is a known security issue w/ ovpn connectivity. I > gather from my (all be it) quick scan of documentation associated to this > issue that it is more related to VIA architectures and not Intel or AMD, but > that is just my take on it and I welcome some clarity on this if someone > cares to. Does this issue affect Soekris boards running the Geode/NSC chips > or if they payload the cryptology onto the Hi/fn 7951 or Hi/fn 7955 > crypto/security accelerator. I couldn't find anything on the Soekris board, > but then again I welcome some clarity on this from anyone. Also it seems > that it isn't necessarily a "security" issue but a "performance" issue ??? > > EXCERPT: it will never hurt correctness to issue padlock_reload_key(), > only performance. For small packets and large library overhead, > you may not notice the performance hit. The only time there will > be a performance loss is when padlock_reload_key() is issued and > the next XCRYPT instruction to execute could have re-used the > currently loaded key. The pushfl; popfl; have no additional > performance penalty when they are issued - only when the next > XCRYPT instruction is issued, and then only if no task switch, > interrupt, etc, had occurred in the interval. > > > If the issue described is present in pfSense, then when will it get assigned > to a dev member for addressing (as I see it is still status > unassigned)? > > I personally find ovpn more robust and stable than the PPTP method for > RWarrior use and use it exclusively to support clients and connect to my > shop when traveling, so I just wanted to get some feedback from the > community on the status/affect of this issue within pfSense. > > Thanks one and all again for a great product!
pfsense does not load or have padlock compiled into the kernel. Without the kernel support padlock will not even attempt to load and work. Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
