On Wednesday 14 February 2007 09:37:07 you wrote: > I do need authentication, probably on both sides. Our problem is that the > Server & Client are both started by the user, and only for 1-connection. > There's a risk that once they start the server, tho, someone else could > "usurp" their connection as their is no validation or security. Also, all > information over the connection is plaintext and ripe for sniffing. The > hope was that by integrating SSL into this connection we could fix someof > these problems, and it sounds like I could. I just wonder how much trouble > it will be dealing with the certificate stuff. > It all depends on how much of the procedural part of PKI you want to implement.
> If I understand correctly, then what I "need" to do is to generate a CA > certificate. Then, all certificates handed out to users will be signed by > this master CA certificate. Then the server will force the client > certificate to be sent (like I'm doing now) and verify that it is signed by > the CA certificate. If it is, then it's all good? > True - but how will you know if the CA certificate hasn't been replaced... you could hardcode the SKI of the certificate into the application, but then what about when the CA Certificate expires? Also, what algorithm are you going to use for the CA Certificate? NIST and NESSIE both recommend that SHA-1 signatures are end-of-lifed in 2010, so you should ensure that your clients can handle SHA-256 if your CA Certificate is going to have a lifetime longer than 3 years from today, and you want to be compliant with best practice in this area. Also, what procedural rules are going to be around the CA? Who is going to write the Certificate Policy for that CA? How will it be maintained? Will it be auditted? How necessary is it for it to be available? Who is going to maintain that availability? Should you protect the CA key in some extra secure hardware? How much does that cost? Has that cost been built into the cost of your application? Just adding certificates/SSL to something is what some refer to as "sprinkle magic crypto juice on it, and it becomes secure"... it may become marginally more difficult to attack, but unless you go through and figure out all of the vectors, risks, and their consequences, you are probably going through a great deal of effort, for not much return. The one thing that I noticed in the below, is that the client isn't verifying the identity of the server. This still leaves you open to a man in the middle attack. Also - in your application, since your users will probably come and go, you should write your own SSL_verify() callback, which will check the CRL, to make sure that the client certificates are still valid. Have you thought about how this CRL will be published? Maintained? Transmitted to the Client? If it gets too big, and/or you are in a low bandwidth environment, are you going to instead use OCSP? How will THAT architecture be configured? What happens if your Data Center or Internet connection goes out, and the CRL is unable to be published, or the OCSP responder is unavailable? What is your application going to do? How are you going to present all of this to the users? That will probably be your biggest challenge. Most people don't know about this stuff, and care less... they just want their apps to work :) There are a huge number of things that you need to think of to make sure that you're not giving yourself a false sense of security. Have fun. Patrick. > Well, the code I'm using is something like this: (Greatly reduced, I > removed all superfluous & error checking code): > > Server Side: > SSL_library_init(); > OpenSSL_add_all_algorithms(); > SSL_load_error_strings(); > method = SSLv3_server_method(); > > // Create new context from method. > ctx = SSL_CTX_new(method); > SSL_CTX_set_options(ctx,SSL_OP_SINGLE_DH_USE); > printf("Loading Public Certificate \"%s\"\n", certFile); > if (SSL_CTX_use_certificate_chain_file(ctx, certFile) <= 0) { > ERR_print_errors_fp(stderr); > return -1; > } > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); > SSL_CTX_set_verify_depth(ctx,2); > SSL_CTX_load_verify_locations(ctx, certFile, NULL); > STACK_OF(X509_NAME) *cert_names; > cert_names = SSL_load_client_CA_file(certFile); > if (cert_names != NULL) { > SSL_CTX_set_client_CA_list(ctx, cert_names); > } > if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) <= 0) { > ERR_print_errors_fp(stderr); > return -1; > } > printf("-> Confirming match..."); > if (!SSL_CTX_check_private_key(ctx)) { > printf(" No match!\n"); > return -1; > } else { > printf(" Good!\n"); > } > // Now create socket in Listen mode.. & wait for connect.. Removed for > brevity.. > client = accept ( ...); > ssl = SSL_new(ctx); > SSL_set_fd(ssl, client); > if (SSL_accept((SSL*)ssl) < 1) { > ERR_print_errors_fp(stderr); > return -1; > } > printf("* Verifying Presented Certificate: "); > if (SSL_get_verify_result((SSL*)ssl) != X509_V_OK) { > printf("Certificate didn't verify.\n"); > return -1; > } else { > printf("Valid!\n"); > } > char buffer[128] = "Hello World from [EMAIL PROTECTED]"; > SSL_write((SSL*)ssl, buffer, strlen(buffer)); > SSL_shutdown((SSL*)ssl); > SSL_free((SSL*)ssl); > close(client); > > Client Side: > SSL_library_init(); > OpenSSL_add_all_algorithms(); > SSL_load_error_strings(); > method = SSLv3_client_method(); > > // Create new context from method. > ctx = SSL_CTX_new(method); > SSL_CTX_set_options(ctx,SSL_OP_SINGLE_DH_USE); > printf("Loading Public Certificate \"%s\"\n", certFile); > if (SSL_CTX_use_certificate_chain_file(ctx, certFile) <= 0) { > ERR_print_errors_fp(stderr); > return -1; > } > printf("Loading Private Key \"%s\"\n", keyFile); > if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) <= 0) { > ERR_print_errors_fp(stderr); > return -1; > } > // Establish connect... > SSL *ssl = SSL_new(ctx); > if (SSL_set_fd(ssl, client) == 0) { > ERR_print_errors_fp(stderr); > return -1; > } > printf("* Negotiating SSL connection...\n"); > > if (SSL_connect((SSL*)ssl) < 1) { > ERR_print_errors_fp(stderr); > return -1; > } > printf("* Connected!\n"); > > char buffer[128]; > memset(buffer, 0, 128); > SSL_read((SSL*)ssl, buffer, 128); > printf("Received: \"%s\"\n", buffer); > SSL_shutdown((SSL*)ssl); > SSL_free((SSL*)ssl); > close(client); > printf("Complete.\n"); > > On 2/14/07, Bernhard Froehlich <[EMAIL PROTECTED]> wrote: > > Randall Hand schrieb: > > > WEll, I understand the SSH way as I use it regularly, but I'm having a > > > hard time finding documentation and examples on the SSL way to do this. > > > Do you have any code examples, or know where I might find some? I > > > managed to figure out how to do DH matching, which gives me encryption > > > but no authentication. I also managed to figure out full certificate > > > work with RSA, but (as I said) it seemed to require the Key, > > > CErtificate, & Password on both ends. > > > > Some sample code: http://www.opensslbook.com/code.html > > The book is also nice reading... > > > > You should not need keys or Password on the client side (if you don't > > want to do client authentication). Also you should not need the server's > > certificate in advance (it is sent to the client during SSL handshake), > > just the certificate of it's CA. OK, in case of self signed certificates > > that's the same... ;) > > > > I guess you are setting up "client" and "server" symmetrically (a > > peer-to-peer setup), so both sides want to authenticate and therefore > > need keys and password. In the most common SSL applications (like HTTPS) > > usually only the server authenticates and the client remains anonymous. > > Some code snippets of your SSL related code might help to evaluate if I > > am guessing correct... > > > > Hope it helps, > > Ted > > ;) > > > > -- > > PGP Public Key Information > > Download complete Key from http://www.convey.de/ted/tedkey_convey.asc > > Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]