On Wed, May 07, 2008 at 10:27:48AM +1000, James A. Donald wrote:
Dynamic strings tempt people to forget about enforcing
length limits and forget about correctly handling the
case when the length limits are exceeded.
This too is dealt with. Message sizes are bounded, recipient counts
are
James A. Donald [EMAIL PROTECTED] writes:
In any program subject to attack, all strings should have known, documented,
and enforced maximum length, a length large enough for all likely legitimate
uses, and no larger.
Precisely. An example of where dynamic strings can lead you is what happens
to
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which they're able, and supply products
which will
On Sun, 04 May 2008 11:22:51 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
I am left with the strong suspicion that SSL VPNs are easier to
On Sat, 03 May 2008 19:50:01 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
Almost exclusively the use for such things is nailing up a tunnel to
bring someone inside a private network. For that, there is no need for
per user auth -- the general assumption is that the remote box is a
single
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
In particular, with TLS the session key can be negotiated between
two user contexts; with IPsec/IKE, it's negotiated between a user
and a system. (Yes, I'm oversimplifying here.)
Is there any reason (in principle) that
In article [EMAIL PROTECTED] you write:
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
Experiment part two: implement remote login (or remote IMAP, or remote
Web with per-user privileges, etc.) under similar conditions. Recall
that being able to do this was a goal of the IPsec working group.
I think that part
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:
- With the upcoming EECDH support, users don't choose curves
directly, they again choose a security grade, and the correspnding
curves are configurable via parameters they are not expected to
ever look at or modify.
The same is true in the source code, unsafe
practices are avoided globally, (e.g. both strcpy()
and strncpy() are absent together with fixed size
automatic buffers) rather than used with care
locally. I won't bore you with all the
implementation safety habits, but there are many.
Steven M. Bellovin wrote:
IPsec operates at layer 3, where there are (generally)
no user contexts. This makes it difficult to bind
IPsec credentials to a user, which means that it
inherently can't be as simple to configure as ssh.
Put another way, when you tell an sshd whom you wish
to
Ian G wrote: (on Kerckhoffs's rules)
=
6. Finally, it is necessary, given the circumstances that command its
application, that the system be easy to use, requiring neither mental
strain nor the knowledge of a long series of rules to observe.
=
...
PS:
Thor Lancelot Simon wrote:
And, in fact, most VPN software of any type fails this test. My concern
is that an excessive focus on how hard is it to set this thing up? can
seriously obscure the important second half of the question and if you
set it up in the easiest possible way, is it safe?
Steven M. Bellovin wrote:
On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
I am left with the strong suspicion that SSL VPNs are easier to
configure and use because a large percentage of their user
population simply is not
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote:
There's a technical/philosophical issue lurking here. We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.
IPsec operates at layer 3, where there are
Jacob Appelbaum [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Until then, OpenVPN let me get started in about five minutes, and the
fact that it is less than completely secure doesn't matter much to me
as I'm running SSH under it anyway.
[...]
I'm always curious to hear what designers of
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
There's a technical/philosophical issue lurking here. We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have
Perry E. Metzger wrote:
It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when
Thor Lancelot Simon [EMAIL PROTECTED] writes:
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
do, and yet is is fairly easy to configure.
And yet there's no underlying technical reason why it is any
Thor Lancelot Simon [EMAIL PROTECTED] writes:
The upshot is that, indeed, at least as shown here, this particular
configuration frontend to OpenVPN is very easy to configure -- if you are
willing to settle for much less security than OpenVPN was designed to
provide,
I think you mean:
]... if
On Saturday 03 May 2008 14:00, Perry E. Metzger wrote:
Right now, to use SSH to remotely connect to a machine using public
keys, all I have to do is type ssh-keygen and copy the locally
generated public key to a remote machine's authorized keys file.
When there is an IPSEC system that is
On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
I am left with the strong suspicion that SSL VPNs are easier to
configure and use because a large percentage of their user
population simply is not very sensitive to how
Thor Lancelot Simon wrote:
It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.
I cannot help repeatedly noting that -- I believe more so than with actual
IPsec
It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.
I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or
24 matches
Mail list logo
