Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <3294518.1182379706058.JavaMail.jira@brutus>
Date: Wed, 20 Jun 2007 15:48:26 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2803) SSL certificate authentication
 succeeds unexpectedly
In-Reply-To: <12858026.1181591367274.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506711 ] 

Rick Hillegas commented on DERBY-2803:
--------------------------------------

I'm not an expert on SSL, but I think I grasp the core of what this feature entails. Correct me if I'm wrong here. When the client and server agree to the Basic ssl mode, their network traffic is then encrypted using a key pair that is stored at the server. When the client and server agree to peer authentication, one side of the connection validates the identity of the other side via a certificate stored at both ends. Alternatively, peer authentication can mean that both sides validate each other's identity via shared certificates.

The following would help me reason about whether I am using this feature correctly: There seem to be 3 peer authentication cases: i) the client verifies the server's identity, ii) the server verifies the client's identity, iii) both sides verify each other's identity. It would help me if the Admin Guide clearly stated which of these cases is being described in a given section of the text. For instance, on the "Running the client" page, I am confused by the heading "With peer (server) authentication". Does this mean that the client is verifying the server's identity or vice-versa?

Thanks.


> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
>                 Key: DERBY-2803
>                 URL: https://issues.apache.org/jira/browse/DERBY-2803
>             Project: Derby
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.3.0.0
>            Reporter: Rick Hillegas
>            Assignee: Bernt M. Johnsen
>             Fix For: 10.3.0.0
>
>
> The following bug report may simply be pilot error. I confess that I am having a hard time understanding the user documentation for this feature. The user documentation is found in the Derby Admin guide in the section titled "SSL/TLS". My confusion arises from the fact that sometimes the documentation talks about 3 SSL states (none, basic, peer) and sometimes the documentation talks about 4 SSL states (none, basic, client certificate, server certificate).
> I tried running an experiment in which the server was setup for "Basic SSL encryption":
> 1) I successfully connected to the server when the client was setup for "Basic SSL encryption". This I expected so good.
> 2) I also successfully connected to the server when the client was setup for "peer (server) authentication". This confused me because the client url was requesting peer authentication but the server was booted with just basic ssl authentication. That is, the client url requested "ssl=peerAuthentication" but the server startup line requested "ssl=basic". I was surprised that the two sides of the connection didn't have to agree on how much authentication was going to be done.
> 3) I also successfully connected to the server when the client was setup for "peer authentication on both sides". This really confused me: It seemed to me that there were 2 certificates involved, but the server, via its startup properties, should only have been aware of one of these certificates, viz., the certificate identified by the javax.net.ssl.keyStore properties.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.