[SERVER-39970] Report all handshake errors to client Created: 05/Mar/19  Updated: 08/Jan/24  Resolved: 12/Mar/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.1.8
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Backlog - Service Architecture
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-39941 Report TLS handshake errors to client Backlog
Assigned Teams:
Service Arch
Participants:

 Description   

Related to https://jira.mongodb.org/browse/SERVER-39941, if a server is configured with TLS on and the client connects without TLS, the server outputs the following in its log:

2019-03-04T23:22:20.337+0000 D -        [conn27] User Assertion: 17189:The server is configured to only allow SSL connections src/mongo/util/net/message_port.cpp 152
2019-03-04T23:22:20.337+0000 D -        [conn27] User Assertion: 17189:The server is configured to only allow SSL connections src/mongo/db/service_entry_point_mongod.cpp 132
2019-03-04T23:22:20.337+0000 I -        [conn27] AssertionException handling request, closing client connection: 17189 The server is configured to only allow SSL connections
2019-03-04T23:22:20.337+0000 I -        [conn27] end connection 127.0.0.1:41224 (1 connection now open)

On the client side, the client only gets its connection closed, and provides the following diagnostics:

[2019/03/05 12:11:46.568] W, [2019-03-05T17:11:45.067404 #3004]  WARN -- : MONGODB | Failed to handshake with localhost:27017: Mongo::Error::SocketError: EOFError: end of file reached (for 127.0.0.1:27017 (no TLS))

As with 39941, it is impossible to determine the reason why the connection failed from the client side.

While in 39941 the idea is to use the openssl alert mechanism to communicate errors to the client, the failure cases covered by this ticket require a different strategy to report them. Perhaps the server can write a simple (or simplified) ismaster response, even in plain text if the server determines that the client connected without TLS to a TLS server, and wait for a minute to close the connection. Normally the driver would write an ismaster request to the server immediately after opening a connection, hence even with the server not reading the request and writing a predetermined ismaster response this should provide reasonable diagnostics to the client to debug connection failures.



 Comments   
Comment by Mira Carey [ 12/Mar/19 ]

I'm uncomfortable trying to special case getting random bytes for a server that's trying to negotiate TLS. It might be a client connecting with a non-tls mongodb wire protocol handshake, it might also be any other protocol at all. Pre-emptively spamming out isMaster responses to unrelated traffic feels off, and attempting to read enough bytes out of the socket to figure out if it is mongodb wire traffic (and responding appropriately) seems error prone.

Unlike SERVER-39941, I think the case where you've connected to a TLS server with a non-TLS client is reasonably debuggable (checking TLS is an obvious avenue). So I'm going to decline this wontfix.

Generated at Thu Feb 08 04:53:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.