Introduction

If you want HttpsURLConnection to stop negotiating obsolete SSL protocols, the practical answer is to allow only specific TLS versions on the underlying SSL socket. There is no single “disable SSL” switch on HttpsURLConnection. The real control point is the socket factory and, in some cases, the JVM security configuration.

What the Goal Should Be

In current Java code, the goal is not literally “turn off encryption called SSL.” The goal is to prevent outdated protocols such as SSLv3 and, depending on policy, older TLS versions from being negotiated. In practice, that means you usually want a client that permits only TLSv1.2, TLSv1.3, or whatever your runtime and server both support.

This matters because protocol choice is a security boundary. If the client accepts weak protocols, a misconfigured or legacy server may negotiate them.

Restrict Protocols with a Custom Socket Factory

One common approach is to wrap the default SSLSocketFactory and narrow the enabled protocols every time a socket is created.

1import javax.net.ssl.HttpsURLConnection;
2import javax.net.ssl.SSLContext;
3import javax.net.ssl.SSLSocket;
4import javax.net.ssl.SSLSocketFactory;
5import java.io.IOException;
6import java.net.InetAddress;
7import java.net.Socket;
8import java.net.URL;
9
10public class TlsOnlyConnection {
11    public static void main(String[] args) throws Exception {
12        SSLContext context = SSLContext.getInstance("TLS");
13        context.init(null, null, null);
14
15        URL url = new URL("https://example.com");
16        HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
17        connection.setSSLSocketFactory(new TlsOnlySocketFactory(context.getSocketFactory()));
18
19        System.out.println(connection.getResponseCode());
20    }
21}
22
23class TlsOnlySocketFactory extends SSLSocketFactory {
24    private final SSLSocketFactory delegate;
25
26    TlsOnlySocketFactory(SSLSocketFactory delegate) {
27        this.delegate = delegate;
28    }
29
30    private Socket restrict(Socket socket) {
31        if (socket instanceof SSLSocket sslSocket) {
32            sslSocket.setEnabledProtocols(new String[] {"TLSv1.2", "TLSv1.3"});
33        }
34        return socket;
35    }
36
37    @Override
38    public String[] getDefaultCipherSuites() {
39        return delegate.getDefaultCipherSuites();
40    }
41
42    @Override
43    public String[] getSupportedCipherSuites() {
44        return delegate.getSupportedCipherSuites();
45    }
46
47    @Override
48    public Socket createSocket(Socket s, String host, int port, boolean autoClose) throws IOException {
49        return restrict(delegate.createSocket(s, host, port, autoClose));
50    }
51
52    @Override
53    public Socket createSocket(String host, int port) throws IOException {
54        return restrict(delegate.createSocket(host, port));
55    }
56
57    @Override
58    public Socket createSocket(String host, int port, InetAddress localHost, int localPort) throws IOException {
59        return restrict(delegate.createSocket(host, port, localHost, localPort));
60    }
61
62    @Override
63    public Socket createSocket(InetAddress host, int port) throws IOException {
64        return restrict(delegate.createSocket(host, port));
65    }
66
67    @Override
68    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) throws IOException {
69        return restrict(delegate.createSocket(address, port, localAddress, localPort));
70    }
71}

That keeps normal certificate validation in place while narrowing the protocol list.

Prefer Per-Connection Scope When Possible

HttpsURLConnection.setDefaultSSLSocketFactory(...) changes behavior globally for the whole JVM. That may be appropriate in a small application, but it is risky in shared runtimes and libraries.

If only one outbound integration needs stricter settings, set the socket factory on that one connection object. Localizing the change makes the code easier to reason about and avoids surprising unrelated network calls.

Do Not Confuse Protocol Restriction with Trust Management

A lot of insecure examples on the internet combine protocol restriction with a trust-all certificate manager or disabled hostname verification. Those are different concerns.

Restricting protocols is a good security step. Accepting every certificate is not. If you disable trust verification, you have created a much larger problem than the one you were trying to solve.

So the safe rule is:

• restrict protocols if needed
• keep normal certificate validation
• keep hostname verification enabled unless you have a very controlled reason not to

Check Runtime and Server Compatibility

Protocol restriction only works if the JVM and the remote server share at least one enabled version. For example, forcing TLSv1.3 on an older JVM or against an older server will fail the handshake. Forcing TLSv1.2 and TLSv1.3 together is usually more practical unless your policy says otherwise.

If you are working in a controlled environment, test against the real remote endpoint rather than assuming support based on documentation alone.

Consider JVM-Level Policy Too

In some environments, the cleanest answer is not custom code but a runtime policy. Modern JVMs already disable many obsolete protocols by default, and enterprise deployments sometimes enforce allowed protocols through JVM security properties. If that is available, prefer policy over hand-written connection wrappers.

Code-level control is still useful when one client integration needs behavior that differs from the process default.

Common Pitfalls

The first mistake is assuming HttpsURLConnection exposes a direct boolean setting to disable SSL. It does not. You control the negotiated protocols on the sockets.

Another mistake is solving the wrong problem by installing a trust-all manager. That bypasses certificate verification and weakens security dramatically.

A third issue is enabling only one TLS version without confirming the server and runtime both support it. A failed handshake is often a compatibility mistake, not a Java bug.

Summary

• To stop HttpsURLConnection from using obsolete SSL protocols, restrict the enabled protocols to trusted TLS versions.
• A custom SSLSocketFactory is the usual code-level mechanism.
• Prefer per-connection changes over global JVM changes when the scope is narrow.
• Do not combine protocol restriction with trust-all certificate hacks.
• Verify compatibility between the JVM, your code, and the remote server before enforcing strict protocol lists.