[
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.
