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]
