Separate SSL and SRVSSL options for client and server connections #20740
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello Metasploit Team,
This commit introduces a clear separation between SSL options for client connections (
SSL) and server connections (SRVSSL) to prevent accidental HTTPS server activation and improve module clarity.Problem
Previously, the
SSLdatastore option was used for both client-side connections (viaHttpClient,Tcp) and server-side connections (viaHttpServer,FtpServer). This created a dangerous coupling where enablingSSL => truefor client connections could inadvertently activate HTTPS on the server side, causing exploits to fail silently.Modules had to use workarounds like temporarily modifying the
SSLdatastore option when starting servers:While it was possible to pass
sslas a parameter tostart_service(), this approach was inconsistent and still relied on theSSLdatastore option as a fallback, making the behavior unpredictable and potentially causing silent failures during exploitation. Additionally, the parameter name has been changed fromssltoSsl(with capital S) to be consistent with other option names likeServerPortandServerHost.Changes
SRVSSLoption inSocketServermixin (default: false)SSLoption fromTcpServer(now uses SRVSSL from SocketServer)HttpServer.start_serviceto acceptopts['Ssl']as override (for explicit control, thoughSRVSSLworks implicitly)SRVSSLfor server-side SSL configuration viaTcpServer.ssl()'ssl' => falseto use'Ssl' => falsefor claritySRVSSLusagemsftidyto recognizeSRVSSLas universal optionThis ensures that server and client SSL configurations are independent, preventing unintended HTTPS server activation when
SSLis enabled for client connections.Benefits
With this change, exploit modules no longer need to temporarily modify the
SSLdatastore option when starting HTTP servers. TheSRVSSLoption works implicitly, but modules can also pass'Ssl' => false(ortrue) as an explicit override tostart_service()if they prefer to be explicit. This eliminates workarounds, removes hidden behavior that could cause silent failures, and makes SSL configuration explicit and predictable.