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