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]
Simple SSL/TLS - Some Questions
Having been greatly encouraged by people on this list to go ahead with a new SSL implementation, it looks like I am going to go for it, but I'd kinda like to not make any enemies in the process so I'll try to keep this list up to date with progress and decisions and stuff ... and I will ask a lot of questions. It's worth summing up the design goals here, so nobody gets confused. Trouble is, I haven't figured out what they should all be. The main point of confusion/contention right now seem to be (1) should it be in C or C++?, (2) should it support SSL or TLS or both? There are plenty of things I am really sure about, however. The two main design goals people seem to want are (1) lightweight, and (2) easy to use. (Plus the obvious goals of (3) it actually /will/ implement SSL/TLS and not something else, and (4) it shouldn't be full of bugs. I figure those go without saying). Regarding the choice of language, I think I would want this library (or toolkit, or whatever) to be somehow different from OpenSSL - otherwise what's the point? I mean ... this may be a dumb question, but ... if people want C, can they not use the existing OpenSSL? Or is it simply that OpenSSL is too complicated to use, so a simpler than OpenSSL C version is required. What I mean is, I don't want to duplicate effort. That seems dumb. C++ has many advantages, which include SECURITY advantages. Proper use of constructors, destructors, exceptions, std::strings, std::vectors, smart pointers, and so on can eliminate memory leaks, dangling pointers, buffer overruns, and just about everything else than can bring a good toolkit down. I already have a very nice, working, C++ secure big-integer library [here's one I wrote earlier]. By secure in this context, I mean that all big-integers get zeroed on deletion, so no crypto keys are ever left lying around in memory. Sure, these sort of things are all also possible in C, but it's so much more work to be /sure/ that every error condition is dealt with. Is embedded C++ non-existant then? I'm pretty sure it's possible to compile C++ to C (instead of to assembler) so a C++ to C wrapper can't be that difficult. (By contrast, a C to C++ wrapper would be easier, but the toolkit would have more bugs!) My inclination is still to go with C++, and figure out a way of turning it into C later if necessary ... but if majority opinion says otherwise I'll reconsider. Now - SSL or TLS - this confuses me. From what I've read in Eric's book, SSL version 3.0 or below is called SSL, wheras SSL version 3.1 or above is called TLS. Have I misunderstood that? In any case, I note the bit in Eric's book (p73 in my edition) where it says In general, it is expected that an implementation speaks all lesser versions ... even if lesser versions become known to be insecure. I'm not sure I like this - and in any case, it goes against the design goal of lightweight. If you want to implement only TLS (for example, in a closed private network where all parties are known to be using the same version of the same protocol), why should you have to lug around SSL as well? I suppose I /want/ the solution to be allow the toolkit to generate either SSL-only, or TLS-only, or SSL+TLS ... but what I'm not sure about is, is the TLS-only option forbidden by the standard? And now some questions about SSL/TLS itself THE HANDSHAKE PHASE The assumption in Eric's book, roughly translated into Alice and Bob scenarios, goes something like this: Bob (client) says hello to Alice (server). Alice sends Bob her certificate (which is basically a copy of her public key, signed by a third party, Carol). Bob validates Alice's key (which is only possible if he already has a copy of Carol's public key), and then uses Bob's (now validated) public key to start sending encrypted messages. (There's more, but that's the important part). Now, this scenario is all very well for banks and big businesses, but I guess I want to do SSL for the rest of us. You see, the above scenario contains a couple of assumptions. It assumes (1) that Bob does not already have Alice's key - otherwise why would she need to send it? It further assumes (2) that Bob /does/ have Carol's key, /and that he trusts Carol/. Okay, fine, but what if these assumptions aren't met? I mean, let's assume that Bob already has Alice's key. (Let's say for sake of argument that she gave it to him personally). Now this means we can save on bandwidth by not having to transmit Alice's cert ... but already there are two problems: (1) would it be a violation of the protocol to omit the cert?, and (2) without the cert, we would need some /other/ kind of message with which to replace it - one which says, simply, Hi, this is Alice, use the copy of my key which you already have. So already I have questions - how free am I to allow variations in the handshake? THE CIPHER SUITE The list on page 74 of Eric's book looks a little limiting to me -
RE: Monoculture
Thanks everyone for the SSL encouragement. I'm going to have a quick re-read of Eric's book over the weekend and then start thinking about what sort of easy to use implementation I could do. I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on that? Also - anyone thinking of using something like this - could you post (in another thread maybe) suggestions as to what kind of simple interface you actually want? As in, what you want it to do? All suggestions gratefully considered, but in the light of comments in this list, I will /not/ turn it into bloatware just to satisfy all demands. (OpenSSL can do that). Finally - I'll need some help setting up a sourceforge thing as I've never set up an open source project before and don't really know how to go about that. Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ... something else?) Re Don's comments below: This seems to me to a /serious/ flaw in the design of MSIE. What if Alice doesn't /have/ a CA because she can't afford their fees? (or she doesn't trust them, or for any other reason you might care to think of). In fact, if I've understood this correctly, if Alice uses MSIE, she can't even tell her browser to trust her own website, despite being in possession of not only her own public key, but her own secret key as well! What is it with MSIE that it would prefer to trust someone other than Alice about the authenticity of Alice's site !!!??? Okay guys - _this is a serious question_. Alice has a web site. Alice has a web browser which unfortunately happens to be MSIE. Alice wishes to view Alice's web site using Alice's browser (which is not on the same machine as the server). Alice does not wish to trust ANYONE else, but she does trust herself absolutely. How does she get the browser to display the padlock? I wouldn't be at all surprised if the answer turns out to be It can't be done. (That may not be a problem if other browsers don't have this design flaw, of course, since Alice can tell all of her friends don't use Microsoft). Jill -Original Message- From: Don Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 1:26 PM To: Jill Ramonsky Cc: [EMAIL PROTECTED] Subject: RE: Monoculture Is it possible for Bob to instruct his browser to (b) to trust Alice's certificate (which she handed to him personally)? (And if so, how?) how it's done depends on the browser: in MSIE 5: Edit Preferences.., Web Browser Security Certificate Authorities (there seems to be no way to tell MSIE 5 to trust Alice's server cert for SSL connections, except to tell MSIE 5 to trust Alice's CA.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Monoculture
I could do an implementation of SSL. Speaking as a programmer with an interest in crypto, I'm fairly sure I could produce a cleanly implemented and simple-to-use version. I confess I didn't realise there was a need. You see, it's not that it doesn't seem to excite [me] - it's just that, well, OpenSSL already exists, and creating another tool (or library or whatever) to do exactly the same thing seems a bit of a waste of time, like re-inventing the wheel. If you can provide some reasonably reassurance that it's not a waste of time, I'll make a start. But I would like to ask you to clarify something about SSL which has been bugging me. Allow me to present a scenario. Suppose: (1) Alice runs a web server. (2) Bob has a web client. (3) Alice and Bob know each other personally, and see each other every day. (4) Eve is the bad guy. She runs a Certificate Authority, which is trusted by Bob's browser, but not by Bob. Is it possible for Bob to instruct his browser to (a) refuse to trust anything signed by Eve, and (b) to trust Alice's certificate (which she handed to him personally)? (And if so, how?) I am very much hoping that you can answer both (a) and (b) with a yes, in which case I will /definitely/ get on with recoding SSL. Jill -Original Message- From: Perry E. Metzger [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Monoculture We could use more implementations of ssl and of ssh, no question. However, suggesting to people that they produce more cleanly implemented and simpler to use versions of existing algorithms and protocols doesn't seem to excite people, although it would be of tremendous utility. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Looking for an N -out-of-M split algorithm
Hi, I remember reading (many years ago) a description on some web page somewhere of an algorithm by which an arbitrary file F could be split into M pieces, such that: (1) given any N pieces, F can be reconstructed precisely, and (2) given fewer than N pieces, it is impossible to determine even a single bit of information about F. Unfortunately, that was many years ago, and -- search as I might -- I haven't been able to find it on web now. Does anyone have any idea where I might learn about this algorithm - or indeed any algorithm which does the job. Jill [Moderator's note: look for Shamir Sharing -- the trick is just turning the secret into a polynomial of degree N so that with enough points you determine the polynomial uniquely and with too few you can't determine it. I'm pretty sure that Schneier and all of the other standard references explain this trick. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Encrypted Virtual Drives
Hi, Could anyone offer any thoughts on what is the "best" encrypted virtual disk drive, which can run on (at least) Windows XP Pro. I used to use the free version of PGPdisk (which you get with PGP version 6.0.2i), but that won't work with Windows XP. I also used to use ScramDisk, but that also won't work with Windows XP. I have been using new version of PGPdisk (PGP version 8.0), but there are a number of problems with that: being (1) the license ($50) seems to be enforced per-computer, not per-user, so if you upgrade from one computer to another you either have to pay again or plead your case with the PGP Corporation's support centre (which is only open during office hours Monday to Friday, so don't try this during the weekend), and (2) their web site had some problem last weekend such that it wouldn't actually let me buy a new license even though I was prepared to pay for it, and(3) the format of the container volume is totally incompatible with that of PGP 6.0.2i. These problems combined mean that if your computer totally dies, to get your data back (assuming the existence of a backup) you are reliant on a single company to grant you a new license to get the software working, and getting that licence is not necessarilyeasy. I have also tried the new version of DriveCrypt (thesuccessor toScramDisk) ... but I worry about this because the company who make this (Securstar) no longer provide source code. I'd kind of like to write my own, but doing the crypto is justthe easy part - the hard part is actually writinga virtual drive - I can't find any tutorials on that part. So I put it to this list, what do folk here reccommend? Jill
Sessions
This has got nothing whatsoever to do with session fixation. It _has_ however, got something to do with security. In particular, with authentication. [Moderator's note: Actually, it seems to have everything to do with session fixation. --Perry] I may be ignorant about a few things but I'm learning fast, and I still think the following question is worth my asking (and someone answering) because I'm actually thinking of using this idea on a real web site. At the very least, it seems to me that it ought to be more secure than NOT tracking the IP. I've come up with a (very simple) defence against session hijacking and so on. It's probably flawed (I admit I'm not an expert on these things), so if someone could please tell me why it won't work, I'd be very grateful. When the user logs in, the server stores the client's IP address in a session variable (so it's stored at the server end - the client just gets a session id). Authentication of subesequent pages is assumed only if the client's IP address matches the IP address stored in the session variable corresponding to the client's session. Is this secure? If not, why not? Jill [Moderator's Note: you might want to read the original paper again. It I didn't receive the rest of this moderator's note so I don't know what it was going to say. My apologies for not having changed the subject line from RE: Session Fixation Vulnerability in Web Based Apps, and for not making it clear that this is a different and unrelated thread. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
