[SERVER-12966] SSL connection error from client does not mention SSL Created: 28/Feb/14  Updated: 02/Mar/14  Resolved: 28/Feb/14

Status: Closed
Project: Core Server
Component/s: Networking, Security
Affects Version/s: 2.6.0-rc0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Tyler Brock Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-11292 Connecting to ssl-encrypted mongod wi... Backlog
Related
Participants:

 Description   

This is the message when you connect using a client without ssl to a server that requires SSL:

MongoDB shell version: 2.6.0-rc0
connecting to: test
2014-02-28T20:25:27.549+0000 Socket recv() errno:10054 An existing connection was forcibly closed by the remote host. 127.0.0.1:27
017
2014-02-28T20:25:27.550+0000 SocketException: remote: 127.0.0.1:27017 error: 9001 socket exception [RECV_ERROR] server [127.0.0.1:
27017]
2014-02-28T20:25:27.550+0000 DBClientCursor::init call() failed
2014-02-28T20:25:27.551+0000 Error: DBClientBase::findN: transport error: 127.0.0.1:27017 ns: admin.$cmd query: { whatsmyuri: 1 }
at src/mongo/shell/mongo.js:146
exception: connect failed

The server logs have great messaging here but the client's message tells me absolutely nothing about SSL being the problem.



 Comments   
Comment by Andreas Nilsson [ 28/Feb/14 ]

Can we copy a revised version of Andy's comments maybe and put them in the other ticket so we don't loose information.

Comment by Tyler Brock [ 28/Feb/14 ]

ok, closing it out.

Comment by Tyler Brock [ 28/Feb/14 ]

Yes, I agree. I'm simply saying that in the absence of being able to say for sure, which would obviously be better, we should at least provide the suggestion. Right now as it stands a user of the shell you have absolutely no indication the problem could be SSL/TLS/security anything if you see this.

Comment by Andreas Nilsson [ 28/Feb/14 ]

This duplicates SERVER-11292. See my comments on alternative solutions there.

Comment by Andy Schwerin [ 28/Feb/14 ]

Well, it's also possible that you're talking on the wrong port, to a different service, or that your firewall is misconfigured, among other possibilities. Without some feedback from the remote about what went wrong, we're guessing.

Comment by Tyler Brock [ 28/Feb/14 ]

Why don't we just also print a message like "It's possible this host only accepts SSL connections"

Comment by Andy Schwerin [ 28/Feb/14 ]

andreas.nilsson@10gen.com, any other clever ideas on this one?

Comment by Andy Schwerin [ 28/Feb/14 ]

Because we have layered TLS/SSL below the messaging layer, it's difficult to do anything more than hang up the connection. Here are some ideas, though:

  • Let the connection open, but mark it such that every operation that sends a reply (not fire-and-forget ops) replies with a TLSRequired error code and message, and then maybe hangs up. If new connections run a command or a query early in their life, this might work pretty well.
  • Introduce a startTLS command that initiates the TLS channel. Servers that require TLS would reply with TLSRequired until the startTLS process completes, and would hang up on fire-and-forget writes to indicate failure. This is pretty reasonable for the server, but might be hard for some of the drivers.
Comment by Eric Milkie [ 28/Feb/14 ]

Is this an issue with all the drivers, not just the shell using the c++ driver?

Generated at Thu Feb 08 03:30:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.