securing my client / server application

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

securing my client / server application

Severine-2

Hi all and thanks in advance for your help.
Here is my problem.
My current project is to secure a client/server application using SSL .
The application has already its own client/server tcp socket. This
socket can be either a client or a server depending on the case.
That is because the application can act as a server or a client
connecting to another server.

For now, I generate self-signed certificates to implement that. I
followed OpenSSL book to generate a Root CA, a Server CA, a server
certificate and a client certificate. I 've set the common name of both
client and server certificates to "localhost".  I've read that
somewhere. For now, my application can act as a webserver, I manage to
browse pages. (Only on one machine and only with firefox, but that is a
tiny problem compared to the rest). The 4 files ar put next to my
application binary

My first question is :  does "localhost" as CommonName makes sens? As
the application can be installed on all the machines of a network, I
tried this solution.
Or will I have to generate automatically certificates in my applictaion
so that the common name is the name of the machine?

My second problem is the following : with all these things put in place,
I can't manage to have a client on a first machine, connecting to a
server on a second one.
The SSL_connect function on the client returns 0 and the SSL_accept on
the server generates a SSL_ERROR_WANT_READ error. My socket is non blocking.

Does any one have a clue for me?

Thanks in advance to have read all this long mail.






______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: securing my client / server application

Kyle Hamilton
On 3/14/06, Severine <[hidden email]> wrote:

>
> Hi all and thanks in advance for your help.
> Here is my problem.
> My current project is to secure a client/server application using SSL .
> The application has already its own client/server tcp socket. This
> socket can be either a client or a server depending on the case.
> That is because the application can act as a server or a client
> connecting to another server.
>
> For now, I generate self-signed certificates to implement that. I
> followed OpenSSL book to generate a Root CA, a Server CA, a server
> certificate and a client certificate. I 've set the common name of both
> client and server certificates to "localhost".  I've read that
> somewhere. For now, my application can act as a webserver, I manage to
> browse pages. (Only on one machine and only with firefox, but that is a
> tiny problem compared to the rest). The 4 files ar put next to my
> application binary
>
> My first question is :  does "localhost" as CommonName makes sens? As
> the application can be installed on all the machines of a network, I
> tried this solution.
> Or will I have to generate automatically certificates in my applictaion
> so that the common name is the name of the machine?

'localhost' as CommonName (or rather, subjectAltName) only makes sense
if it's on the same machine.  Otherwise, it needs to be the actual
name of the machine as it's known to the rest of the network, else
it'll have a problem verifying.

> My second problem is the following : with all these things put in place,
> I can't manage to have a client on a first machine, connecting to a
> server on a second one.
> The SSL_connect function on the client returns 0 and the SSL_accept on
> the server generates a SSL_ERROR_WANT_READ error. My socket is non blocking.

SSL_accept returns SSL_ERROR_WANT_READ when the underlying BIO needs
its filehandle to be read, so that it can process the next part of the
data stream.

(Considering I work with basically only the server side, I don't know
about SSL_connect and its semantics.  Anyone else?  Also, you may wish
to read the manpages for SSL_accept and SSL_connect.)

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: securing my client / server application

Severine-3



