Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-12 Thread Perry E. Metzger

[Moderator's note: Forwarded anonymously at the sender's request, so
if you reply to this, please cut my name out of it, it isn't my
message --Perry]


--
Perry, please forward anonymously.

On Friday, Oct 10, 2003, at 22:48 America/Chicago, David Honig wrote:
 At 12:08 AM 10/10/03 +0800, Ng Pheng Siong wrote:
 I believe SSL VPNs are easier than IPsec to deploy

 For the former, you give a password or two --maybe
 reuse a POP3 that your users already have-- and all your
 users get in fairly securely, and you can verify them.

Ugh.

Taking a page from the IETF playbook, I ran dsniff as a background task 
at a recent business meeting.  I captured hundreds of assorted 
passwords.  About half were POP passwords.

--

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-11 Thread Ben Laurie
Peter Clay wrote:

 On Thu, 9 Oct 2003, Peter Gutmann wrote:
 
 
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
to join the zero or so already out there.  The difficulty in setting up any
IPsec tunnel is what's been motivating the creation of (often insecure) non-
IPsec VPN software, so what'd be a lot more helpful than (no offense, but) yet
another SSL implementation is some means of making IPsec easier to use
(although that may not be possible... OK, let's say less painful to use :-).
 
 
 Having spent much of the past few weeks trying to sort out a workable VPN
 solution, I think this is a good but doomed idea. http://vpn.ebootis.de/
 has the best free windows IPsec configuration tool I've found, but that
 doesn't help. Why? Because IPsec traffic is not TCP traffic and therefore
 gets dropped by random networks.
 
 If you want a VPN that road warriors can use, you have to do it with
 IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even
 Microsoft PPTP.

PPTP uses GRE, so aggressive firewalls are likely to kill it, however,
it isn't hard to stop them :-)

However, I've seen UDP surive some fairly aggressive firewalling, and
that's what you really want for a VPN.

 If someone out there wants to write VPN software that becomes widely used,
 then they should make a free IP-over-TCP solution that works on Windows
 and Linux which uses password authentication.

Doesn't OpenVPN have that option?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Peter Clay
On Thu, 9 Oct 2003, Peter Gutmann wrote:

 I would add to this the observation that rather than writing yet another SSL
 library to join the eight hundred or so already out there, it might be more
 useful to create a user-friendly management interface to IPsec implementations
 to join the zero or so already out there.  The difficulty in setting up any
 IPsec tunnel is what's been motivating the creation of (often insecure) non-
 IPsec VPN software, so what'd be a lot more helpful than (no offense, but) yet
 another SSL implementation is some means of making IPsec easier to use
 (although that may not be possible... OK, let's say less painful to use :-).

Having spent much of the past few weeks trying to sort out a workable VPN
solution, I think this is a good but doomed idea. http://vpn.ebootis.de/
has the best free windows IPsec configuration tool I've found, but that
doesn't help. Why? Because IPsec traffic is not TCP traffic and therefore
gets dropped by random networks.

If you want a VPN that road warriors can use, you have to do it with
IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even
Microsoft PPTP.

If someone out there wants to write VPN software that becomes widely used,
then they should make a free IP-over-TCP solution that works on Windows
and Linux which uses password authentication.

Pete
-- 
Peter Clay | Campaign for   _  _| .__
   | Digital   /  / | |
   | Rights!   \_ \_| |
   | http://www.ukcdr.org

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Peter Gutmann
Peter Clay [EMAIL PROTECTED] writes:

If you want a VPN that road warriors can use, you have to do it with IP-over-
TCP. Nothing else survives NAT and agressive firewalling, not even Microsoft
PPTP.

IP-over-TCP has some potential performance problems, see
http://sites.inka.de/bigred/devel/tcp-tcp.html, although having used SSH and
SSL tunnels quite a lot, I wonder how serious this really is - the author of
the above analysis mentions performance problems on a link with a high level
of packet loss, but on a typical link I haven't found any real problems.  If
you specifically want a pure TCP tunnel though, there's a pile of solutions
available, of which the easiest to set up is SSH (point it at the target,
indicate that you want port forwarding, and you're done).

If someone out there wants to write VPN software that becomes widely used,
then they should make a free IP-over-TCP solution that works on Windows and
Linux which uses password authentication.

Some guy called Ylonen already did this in 1995 :-).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Perry E. Metzger

Peter Clay [EMAIL PROTECTED] writes:
 Having spent much of the past few weeks trying to sort out a workable VPN
 solution, I think this is a good but doomed idea. http://vpn.ebootis.de/
 has the best free windows IPsec configuration tool I've found, but that
 doesn't help. Why? Because IPsec traffic is not TCP traffic and therefore
 gets dropped by random networks.
 
 If you want a VPN that road warriors can use, you have to do it with
 IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even
 Microsoft PPTP.

Unfortunately, IP over TCP has very bad properties. TCP stacks figure
out what the maximum bandwidth they can send is by increasing the
transmission rate until they get drops, and then backing off. However,
the underlying TCP carrying the IP packets is a reliable,
retransmitting service, so there will never be any drops seen by the
overlayed TCP sessions. You end up with really ugly problems, in
short.

Port-forwarded TCP sessions, a la ssh, work a lot better.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Guus Sliepen
On Thu, Oct 09, 2003 at 09:42:18AM -0400, Perry E. Metzger wrote:

  If you want a VPN that road warriors can use, you have to do it with
  IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even
  Microsoft PPTP.
 
 Unfortunately, IP over TCP has very bad properties. TCP stacks figure
 out what the maximum bandwidth they can send is by increasing the
 transmission rate until they get drops, and then backing off. However,
 the underlying TCP carrying the IP packets is a reliable,
 retransmitting service, so there will never be any drops seen by the
 overlayed TCP sessions. You end up with really ugly problems, in
 short.
 
 Port-forwarded TCP sessions, a la ssh, work a lot better.

If you run your VPN over TCP, and the VPN daemon therefore knows that
every packet it sends to the other side of the connection will arrive
anyway, you can do proxy-ACK, which essentially means you automatically
do port-forwarding for all TCP sessions on the virtual network
interface.

Still, not only is TCP-over-TCP a problem, anything realtime over TCP
(like VoIP, games, streaming video) suffers from it.

SCTP (RFC 2960) looks like a solution, although I don't know of NATs
that support it, and although some platforms already have some support
for it in their kernels, I don't think it's possible to write a user
space application using SCTP yet.

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen [EMAIL PROTECTED]


signature.asc
Description: Digital signature


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Ng Pheng Siong
On Thu, Oct 09, 2003 at 01:56:47AM +1300, Peter Gutmann wrote:
 I would add to this the observation that rather than writing yet another SSL
 library to join the eight hundred or so already out there, it might be more
 useful to create a user-friendly management interface to IPsec implementations
 to join the zero or so already out there.  The difficulty in setting up any
 IPsec tunnel is what's been motivating the creation of (often insecure) non-
 IPsec VPN software, 

Still coming back to SSL, it seems SSL VPNs are getting bigger: just got a
press release that some big firewall vendor (who has an IPsec appliance
product) has acquired some (big?) SSL VPN appliance vendor.

I believe SSL VPNs are easier than IPsec to deploy and operate for the road
warrior accessing corporate resources. This may eventually restrict IPsec's
utility to site-to-site tunneling (useful when, e.g., one wishes to run
OSPF over the tunnel), which _should_ be far easier to configure without
needing the help of some whizbang AI.


-- 
Ng Pheng Siong [EMAIL PROTECTED] 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Ben Laurie
Jill Ramonsky wrote:
 Too late. I've already started. Besides which, posts on this group
 suggest that there is a demand for such a toolkit.

I think there's demand in the sense that there's demand for free
lunches. People would like the inherent complexity to go away, because
they can see that there's a way simpler API that addresses _their_
problem, but I fear that a good deal of the complexity in TLS is not
removable, so all that will happen is that the API will be unsuitable
for almost everyone else's problem - or it'll still be complex.

There must be a reason that OpenSSL is popular despite its disgusting
API and appalling documentation[1]. I hypothesize its because if you
think about it a while you can get it to do almost anything.

Its also worth considering that most applications of TLS need other
crypto primitives (it seems to me), so merely replacing the TLS part
doesn't actually help most people.

Anyway, that said, there's certainly room for something that does
everything OpenSSL does, only nicely.

Cheers,

Ben.

[1] People have wondered in the past why I maintain OpenSSL if I have
such a low opinion of it - the answer is I do it because somebody has
to. Or to plagiarise someone else's witticism: the only thing that's
worse than OpenSSL is all the alternatives.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-08 Thread Arcane Jill
Okay, okay. I've got the message. I give in.

The toolkit will be distributed with the most generous, most liberal 
license possible. This means that (basically) anyone can do pretty much 
anything with it, including release binaries compiled with it.

I'm happy with this decision. It means that if Alice wishes to trust 
software written or modified by Eve (or Mallory, etc.)., then she is 
perfectly entitled to do so. It is up to Alice to choose her own threat 
model, not me. The bottom line is, everyone has the right to choose whom 
they trust ... even if they're wrong. (After all, I can hardly demand 
that right for myself and then deny it to others, can I?).

Jill (Ramonsky ... sending from new email address)

Oh yeah, one last thing

 -Original Message-
 From: Rich Salz [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 07, 2003 4:19 PM
 To: Jill Ramonsky
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: Open Source (was Simple SSL/TLS - Some Questions)


 I think that rather than spending time on deciding what to call this
 library that is to-be-written, and how to license this library that is
 to-be-written, that time should be spent on, well, writing it. :)
 /r$
Aha - I'm ahead of you there. I've already started. But more than one 
person advised me to not talk about code until at least one third of it 
was finished, in order to avoid real-time discussions about how code 
should be written. If I am silent on the coding progress, rest assured 
it doesn't mean I'm not doing anything.

On the other hand, I /could/ post progress reports if people wanted. I 
have absolutely no idea whether that would be considered appropriate or 
not. I'm open to suggestion.

Jill

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-08 Thread Peter Gutmann
Rich Salz [EMAIL PROTECTED] writes:

I think that rather than spending time on deciding what to call this library
that is to-be-written, and how to license this library that is to-be-written,
that time should be spent on, well, writing it. :)

