Re: Open Source (was Simple SSL/TLS - Some Questions)
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. There seems to be a fair amount of confusion over what a "SSL VPN" really is - there are several examples of such that are true VPN clients - but the big commercial push seems to be the ASP model - converting *everything* to be web-delivered, and calling the resulting HTTPS site "Thin Client SSL VPN" but in fact they mean "Web browser accessable website with some normally non-web apps on it" - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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)
David Honig wrote: > 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. > Easy for them because they already have a browser. Has anybody tried to revert the political decision not to support password-based authentication with IPsec? [Moderator's note: there was no such political decision to my knowledge. In fact, there was a requirement for manual keying from very early on in the protocol's life. --Perry] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Open Source (was Simple SSL/TLS - Some Questions)
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. Easy for them because they already have a browser. (And some browsers, I recently found out, will accept a self-cert for life, as well as remember your passwords. Can you guess which company made that convenience-vs-security tradeoff?) For IPsec, you have to walk each of them through installing the stack, etc. Not fun, esp on multiple platforms. 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. Things *should* get easier for IPsec when its part of the "default" client system, whether *nix or otherwise. Then everything reverts back to simple :-) key management. He say "I know you, you know me" He got x509 he got intrusion detection He got secure DNS he got spam filter He say "One and one and one is three" Got to be spoofed 'cause he's so hard to see >From Link Together J0hn L3nn0n - 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)
At 5:56 AM -0700 10/8/03, Peter Gutmann wrote: >... 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" :-). Given that the application I had which needed IPSec for encryption was Voice over IP, I'd settle for a secure, point-to-point voice system which works when both ends have NAT with appropriately configured firewalls. Multi-point voice would be icing on the cake. Cheers - Bill - Bill Frantz| "There's nothing so clear as a | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet." -- Dean Tribble | Los Gatos, CA 95032 - 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)
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)
On Thursday, Oct 9, 2003, at 04:31 America/Chicago, Peter Clay wrote: If you want a VPN that road warriors can use, you have to do it with IP-over-TCP. [...] 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. And people will mostly want to run TCP over their VPN. See "Why TCP Over TCP Is A Bad Idea" by Olaf Titz at http://sites.inka.de/sites/bigred/devel/tcp-tcp.html - 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 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)
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, 9 Oct 2003, Peter Gutmann wrote: > IP-over-TCP has some potential performance problems, see Yeah. I hope they won't be too serious. My understanding is that links with few tunnelled connections and low packet loss work OK. > >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 :-). That's just TCP tunnelling, or are there SSH implementations with virtual network interfaces that I don't know about? 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)
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)
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)
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)
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)
| Maybe the solution should be this: You can distribute the binary without | any source code whatsoever, and use this toolkit, unrestricted, in | whatever manner you choose, provided that EITHER you distribute the | source code for the whole product in a form which allows the user to | reconstruct a working executable from the source code, OR you include a | message which says something like "Warning - this product is closed | source. If you rely on its crypto features, you do so at your own risk". No commercial software is ever going to use your software based on those requirements. Oh, sure, the software vendors all write language into their contracts that try to dump all the risk on the buyer - and the current attempts at a class action suit against Microsoft may determine the degree to which the courts let them get away with it. But no one is going to let you impose *your* language on the way they talk to their customers - unless you make your requirement so mealy-mouthed that it's pointless, or you allow them to hide the language so deep that no one ever sees it. At some point, you need to decide whether you are doing this in service to some kind of idealism about perfect cryptography for the masses, or whether you want to improve the state of the world by making it easier for honest vendors to easily provided good crypto. I'll let my bias show: If the vendor of your software wishes to attack you, there's not a hell of a lot you can do about it. It's just too hard to hide things, if you set your mind to it. Even accidental bugs take huge effort to find - whether you believe that "all bugs are shallow to sufficiently many eyes" or not, there's no bug-free open-source software out there any more than there's bug-free closed-source (...which may simply mean that there aren't sufficiently many eyes - but there likely never will be.) *Deliberate* bugs in a system of significant size? I can't even imagine the effort necessary to gain assurance that there aren't any, given the current state of the art. (Sure, in an eventual world with multiple independent proved-secure compilers and libraries for safe languages, verifiers, proof-carrying code or some such technique ... maybe. But the necessary infrastructure is currently way beyond the state of the art for all but very specialized, limited domains.) -- Jerry - 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]
Re: Open Source (was Simple SSL/TLS - Some Questions)
Jill Ramonsky wrote: > Example. You're a company. You build hardware devices which need to talk > to each other securely. (Say, ATMs for example). Obviously it wouldn't > make sense for that company to have to supply its ATM-using-customers > with the source code of the ATMs. Who's the customer, the one that buys and deploys the ATMs, or the actual customer who interacts with it? I can only recommend to demand source code before purchase/deployment, especially for embedded devices which are supposed to communicate securely over an untrusted network. Custom crypto protocols appear to be quite common in this area. Even if you lack the necessary time and experience to detect subtle flaws in the implementation, it's likely that you'll discover a few surprises. Did you know that proprietary Blowfish libraries exist which are extremely easy to use? They even provide a default key which is used unless another key is imported explicitly. This neatly solves all key management problems. (The key, by the way, is the third one you would check if you had to guess it.) > This is an important question (for me, at least) since it affects the > licensing of the yet-to-be-written TLS++ project. There are few licenses today which require distribution of source code to end users if they don't receive binaries. One prominent exception is the Afferro (sp?) GPL. > Maybe the solution should be this: You can distribute the binary without > any source code whatsoever, and use this toolkit, unrestricted, in > whatever manner you choose, provided that EITHER you distribute the > source code for the whole product in a form which allows the user to > reconstruct a working executable from the source code, OR you include a > message which says something like "Warning - this product is closed > source. If you rely on its crypto features, you do so at your own risk". If you want to see widespread adoption of your Better TLS Library, you should avoid such licensing experiments. Use a BSD or MIT-style license instead. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
