I fully understand your arguments about the "magic crypto fairy dust", and
thankfully I won't be the sole person dealing with this if we decide to
actually implement it. One of the advantages of working for the DOD is
there are plenty of security people to go around :)
Right now I'm just trying to get an idea of a few things:
1) Amount of code modification we'll have to make to the app.. currently
this seems relatively minimal. All the communication goes through 1 C++
class, so it seems we'll need to extra code at the startup, then just
replace recv/send with SSL_write/SSL_read.
2) Inconvenience to the Users & Admins to make it work - If we want full
authentication, then it seems we're gonna have to get into the CA business
and, like you mention, deal with Generating/Expiring certificates and keys
and such..
3) Level of Security - I'm still not certain (waiting for input from the
Security folks) whether we need Authentication or just end-to-end
encryption.. I've been looking into the DH encryption stuff (no
authentication), but i'm concerned about the problem you pointed out
"Verifying the identity of the server". How is this done in an SSL sorta
way?
My biggest problem has been finding documentation on all this. The API
documentation helps some, but it seems most of the information is locked up
in Paper books. I can go get a book, but then I'm down for 2-3 weeks while
I wait for it to arrive (don't ask, govt red tape). Most of the
documentation is specifically targeted toward HTTPS, which isn't what i'm
doing.
On 2/14/07, Patrick Patterson <[EMAIL PROTECTED]> wrote:
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]
--
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL
