[SERVER-11292] Connecting to ssl-encrypted mongod with non-ssl mongo shell generates confusing error Created: 21/Oct/13  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Security, Shell
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Kyle Erf Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 0
Labels: rp-c
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-8669 When shell fails to connect due to no... Closed
is duplicated by SERVER-12966 SSL connection error from client does... Closed
Related
related to SERVER-11489 Fail gracefully when more than 2 dist... Backlog
is related to SERVER-8731 ssl config server, non-ssl mongos - m... Backlog
Assigned Teams:
Server Security
Participants:

 Description   

Connecting to an encrypted mongod from an unencrypted mongo shell generates this clear server log:

2013-10-21T14:34:47.034-0400 [conn3] AssertionException handling request, closing client connection: 17189 The server is configured to only allow SSL connections

however, from the mongo shell, the user sees:

MongoDB shell version: 2.5.4-pre-
connecting to: test
2013-10-21T14:34:47.034-0400 DBClientCursor::init call() failed
2013-10-21T14:34:47.034-0400 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

which leaves no helpful clue about how to fix the issue. In a perfect world we would print something helpful like "ERROR: Cannot connect to encrypted server with unencrypted mongo shell. Try running mongo with --ssl." This could prove to be too complicated and hackish to implement properly, but would be nice for usability.



 Comments   
Comment by Tyler Brock [ 28/Feb/14 ]

FROM ANDY:

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 Andy Schwerin [ 19/Dec/13 ]

andreas.nilsson@10gen.com, how might we detect this scenario in the shell to improve messaging?

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