On Mon, Aug 19, 2002 at 10:43:00AM +0200, Richard Levitte - VMS Whacker wrote: > [NOTE: whatever I write below is *my* opinion. Period] > > In message <[EMAIL PROTECTED]> on Sun, 18 Aug 2002 21:32:43 -0400, >Tom Zerucha <[EMAIL PROTECTED]> said: > > tz> I don't know what the historic reasons for doing things a particular > tz> way, but I would suggest the following (in order of importance): > tz> > tz> 1. Install the certs by default, > > I'm amazed by this statement. Are you seriously willing to give us > that kind of trust, rather than installing whatever root certs you > need yourself? I'm personally not at all sure I want to be given that > kind of trust; I'm a developper, not a trusted certificate store > care-taker (at least in the OpenSSL arena).
The alternative seems to be to let everyone IGNORE CERTIFICATES ENTIRELY. The following SIX applications use OpenSSL and do so in such a way that there is NO security by default: Lynx, Links, Curl, w3m, OmniWeb (commercial MacOSX!), and Wget. Of these, one OpenSource program has a secure mode which requires someone else install the certs. I'll leave it to anyone here to guess which/how to create a truly secure connection. But let me ask an even more stupid question if you don't trust the certs contained in the OpenSSL distribution: Why do you not think there are dozens of bugs, backdoors, intentional hacks, etc? Why shouldn't there be? If no one is checking the code for the certs anyway, and everyone (except maybe Opera - on the Zaurus they got it wrong, but other platforms are right - and Mozilla/Netscape) is ignoring, how do you know the CODE even works even if the certificates are correct? If you can't trust the certs, which you can compare with the cache from Mozilla or another source USING THE COMPILED BINARY TOOLS, why should you trust the source code, much less the binaries? > Unfortunately, we've all been fooled into thinking that our software > distributors should be points of distribution for trusted root > certificates (meaning we implicitely trust Netscape Navigator/ > Communicator, IE and whatnot to be truthful, even though there's no > way in the world the distributors can guarantee that), and most of us > are too lazy to deal with all of that properly. Not quite. When there is a bug, as has just happened with IE, it generally gets publicized and/or noticed and patches are released. Right now, with the IE hole, the third-sigma browsers that normally wouldn't be worth exploiting will get caught up anytime IE is exploited. Get ready for the headline: "OPENSSL BASED BROWSERS LESS SECURE THAN MICROSOFT'S INTERNET EXPLORER". People will be too lazy to read further and Opensource and OpenSSL will get a black eye. > Ultimately, it is YOUR responsability, as a user, to assure the > security of your installation, be it by doing it yourself or by > hiring someone to do it for us. The ultimate responsibility is the user's, but right now I have found at least 7 browsers that are COMPLETELY INSECURE "out of the box". If they said so (by interrupting the user or refusing to work until some override was used), that their use of SSL was only for convienience and not secure, I might be persuaded. There are some cars that have old junk stuffed where the airbag should be. But the airbag light doesn't go on and it looks secure - until you have an accident. If I know there isn't really an airbag there I will drive more carefully until I get it replaced. If you buy a used car, how do YOU, the USER know the airbag is real and not merely some junk stuffing the void?. Someone says it is real. You have to go on the word of the mechanic or dealer. We don't say it was your responsibility because the airbag wasn't real - it is a case of fraud most places (and most people wouldn't buy a car or demand a huge discount if they knew they didn't have a real airbag). Pretend locks that can be opened with any screwdriver would be much cheaper than real ones that require a matching key. Maybe I would use such to discourage burglars, but I would be making an informed choice. Where on the OpenSSL web site does it say that in normal usage that it is completely insecure as used in MOST applications? OpenSSL is sort of a trademark. Those implementing OpenSSL are saying they are using it for the "SECURE socket layer", or for "secure" connections. How is the user supposed to know it is not secure? I can say if they can reach https://www.amazone.com that they should stop using the software immediately. But how do I get that message out? And if it connects, it it a "bug" or a "feature"? OpenSSL is probably considered a "bolt on". The problem is that now it also needs to be filled up and turned on to be secure. It could be made that the effort would be required to drop security. > tz> or if there are nontechnical reasons not to, add something > tz> prominent to the readmes and make process so that the certs > tz> directory will be populated by the users or the distributor > tz> creators. > > I personally have no real problem with writing an extra blurb on > this. Make it prominent enough so that people know that it is insecure by default (if you aren't going to make it default differently). Also indicate what a "correct" implementation needs to do. Right now the ok state doesn't seem to be propogated out of the callback, so it needs to be passed in a global or something, or the CTX cert error state must be checked. In addition, the DNS value of the host must be compared with that in the certificate. After doing several patches for some of the above browsers I have some sample code which is simple but implements the specifications correctly. There are simpler versions if you don't need things like wildcards or expressions in certs. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
