On Fri November 28 2008, Peter Sysko wrote: > Hello. > Two things that occur to me -
*) Doesn't Diffie-Hillman already do that? Without the file exchange. *) Have you considered this plan from the viewpoint of a zero-knowledge proof? Mike > I've read over the majority of the information about what the OpenSSL > project is for and is striving to become, > and, being not a hardcore coder, I must say I a little overwhelmed with > some technical details that I won't be addressing > right now, this post is just to introduce an idea, if it hasn't been > presented. Maybe a discussion about this idea could help > me and other website owners come to a solution that makes a new type of > Dynamic 2-Way SSL "protocol" > > Firstly, I'd like to address the need for and the merits of such a > protocol, and what it would consist of. Then perhaps a discussion could > be informed, if there is a quorum of users who would agree that its a > good idea to come about possible implementation methods. Finally, how to > make these implementation methods accepted as a solution for todays and > tomorrows secure network administration. And also, I dont want to be > wasting anyone's time including my own, so if anyone is aware of > "out-of-the-box" solutions that already exist, I'll be all ears. > > So, heres the problem (as i see the problem, and any thoughts on why > this might not be a problem afterall would be appreciated):: > > The standard practice is to generate static certificate pairs, usually > valid for about a year. The authority of the certificates' authority > ranges from self-signed to highly visible EV signatures (that cost a lot > of money), based on who you have to validate the "working order" of your > cryptographic setup. As a website owner, you can feel comfortable that > you are creating a secure "tunnel" from the client to the server. The > problems of sending data to an unidentified peer or client (who may be > using a proxy), is that THEY don't have a public key with their own > private key with a certificate authority vouching for their own node in > the network. > > (for the sake of the conversation, assume that we are the server admin > team for a huge company with millions of peers using their network and > have a virtually unlimited needs based budget to secure the network, adn > that these millions of peers would download a program to make their > network experience secure too) > > So, here is my crazy idea: > > So we have our EV cert verified and validated on the server. We know > that everyone using https to access our domain on port 443 is sending > data in a very secure manner. Then, a client wishes to access sensitive > data from our server, we go through the following process, in an > mostly-automated manner: > > • client requests a secure connection to the server (hello server, im on > port 443 of your web application) > • server responds: "please authenticate yourself, here is an open safe. > put your login credentials in this safe and shut the door. Only I can > open the safe." > • client thus provides login credentials - encrypted in only a way the > server can decrypt. > • server opens the safe, validates that the user exists. I have new > important messages for you from the network, they are secure. do you > have a public key? if so, send me the public key to your safe. > • client responds "no, i'm relatively new to the network" > • sever says "thats ok, let me put a tool on your computer that will > generate a combination that only your computer will know, so that > everyone can send you sensitive data. do you accept?" > • client responds "yes" > • sever sends a package file, a toolkit that using the RSA/SSL Library > to generate a pair and a certificate signing request, which goes to us > to sign it. "first let me send you something to test the certificate" > server sends a randomly generated string encrypted with the public key > that the client just provided. "can you read this? what does it say?" > • client decrypts with his own new private key using the toolkit, still > running. "it says _______" > • server "great! thats exactly what i sent to you. We have stored your > public key in our keystore, and matched it to your account. now keep > your application running when you use our network, in order to ensure > you receive data from us in the same secure manner that we send it to you" > • client then proceeds to their account page where they can start using > features. all data sent to the client during the session will be sent > encrypted via the certificate > > --- > > Ok, so thats basically how I see 2-way SSL working. I personified the > code and communication between client and server -- of course thats what > the application needs to do, so that all the user has to do is 1) Login > 2) download a package 3) install and run the package and 4) keep it > running along with the web portal the are accessing on port 443 > > This "toolkit" package could be a Firefox or Opera plugin, to start. or > a standalone app that runs concurrently with their favorite browser, or > both. the application would have to be able to communicate between the > browser, sort of like the TOR module "Vidalia" does. the app/plugin set > could be toggled off and on for speed related issues. > > This sounds like a large project to me. Could be an awesome evolution of > secure networks of the future does anyone else see a merit in it? Any > solutions like this exist for 2-way open source SSL? Any feedback is > welcomed. > > Thanks for reading. > > Peter Sysko, CEO > U4EA Networks, Inc. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
