SSL and TLS Protocol Versions
By default, new clients connecting to new servers use TLSv1.2.
Clients and servers choose the highest TLS version supported by both ends of the connection.
If the "client" is not explicitly set, explicitly setting the server's ssl.tls.version.min and ssl.tls.version.max configurables will apply to "client" connections for backwards compatibility.
Configurables
Two server configurables restrict the allowed TLS versions when a new client connects to a new server:
ssl.tls.version.min [default=10]
ssl.tls.version.max [default=12]
Each of these configurables can take one of the following values:
13 specifies TLSv1.3
12 specifies TLSv1.2
11 specifies TLSv1.1
10 specifies TLSv1.0
- ssl.tls.version.min configurable specifies the lowest TLS version that will be accepted
- ssl.tls.version.max specifies the highest TLS version that will be accepted.
The 2021.1 release introduced two corresponding configurables on the client side:
The range of values that the client-side configurables accept is not necessarily identical with the range of values that the server-side configurables accept. Clients and servers choose the highest TLS version supported by both ends of the connection.
These "client" and server) of configurables can be used in servers, proxies, or brokers where both upstream (client-side) and downstream (server-server) connections are made. For example, in edge-to-edge chaining, one edge server acts as a "client" to another edge server. This aspect of a server as a "client" applies to other scenarios as well, such as centralized authorization server (P4AUTH), centralized changelist server (P4CHANGE), and when one server accesses a "remote depot" on another server.
After you change the value of these configurables, you must explicitly "stop" the server.
p4 admin restart is NOT sufficient.
The change takes effect after a complete "stop" and start.
- For UNIX, see Stopping the Helix Server and Starting the Helix Server.
- For Windows, see Starting and stopping the Perforce service.
TLS 1.3 is faster than TLS 1.2 at file transfers, but establishing a TLS 1.3 connection requires more overhead. (Note that the higher the latency, the less the connection overhead matters.)
Applications that rely on many short-lived connections might want to pin their version to 1.2 if using a 1.3-enabled server.
If the client-side configurables are not set
To force the use of TLSv1.3, set
ssl.tls.version.min=13 ssl.tls.version.max=13
To force the use of TLSv1.2, set
ssl.tls.version.min=12 ssl.tls.version.max=12
To allow TLSv1.2 or TLSv1.3, but exclude TLSv1.0 and TLSv1.1, set
ssl.tls.version.min=12 ssl.tls.version.max=13
These configurables can also be used by clients for testing purposes or to prevent connecting to servers below a minimum version.
On a client, to verify that TLSv1.0 does not connect:
p4 -v ssl.tls.version.min=10 -v ssl.tls.version.max=10
info
Values of either configurable outside of the legal range will be treated as if they were pinned to the nearest end of the range. Thus values below 10 will be treated as 10, and values above 13 will be treated as 13.
