Skip to content

Conversation

@Chocapikk
Copy link
Contributor

@Chocapikk Chocapikk commented Nov 28, 2025

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 SSL datastore option was used for both client-side connections (via HttpClient, Tcp) and server-side connections (via HttpServer, FtpServer). This created a dangerous coupling where enabling SSL => true for client connections could inadvertently activate HTTPS on the server side, causing exploits to fail silently.

Modules had to use workarounds like temporarily modifying the SSL datastore option when starting servers:

original_ssl = datastore['SSL']
datastore['SSL'] = false
start_service({ 'Path' => '/' })
datastore['SSL'] = original_ssl

While it was possible to pass ssl as a parameter to start_service(), this approach was inconsistent and still relied on the SSL datastore option as a fallback, making the behavior unpredictable and potentially causing silent failures during exploitation. Additionally, the parameter name has been changed from ssl to Ssl (with capital S) to be consistent with other option names like ServerPort and ServerHost.

Changes

  • Add SRVSSL option in SocketServer mixin (default: false)
  • Remove SSL option from TcpServer (now uses SRVSSL from SocketServer)
  • Update HttpServer.start_service to accept opts['Ssl'] as override (for explicit control, though SRVSSL works implicitly)
  • All modules now automatically use SRVSSL for server-side SSL configuration via TcpServer.ssl()
  • Update modules that explicitly used 'ssl' => false to use 'Ssl' => false for clarity
  • Update documentation to reflect SRVSSL usage
  • Update msftidy to recognize SRVSSL as universal option

This ensures that server and client SSL configurations are independent, preventing unintended HTTPS server activation when SSL is enabled for client connections.

Benefits

With this change, exploit modules no longer need to temporarily modify the SSL datastore option when starting HTTP servers. The SRVSSL option works implicitly, but modules can also pass 'Ssl' => false (or true) as an explicit override to start_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant