Hi again, As my security experience is not very broad I think that as you properly pointed I was confused by the security model. From your words I see that only client X can present a certificate that belongs to client X. Why? X.509 certificate simply ties an identity (DNS name for ex.) to a public key. What will happen if client Z presents the certificate that belongs to client X to the server Y. That certificate will carry the public key and the identity of X. How will the server Y understand that it is not X but Y that he is speaking to and therefore it should not provide data to Y? Basically is it enough to only check that a certificate is valid, i.e if the identity of X is sitting in the Common Name field of an X.509 certificate does this guarantee that it is exactly X sitting on the other side of the connection?
Vladislav Victor Duchovni wrote: > 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. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
