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