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 "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/02/20 21:06:05 UTC
[jira] Created: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-2363
URL: https://issues.apache.org/jira/browse/DERBY-2363
Project: Derby
Issue Type: Improvement
Components: Network Client, Network Server, Security
Reporter: Daniel John Debrunner
Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen reassigned DERBY-2363:
---------------------------------------
Assignee: Bernt M. Johnsen
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475956 ]
Bernt M. Johnsen commented on DERBY-2363:
-----------------------------------------
Experimenting with this feature, I find that if a client to do an SSL handshake towards a server running a plaintext socket, I get (of course, since the server in that case views the SSL traffic as garbage):
Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3
org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3
at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:469)
at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:348)
at org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:1025)
at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:619)
at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:265)
This, can't be avoided, but adds to the resource overhead of the handshake, since the DRDAConnThread is terminated, which is wise since we don't know *why* we got the DRDAProtocolException. Also, I guess the text also should be changed to indicate a possibility of an SSL conection attempt. Any ideas?
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
> Fix For: 10.3.0.0
>
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474850 ]
Bernt M. Johnsen commented on DERBY-2363:
-----------------------------------------
I like this idea. The client could also keep a hashtable of all host/portnumber pairs to keep track of which servers that are plaintext and thus avoid the overhead of trying out SSL on servers that already proven themselves to be plaintext.
DERBY-2356 proposes three modes for ssl: off, basic and peerAuthentication. If we add negotiable and use that as default for the client we will have all we need.
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476881 ]
Bernt M. Johnsen commented on DERBY-2363:
-----------------------------------------
I have now experimented with two possible approaches.
1) Trying SSL first and fall back to plaintext if the SSL handshake fail. There is two problems with this approach. One is that clients by default will run somewhat slower against plaintext servers (the failed connect will increase the time it takes to connect) and this will probably be the most common scenario (of course this may be avoided by setting the ssl flag explicitely to off). The second problem is that the DRDA_Proto_SYNTAXRM in the initial DRDA handshake should not be displayed to users, but this will also mask any new bugs in the initial DRDA handshake, which I think is a bad thing.
2) The second approach is to try out plaintext first, e.g. with a PING command. This will add an extra roundtrip to the initial sequence in an connect (this may be avoided by setting the ssl flag explicitely). This approach is anyway faster than approach 1) for plaintext servers. The problem with this approach is that all the admin commands (shutdown, sysinfo, ping etc) are implemented in NetworkServerControlImpl and use the error reporting apparatus available here, which is not quite suitable for this purpose. To make a good implementation for this approach, these admin commands should be split out from NetworkServerControlImpl into a separate class or package (which is wise anyway, since these commands are clients and not really very much related to the server).
So?
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
> Fix For: 10.3.0.0
>
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-2363:
-------------------------------------
Assignee: (was: Bernt M. Johnsen)
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476916 ]
Daniel John Debrunner commented on DERBY-2363:
----------------------------------------------
bernt> To make a good implementation for this approach, these admin commands should be split out from NetworkServerControlImpl into a separate class or package (which is wise anyway, since these commands are clients and not really very much related to the server).
+1
In looking at the network startup code (DERBY-1966) it struck me that the NetworkServerControlImpl class is overly complex due to the mixing of client commands and the actual logic to run a network server. Such a split should probably stop using the name NetworkServerControlImpl and instead two classes with names that reflect their purpose, commands and server.
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
> Fix For: 10.3.0.0
>
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475864 ]
Bernt M. Johnsen commented on DERBY-2363:
-----------------------------------------
Negotiating SSL/vs plaintext will give a higher latency in calls to getConnection. Since an implementation will have to try SSL before it tries plaintext, this latency will hit all clients talking to plaintext servers. The extra latency may be avoided by setting "ssl=off" explicitely.
This could be avoided by storing a map of which server/port pairs that responds to SSL and which responds to plaintext. Storing this information in the client must be done under the assumption that if a server is restarted with other ssl settings, all clients will have to be restarted too so that this map may be cleared. Is that a safe assumption?
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
> Fix For: 10.3.0.0
>
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2363:
------------------------------------
Fix Version/s: (was: 10.3.0.0)
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2363) Add initial handshake on connection
setup to determine server's required ssl support level and avoid client
side attribute settings.
Posted by "Bernt M. Johnsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernt M. Johnsen updated DERBY-2363:
------------------------------------
Fix Version/s: 10.3.0.0
> Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2363
> URL: https://issues.apache.org/jira/browse/DERBY-2363
> Project: Derby
> Issue Type: Improvement
> Components: Network Client, Network Server, Security
> Reporter: Daniel John Debrunner
> Assigned To: Bernt M. Johnsen
> Fix For: 10.3.0.0
>
>
> Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties.
> Thus one could change the server to be ssl enabled without having to change any applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.