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!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