I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
to join the zero or so already out there.  The difficulty in setting up any
IPsec tunnel is what's been motivating the creation of (often insecure) non-
IPsec VPN software, so what'd be a lot more helpful than (no offense, but) yet
another SSL implementation is some means of making IPsec easier to use
(although that may not be possible... OK, let's say less painful to use :-).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-08 Thread Jill Ramonsky
Too late. I've already started. Besides which, posts on this group 
suggest that there is a demand for such a toolkit.

Also, I have a lot of interest in SSL/TLS, and no interest whatsoever in 
IPsec. I believe I am a competent programmer, but the fact is, if you 
want me to write something in my own spare time, something for which I'm 
not being paid, then I'm afraid I do require the subject to interest and 
inspire me.

But I am at least putting my money where my mouth is. I'm doing 
something, not merely talking about it. It may be months before I have 
anything to show off, but that day will come soon enough. And even 
within the confines of the subject of SSL/TLS I'm sure there will be 
people saying don't do this, do that. Asking me to change /everything/ 
and start again from scratch is unrealistic.

I can only suggest that if you believe there is a need for an IPsec 
library, you might consider picking up a C/C++ compiler and starting to 
code it. Or if that's not your field of expertise, you could ask this 
list for volunteers. But asking someone who's /already/ volunteered for 
something to drop what they volunteered for and do something else 
instead is ... well ... a strategy which is unlikely to succeed, to put 
it politely. I am sorry about that, but I really want to do TLS++ (it 
has a name now, although the name can obviously change). And if it turns 
out that I'm wrong, and those who encouraged me are also wrong, and 
there is no big demand for Simple-to-use SSL/TLS after all, then I 
don't care - because _I_ want to use it, and that, to me, is the most 
important demand of all.

Of course, you could always offer to pay me more than my current 
employer, then I'd write anything you wanted!
Jill (Apologetically)

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 08, 2003 1:57 PM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: RE: Open Source (was Simple SSL/TLS - Some Questions)


 Rich Salz [EMAIL PROTECTED] writes:

 I would add to this the observation that rather than writing
 yet another SSL
 library to join the eight hundred or so already out there, it
 might be more
 useful to create a user-friendly management interface to
 IPsec implementations
 to join the zero or so already out there.  The difficulty in
 setting up any
 IPsec tunnel is what's been motivating the creation of (often
 insecure) non-
 IPsec VPN software, so what'd be a lot more helpful than (no
 offense, but) yet
 another SSL implementation is some means of making IPsec easier to use
 (although that may not be possible... OK, let's say less
 painful to use :-).

 Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-07 Thread Rich Salz
  I took the initial view that closed source and trustable
 crypto are mutually incompatible

Of course this isn't true.  When is the last time you built your
own ATM or credit-card POS terminal?

 Claims such
 as Download this app and you will be secure should definitely need to
 be proven, and if the app is built with TLS++ that would mean
 distributing the source code.

That's not enough.  Are you validating the toolchain?  (See Ken Thompson's
Turing Aware lecture on trusting trust).  Are you going to prevent
users from storing private keys in world-readable files?  Think very
carefully before you make *any* claims about what features your software
will provide, and what is necessary to truly ensure those features.
Are you planning on taking real liability here?   That would be a first
in the software world.

 I don't want to restrict the distribution of TLS++, but I
 also don't want crippled versions of it being used to fool the public.

Do you really think that someone who wants to fool the public will
be deterred by a LICENSE.txt file in an open source distribution?

 If anyone could help me to outline a reasonable possibility?

I think that rather than spending time on deciding what to call this
library that is to-be-written, and how to license this library that is
to-be-written, that time should be spent on, well, writing it. :)
/r$
--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]