On Wed, Mar 07, 2007 at 03:34:31AM +0100, Vladislav Marinov wrote:
> > Unless the server solicited the client connection, and was expecting
> > a connecting from a *given* client, it typically makes to sense to tie
> > the client credentials to the client's IP address, rather if you have
> > a client cert, that's the client you are talking to, and you apply any
> > rights/ACLs that go with that identity.
> >
> >
> The server is simply waiting for connections and when a client connects
> and presents a certificate I want to make sure that
> 1. The client has a valid X.509 certificate
This is fine.
> 2. The client who is presenting the certificate is the one who owns the
> certificate (to avoid attacks when a client presents a valid certificate
> that does not belong to him)
This makes no sense, the client can only "present" the certificate if it
has the corresponding private key. When it has the private key, and the
certificate is not revoked (or as with most applications you are not checking
CRLs) it can assert the identity in the matching certificate.
> This is why I want to extract information about who is the hostname/IP
> participating in the TLS handshake and compare it to the Common Name
> field in the certificate.
This makes no sense, the client could be behind a NAT firewall, ... its
network address should be irrelevant, perform access control on the client
identity found in the cert, and ignore the IP address.
> >> validation - it compares the *physical* hostname/IP address of the
> >> client with the Common Name field of a X.509 certificate.
> >
> > Why?
>
> I mentioned the reasons above - I want to authenticate a specific
> hostname/IP address.
This makes no sense, unless you are building a VPN and want to tie acccess
rights to verified IP addresses. What sort of application is this?
> > Why?
>
> In TLS one can simply extract such information from the call to
> accept(). However in DTLS there is no call to accept(), so we have
> SSL_accept() and then we proceed to SSL_read() and SSL_write(). I cannot
> find a way to extract information about the other party in this DTLS
> connection.
You should be able to call SSL_get_peer_certificate().
> > What problem are you solving? Why do you need to validate the peer name
> > before the data is received? You can do it after the handshake is complete
> > just before you use the data.
>
> Basically I have my server waiting for connections from users. Think
> about the username being the IP address/ hostname of the client. If the
> client presents a valid certificate then this is considered a valid
> authentication.
Why not use the IP address in the certificate as the user name and ignore
the trivially forgeable source of the datagram that carries the packet.
> This is why it is important that the client does not
> present a certificate that belongs to somebody else and this is why I
> compare the hostname/IP address with what is in the common name field of
> the certificate.
Clients can't "present" certificates unless they have access to the private
key. Any connection with the source IP address of the packets is generally
unreliable (NAT) and not secure.
> It doesn't really matter when I do the comparison i.e
> when I check the certificate with my validation function but my problem
> is that I cannot extract the IP address/hostname of the other party in
> the SSL connection.
I still think you are not explaining the requirements clearly, or are
confused about the security model.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
