On Mon, May 22, 2006 at 08:47:50PM +0200, Marek Marcola wrote:

> > In my case I don't know who the special clients are, until they send
> > their credentials. Only the clients know in advance that they are special.
> > 
> > Is it possible for a client to unilaterally provide credentials without
> > the server explicitly requesting them? If that were possible, I could
> > stop requesting credentials from all clients.
>
> According to SSL3/TLS1 specification server decides to request client
> authentication or not.
> Client authentication is triggered by server by sending to client 
> CertificateRequest handshake packet (in first client connection
> or in re-handshake (renegotiation)).
> 
> > I can also operate a separate service port for clients that need to
> > send credentials, but if I can avoid it, and not lose connectivity
> > with misconfigured clients, I'd like to explore that option.
>
> I think that in this situation only modifying OpenSSL code may help.
> (workaround against bad configured client) - but this may only
> complicate things.
> 
> There are some SSL record layer callbacks in OpenSSL which
> may be used but this is bad solution :-)  

So, faced with clients (whose credentials I don't really need) that get
the client authentication wrong, it seems that the best solution for now
is to not ask for credentials unless they are always needed, which means
a separate service port for clients that authenticate :-(

If, in the fullness time, someone has time to make successful decryption of
client credentials a non-fatal error, I think that would be a useful feature,
provided that it is possible to continue the protocol without verifying the
client's signature with any credentials supplied discarded...

For now, I will go the multiple ports route...

-- 
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to