You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2007/06/11 21:49:27 UTC
[jira] Created: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
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
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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508105 ]
John H. Embretsen commented on DERBY-2803:
------------------------------------------
I've read the new documentation and I find it very good indeed (though bear in mind that English is not my native tongue either, and I do have prior knowledge of communication security including the SSL protocol). Although I think most of Rick's suggestions are fair and valid, I do have a worry that the meaning of the terms "wire encryption" and "wire traffic" are not necessarily that obvious to a portion of the people who do not speak English natively.
I think it would be both more accurate (after all, there might be lots of _wireless_ client-server connections going on already) and more recognizable (it is hard enough to find things in the docs as it is) if we rather used terms such as "network encryption" and "network traffic" - at least in the headings. Just my 2 cents.
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Assigned: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen reassigned DERBY-2803:
---------------------------------------
Assignee: Bernt M. Johnsen
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507913 ]
Rick Hillegas commented on DERBY-2803:
--------------------------------------
Thanks, Bernt! I have looked at the zip file of html output and I think that this is much easier to understand. I have some comments on the documentation.
DOCUMENTATION
1) I think that the title of this section should be changed to something that suggests why a user would be interested in consulting this section. Perhaps something like this: "Wire Encryption and Peer Authentication". Right now, the title "SSL/TLS" seems like a statement of the solution rather than the problem. I think that the user is more interested in the problem statement.
2) Along the same lines, I think that the section should start out with an introductory sentence or paragraph focusing the reader's attention on the problem rather than the solution.
3) On the same page: I think that the sentence about CA certificates deserves its own paragraph. I understand that you can't go into a detailed explanation of certificates and signing authorities However, it would be helpful if you could at least indicate that you are referring here to the situation in which a 3rd party is vouching for the identity of the other end of the connection.
4) "Key and certificate handling": I would recommend rewriting the first paragraph as follows: "For SSL operation, the server always needs a key pair. If the server runs in peer authentication mode (the server authenticates the clients), then each client needs its own key pair. In general, if one end of the communication wants to authenticate its partner, then the first end needs to install a certificate generated by the partner."
5) "Starting the server with SSL/TLS": I would recommend renaming the "Starting the server with client authentication" subsection to be "Starting a server which authenticates clients" and I would reword its first paragraph as follows: "When the server's SSL mode is set to peerAuthentication, then the server authenticates its client's identity in addition to encrypting wire traffic. In this situation, the server's trust store must contain a certificate for each client which will connect."
6) "Running the client with SSL/TLS": Similarly, I would rename "Running the client with server authentication" to be "Running a client which authenticates the server" and I would reword the first sentence of this section as follows: "If the client wants to authenticate the server, then the client's trust store must contain the server's certificate."
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Updated: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2803:
------------------------------------
Component/s: Documentation
Affects Version/s: 10.3.1.1
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0, 10.3.1.1
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504603 ]
Bernt M. Johnsen commented on DERBY-2803:
-----------------------------------------
Re #2 above. I have read through the adminguide, and in "SSL/TLS" it says: "Peer authentication may be set either on the server or on the client or on both. Peer authentication means that the other side of the SSL connection is authenticated based on a trusted certificate installed locally."
Furthermore, in "Key and certificate handling": "If a client uses peer authentication (the client wants to authenticate the server), a server certificate has to be distributed to the client and imported into the client's truststore (a store of trusted keys)."
Could you elaborate more on what is unclear and perhaps point me to where in the docs information is missing? (My problem is, I guess, that I implemented it, wrote the docs and have lot of SSL experience from the past, so I'm kind of blind here).
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507152 ]
Bernt M. Johnsen commented on DERBY-2803:
-----------------------------------------
Thanks Rick.I think I understand what's unclear and I will remake the docs to try to make things a bit clearer.
> 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.
[jira] Updated: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2803:
------------------------------------
Attachment: DERBY-2803.zip
DERBY-2803.stat
DERBY-2803.diff
Attached patch which rewrites the SSL docs in the admin guide. Need feedback, since enlish is not my native tongue.
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503831 ]
Bernt M. Johnsen commented on DERBY-2803:
-----------------------------------------
There are 3 states, off, basic and peerAuthentication, but since server and client usage is a bit different, the ahve to be documented different. I'll have to take a look at the docs to see if this could be clarified somewhat.
2) This is expected behaviour. peerAuthentication is an unilateral issue (if you ignore the fact that the other part issued a certificate which was stored in the authenticating part's trusted key store).
3) I think you observe expected behaviour here too, since peerAuthentication on one side is independent of the other side.
> 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
> 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.
[jira] Updated: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2803:
------------------------------------
Attachment: DERBY-2803-v2.zip
DERBY-2803-v3.stat
DERBY-2803-v3.diff
Thaks Rick. 1) The toc is not part of attached zip-file, but it builds ok in me sandbox. 2-4) Done. New patch uploaded. Will commit & merge to 10.3 today.
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803-v2.diff, DERBY-2803-v2.stat, DERBY-2803-v2.zip, DERBY-2803-v2.zip, DERBY-2803-v3.diff, DERBY-2803-v3.stat, DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508206 ]
Rick Hillegas commented on DERBY-2803:
--------------------------------------
Thanks, Bernt. I think this is a big improvement and will help customers take advantage of this feature. We are down to copyediting nits now:
1) In the Admin guide, the top page for this feature is titled "Network encryption and authentication with SSL/TLS" now. That's great. A corresponding change needs to be made to the table of contents. There the top level page is still called "SSL/TLS".
2) Some typos in the Admin guide on the page titled "Running the client with SSL/TLS":
a) The phrase "If the server does client authetication" should read "If the server does client authentication"
b) The heading "Running the client when both parties does peer authentication" should read "Running the client when both parties do peer authentication"
3) A little grammar sanding in the Developer's guide section titled "Derby and Security": The phrase "in Derby Server and Administration Guide" would read more smoothly as "in the Derby Server and Administration Guide"
4) Same comment in the Reference guide section titled "ssl=sslMode attribute"
Thanks!
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803-v2.diff, DERBY-2803-v2.stat, DERBY-2803-v2.zip, DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506463 ]
Bernt M. Johnsen commented on DERBY-2803:
-----------------------------------------
I did not get any response on my last comment on this one. Should something be done with the docs or should this issue be closed?
> 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.
[jira] Resolved: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen resolved DERBY-2803.
-------------------------------------
Resolution: Fixed
Committed revision 551080 on trunk
Committed revision 551084 on 10.3 branch
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803-v2.diff, DERBY-2803-v2.stat, DERBY-2803-v2.zip, DERBY-2803-v2.zip, DERBY-2803-v3.diff, DERBY-2803-v3.stat, DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Updated: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2803:
------------------------------------
Affects Version/s: (was: 10.3.1.1)
Fix Version/s: (was: 10.3.0.0)
10.4.0.0
10.3.1.1
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Issue Comment Edited: (DERBY-2803) SSL certificate
authentication succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507878 ]
Bernt M. Johnsen edited comment on DERBY-2803 at 6/25/07 6:43 AM:
------------------------------------------------------------------
Attached patch which rewrites the SSL docs in the admin guide. Need feedback, since English is not my native tongue.
was:
Attached patch which rewrites the SSL docs in the admin guide. Need feedback, since enlish is not my native tongue.
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Commented: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-2803) SSL certificate authentication
succeeds unexpectedly
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2803:
------------------------------------
Attachment: DERBY-2803-v2.zip
DERBY-2803-v2.stat
DERBY-2803-v2.diff
Thanks Rick & John. I have incorporated your comments in V2 of the patch.
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.1, 10.4.0.0
>
> Attachments: DERBY-2803-v2.diff, DERBY-2803-v2.stat, DERBY-2803-v2.zip, DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.
[jira] Closed: (DERBY-2803) SSL certificate authentication succeeds
unexpectedly
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas closed DERBY-2803.
--------------------------------
> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>
> Key: DERBY-2803
> URL: https://issues.apache.org/jira/browse/DERBY-2803
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Bernt M. Johnsen
> Fix For: 10.3.1.4, 10.4.1.3
>
> Attachments: DERBY-2803-v2.diff, DERBY-2803-v2.stat, DERBY-2803-v2.zip, DERBY-2803-v2.zip, DERBY-2803-v3.diff, DERBY-2803-v3.stat, DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
>
>
> 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.