knb MNs and CNs allow self-signed certificates to connect
I have a self-signed certificate that succeeds in mn.ping(), mn.listObjects() and mn.isAuthorized() against demo1.test.dataone.org.
a) an expired certificate for the same user (signed by dataone CA) fails to establish a connection, and
b) my MobileMe certificate passed by the Safari browser fails to establish a connection
poses a security risk to the system.
also tests the same way for cn-dev, so maybe a problem with CN deployment packaging as well.
#2 Updated by Chris Jones over 10 years ago
- Status changed from New to In Progress
- Target version set to Sprint-2012.09-Block.2.1
The SSL configuration for Apache has:
meaning that a client may or may not send a valid cert. If we set it to 'none', the behavior is the same. If we set it to 'require', no SSL connections will be allowed without a valid cert (limited to cilogon and dataone on the CNs, and any on the MN depending how we decide to limit the authorized CAs.
This seems black and white: either we force or don't force valid client certs - we can't have an in between that I can see.
#3 Updated by Ben Leinfelder over 10 years ago
We have to keep it as optional or else there will not be any notion of public access -- all communication with the server will require a valid certificate.
My understanding of client certificate processing was that only client certificates signed by a CA that the server trusted would be accepted and any others would be ignored (treated as though there were no certificate at all). This makes it a little more difficult to immediately recognize why you don't have access to some protected resource, but I think it's not that bad in the grand scheme of things.
Just because you are "using a self signed cert" doesn't mean the server used it or even asked for it. At least that's what I was seeing back in the day when we first started down this client certificate road.
#5 Updated by Dave Vieglais over 10 years ago
- Target version deleted (
The issue is related to he SSL handshake process. The server indicates which CAs it will trust, if the (java) client does not have a certificate that matches, then it wil continue the connection with no certificate, and so will be connecting as public. This is not a security risk (since only public content will be seen), however there should be some feedback to the user that the connection is as a public user.
It is necessary for the certificate acceptance to be optional since otherwise, as Ben indicates, all connections will require a certificate which makes all interactions significantly more complex.
Moving this issue to the backlog, since notifying the user of who they are connected as is important, but not critical for the public release.