RE: Open Source (was Simple SSL/TLS - Some Questions)
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)
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)
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)
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
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)
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]
