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]


Indian Defence Research Facility Burgled

2003-10-09 Thread R. A. Hettinga
http://www.hindustantimes.com/onlineCDA/PFVersion.jsp?article=http://10.81.141.122/news/181_410767,0008.htm


HindustanTimes.com

Defence research facility burgled 

Soni Sangwan, Vishal Thapar and Vibha Sharma 
New Delhi,?October 9 

Nineteen computers belonging to top-secret establishments of the Defence Research and 
Development Organisation (DRDO) at Metcalfe House near ISBT have been stolen. 

What's spooked the defence brass is that the computers ? which were installed in the 
offices of the Scientific Analyses Group (SAG) and the Institute for System Studies 
and Analyses (ISSA) ? contained strategic data vital to India?s security. 

The SAG is responsible for cryptography. In other words, all codes and cyphers to 
ensure communication security for the defence forces have an SAG stamp. The ISSA, on 
the other hand, analyses competing weapons systems for induction into the armed 
forces. 

The matter was reported to the local police on Monday by Wing Commander Ratan Kumar 
Srivastava. 

For the moment, the defence establishment has no answers ? only red faces. We don't 
even know the extent of loss of strategic data, said sources at the Ministry of 
Defence. 

What?s worrying the defence establishment is that the DRDO has provided the encryption 
back-up for protecting strategic communications in the context of India's nuclear 
arsenal 

Officially, the DRDO has put up a brave face. There is no sensitive information on 
current projects on the hard discs stolen, a senior DRDO official insisted. 

Spooked 

Target: Scientific Analyses Grp 
Lost: Encryption data on codes used by strategic forces 
Application: Securing communication channels of nuclear command chain 
Target: Institute for Systems Studies and Analyses 
Lost: Assessment of competing weapons systems of rival manufacturers and weapon 
effectiveness studies 
Application: Such scientific inputs are critical in defence buys and analysis of 
military hardware 
-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
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]