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