Bug #7504
Investigate support for TLS Server Name Indication during CN-to-MN communications
100%
Description
Read operations during synchronization of both the mnTestNRDC1 and NRDC MN fails with a "java.net.SocketException: Connection reset" exception message (see below). This state began on 13 November on cn-stage and on 30 Nov on cn (production) immediately after approving the urn:node:NRDC MN. CN communication with urn:node:mnTestNRDCI prior to 2015-11-14 00:00:00 UTC on cn-stage occurred without error. Email communication with Eric Fritzinger (NRDC administrator) indicates their primary web server was modified to use the TLS Server Name Indication protocol on 13 November 2015.
[ERROR] 2015-11-14 00:00:00,269 (ObjectListHarvestTask:retrieve:251) urn:node:mnTestNRDC1- <?xml version="1.0" encoding="UTF-8"?>
class java.net.SocketException: Connection reset
[ERROR] 2015-11-30 17:45:00,285 (ObjectListHarvestTask:retrieve:251) urn:node:NRDC- <?xml version="1.0" encoding="UTF-8"?>
class java.net.SocketException: Connection reset
Testing with both curl and openssl s_client post-TLS-SNI changes did not reveal any errors. For example: "openssl s_client -servername sensor.nevada.edu -connect sensor.nevada.edu:443" correctly identifies the server certificate, where as "openssl s_client -connect sensor.nevada.edu:443" fails to identify the correct server name during SSL negotiation.
The goal of this ticket is to determine if the core CN java infrastructure supports the TLS Server Name Indication protocol when communicating with a MN that is using TLS SNI.
Related issues
History
#1 Updated by Mark Servilla almost 9 years ago
- Related to MNDeployment #6957: NRDC - Nevada Research Data Center added
#2 Updated by Mark Servilla almost 9 years ago
Relevant thread on Stack Overflow - http://stackoverflow.com/questions/12361090/server-name-indication-sni-on-java
#3 Updated by Rob Nahf almost 9 years ago
- Category set to d1_synchronization
- Project changed from CN REST to Infrastructure
- Assignee set to Rob Nahf
- Target version set to CCI-2.0.0
- Milestone set to None
v2 d1_ilbclient_java uses HttpClient v4.3.3 which supports SNI for clients running on Java 1.7 or higher. SNI negotiation is a TLS issue that is under supported by com.sun.security implementations. HttpClient was able to find an acceptable workaround out of necessity, but couldn't get it to work for Java 1.6. This shouldn't be a problem with DataONE's V2 deployment, but is still a problem with the current CN environment, which runs on Java 1.6.
I suspect the issue is related to running the tests via Java 1.6. I'll try to write a simple java application to test connections to MNs that implement SNI. If this is the cause, there should not be any worry about either the test MN or the production MN in the soon to be released V2 environments.
see:
https://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt
https://issues.apache.org/jira/browse/HTTPCLIENT-1119 (for the solution discussion)
also looked at:
http://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7
http://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/
#4 Updated by Rob Nahf almost 9 years ago
using v2 d1_libclient_java, I was able to get a correct response, but the same query using v1 d1_libclient_java, I got the "Connection reset" error.
Both tests were run using Java 1.7, (a Java 1.6 runtime not easily available).
Requests using v2 d1_libclient_java using Java 1.8 also get a correct response.
#5 Updated by Rob Nahf almost 9 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
- Target version changed from CCI-2.0.0 to CCI-1.5.2
V2 infrastructure will take care of the SNI issue.
It should be noted that DataONE tools and Nodes using a V1 d1_libclient_java will not be able to connect to MNs using SNI.
#6 Updated by Rob Nahf almost 9 years ago
- Related to Story #7586: LogAggregation fails for MN in production with handshake alert added