> 'localhost' as CommonName (or rather, subjectAltName) only makes sense
> if it's on the same machine.  Otherwise, it needs to be the actual
> name of the machine as it's known to the rest of the network, else
> it'll have a problem verifying.
>  
Thanks for your fast answer.
Well I've just generated certificates with the machine names. And the
problem is the same. Or maybe I'm still wrong with my certificates.
> SSL_accept returns SSL_ERROR_WANT_READ when the underlying BIO needs
> its filehandle to be read, so that it can process the next part of the
> data stream.
>
>  
I've read the man pages for SSL_accept and the only clue I first found
was the non-blocking socket. And mine was already non-blocking.
What do you mean then?
I tried to continue despite the WANT_READ error and when I call
BIO_gets, it does not read anything : it returns -1 (and SSL_ERROR_SSL
if I use SSL_get_error which I'm not sure)
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: securing my client / server application

Mikhail Kruk-2
> Thanks for your fast answer.
> Well I've just generated certificates with the machine names. And the problem
> is the same. Or maybe I'm still wrong with my certificates.

The name in the certificate will not be automatically verified for you.
Your application has to verify that the name specified in the certificate
somehow matches who your peer claims to be.  So if client verifies a
certificate of a server it should make sure that the name in certificate
matches the hostname that it used to connect to this server.  With client
it's usually app specific -- somewhere as part of your protocol your
client is probably supplying username or something like that -- this
username should be verified to be mentioned in the certificate.  If your
server doesn't do any authentication of the client you don't need the
client certificate at all.

> I've read the man pages for SSL_accept and the only clue I first found was
> the non-blocking socket. And mine was already non-blocking.
> What do you mean then?
> I tried to continue despite the WANT_READ error and when I call BIO_gets, it
> does not read anything : it returns -1 (and SSL_ERROR_SSL if I use
> SSL_get_error which I'm not sure)

When the socket is non-blocking you have to pretty mcuh always assume that
any call can fail with WANT_READ or WANT_WRITE and you will have to just
repeat the call again. Usually it is a good idea to do appropriate (read
or write) select() before repeating the call.

Look at the easy-tls demo (part of OpenSSL) for examples on how to use
non-blocking sockets.

Use ERR_get_error() to log real errors you get from SSL, e.g.:

  while ((serr = ERR_get_error()) != 0)
  {
  ERR_error_string_n(serr, buf, sizeof(buf)/sizeof(buf[0]));
  printf(buf);
  }
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: securing my client / server application

Severine-3
Thansk for you answer

> The name in the certificate will not be automatically verified for
> you. Your application has to verify that the name specified in the
> certificate somehow matches who your peer claims to be.  So if client
> verifies a certificate of a server it should make sure that the name
> in certificate matches the hostname that it used to connect to this
> server.  With client it's usually app specific -- somewhere as part of
> your protocol your client is probably supplying username or something
> like that -- this username should be verified to be mentioned in the
> certificate.  If your server doesn't do any authentication of the
> client you don't need the client certificate at all.
For now, I don't even want to verify anything. and even when implenting
the server and using it with a web browser, I have problems : FireFox
works wuite fine, but I can't have any page displayed with IE 6.

>> I've read the man pages for SSL_accept and the only clue I first
>> found was the non-blocking socket. And mine was already non-blocking.
>> What do you mean then?
>> I tried to continue despite the WANT_READ error and when I call
>> BIO_gets, it does not read anything : it returns -1 (and
>> SSL_ERROR_SSL if I use SSL_get_error which I'm not sure)
>
> When the socket is non-blocking you have to pretty mcuh always assume
> that any call can fail with WANT_READ or WANT_WRITE and you will have
> to just repeat the call again. Usually it is a good idea to do
> appropriate (read or write) select() before repeating the call.
What if I use a blocking socket?
Anyway, as I can now start to connect to my server via a web browser,
I'm coming to the client part.
The SSL_connect always return 0.
here are the piece of code I wrote :

----------------------------------------------------------------------------------------------------------------------------------
client part:

    /* Build our SSL context*/
    SSL_METHOD *meth;
    /* Global system initialization*/
    SSL_library_init();
    SSL_load_error_strings();
    //OpenSSL_add_all_algorithms();
   
    // Create our context
    meth=SSLv23_method();
    ctxSSLContext=SSL_CTX_new(meth);
    if (!(SSL_CTX_load_verify_locations (ctxSSLContext, CA_LIST, NULL)))
    {
        printf ("Can't read CA list\n");
    }
 
 
        /* Connect the SSL socket */
    sslSocket = SSL_new (ctxSSLContext);
   
    //SSL_set_fd (sslSocket, SocketId);
   
    if (!sslSocket)
    {
            printf(" sslSocket is NULL\n");
    }
   
   
    bioSSLSocket = BIO_new_socket (SocketId, BIO_NOCLOSE);
    if (!bioSSLSocket)
    {
            printf (" bioSSLSocket is NULL\n");
    }
    SSL_set_bio (sslSocket, bioSSLSocket, bioSSLSocket);
 
    int r = SSL_connect (sslSocket);
   
    if((r <= 0))
    {
        int r = SSL_get_error (sslSocket, r);
        printf       ("SSL_connect error %d \n", r);
    }
    printf ("SSL connect connection using %s\n", SSL_get_cipher
(sslSocket));

----------------------------------------------------------------------------------------------------------------------------------
server part:
    /* Build our SSL context*/
    SSL_METHOD *meth;
    /* Global system initialization*/
    SSL_library_init();
    SSL_load_error_strings();
    //OpenSSL_add_all_algorithms();
   
    // Create our context
    meth=SSLv23_method();
    ctxSSLContext=SSL_CTX_new(meth);

    if (!( SSL_CTX_use_certificate_chain_file (ctxSSLContext, KEYFILE)))
    {
        printf ("Can't read certificate server file\n");
    }

   
    SSL_CTX_set_default_passwd_cb (ctxSSLContext, SSHPasswordCallback);

    if (!(SSL_CTX_use_PrivateKey_file (ctxSSLContext, KEYFILE,
SSL_FILETYPE_PEM)))
    {
        printf ("Can't read key file\n");
    }
   
    if (!SSL_CTX_check_private_key (ctxSSLContext))
    {
        printf ("Can't check key file\n");
    }
   
    if (!(SSL_CTX_load_verify_locations (ctxSSLContext, CA_LIST, NULL)))
    {
        printf ("Can't read CA list\n");
    }

   
    // SSL
    ptrSocket->sslSocket = SSL_new (ctxSSLContext);
   
    //SSL_set_fd (sslSocket, GetSocketId ());
   
    if (!ptrSocket->sslSocket)
    {
        printf(" sslSocket is NULL\n");
    }
   
   
    ptrSocket->bioSSLSocket = BIO_new_socket (GetSocketId (), BIO_NOCLOSE);
    if (!bioSSLSocket)
    {
        printf(" bioSSLSocket is NULL\n");
    }
   
    SSL_set_bio (sslSocket, bioSSLSocket, bioSSLSocket);
   
    //SSL_set_mode (sslSocket, SSL_MODE_AUTO_RETRY);
   
    int iError = SSL_accept (sslSocket);

    if ((iError <= 0))
    {
        int r = SSL_get_error (sslSocket, iError);
     
       printf ("SSL_accept error %d \n", r);
    }
   
    printf ("SSL accept connection using %s\n", SSL_get_cipher
(ptrSocket->sslSocket));
   

    ptrSocket->bioIO = BIO_new (BIO_f_buffer ());
    ptrSocket->bioSSL_BIO = BIO_new (BIO_f_ssl ());
    BIO_set_ssl (ptrSocket->bioSSL_BIO, ptrSocket->sslSocket, BIO_CLOSE);
    BIO_push (ptrSocket->bioIO, ptrSocket->bioSSL_BIO);

----------------------------------------------------------------------------------------------------------------------------------

And in my socket Send and Receive methods, I Use BIO_read and
BIO_write/BIO_flush functions.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: securing my client / server application

Mikhail Kruk-2
>> The name in the certificate will not be automatically verified for you.
>> Your application has to verify that the name specified in the certificate
>> somehow matches who your peer claims to be.  So if client verifies a
>> certificate of a server it should make sure that the name in certificate
>> matches the hostname that it used to connect to this server.  With client
>> it's usually app specific -- somewhere as part of your protocol your client
>> is probably supplying username or something like that -- this username
>> should be verified to be mentioned in the certificate.  If your server
>> doesn't do any authentication of the client you don't need the client
>> certificate at all.
> For now, I don't even want to verify anything. and even when implenting the
> server and using it with a web browser, I have problems : FireFox works wuite
> fine, but I can't have any page displayed with IE 6.

Do you get any error?  Might be result of not having the right ciphers
configured.

>>> I've read the man pages for SSL_accept and the only clue I first found was
>>> the non-blocking socket. And mine was already non-blocking.
>>> What do you mean then?
>>> I tried to continue despite the WANT_READ error and when I call BIO_gets,
>>> it does not read anything : it returns -1 (and SSL_ERROR_SSL if I use
>>> SSL_get_error which I'm not sure)
>>
>> When the socket is non-blocking you have to pretty mcuh always assume that
>> any call can fail with WANT_READ or WANT_WRITE and you will have to just
>> repeat the call again. Usually it is a good idea to do appropriate (read or
>> write) select() before repeating the call.
> What if I use a blocking socket?

Blocking socket should only return with a success or final failure (which
doesn't have to be retried).

> Anyway, as I can now start to connect to my server via a web browser, I'm
> coming to the client part.
> The SSL_connect always return 0.

Use the error printing routins I mentioned in my prev. email to get
details on why does it fail.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]