Enabling older protocols (TLSv1, TLSv1.1)

[RoganDawes]

Hi folks,

I am making a tool for building intercepting proxies called Mallet, with the goal of proxying and intercepting arbitrary protocols. One of the use cases is testing how well clients are verifying server certificates, etc, for which I need to attempt to intercept the TLS comms, and present my own certificates. While I recognise that TLSv1 and TLSv1.1 have officially been deprecated in RFC8996, and SSLv3 long before that, I do still encounter systems in the field that are still using these protocols, and as such, need to support them as far as possible.

As such, I have been testing the BouncyCastle libs as a possible way to support protocols that are no longer available in the JRE/JDK. Unfortunately, although I have been following the basic TLSServerExample.java code in the TLSUserGuide.pdf, and added calls to sSock.setEnabledProtocols(sSock.getSupportedProtocols()); (and printing the results of getSupportedProtocols() includes "TLSv1"), I still get TlsFatalAlertReceived: protocol_version(70) when I attempt to connect using openssl -tls1 or -tls1_1.

Doing some digging, I discovered AbstractTlsPeer has the following code:

    protected ProtocolVersion[] getSupportedVersions()
    {
        return ProtocolVersion.TLSv13.downTo(ProtocolVersion.TLSv12);
    }

which appears to override the String array of enabled protocols, no matter what I do, whether modifying jdk.tls.disabledAlgorithms or jdk.tls.server.protocols.

Is my interpretation correct, and is this intended behaviour?

[peterdettman]

No, that method is overridden in ProvTlsServer to return the versions specified in the SSLParameters, subject to any algorithm constraints.

Those include "jdk.tls.disabledAlgorithms" and "jdk.certpath.disabledAlgorithms" plus any user-specified ones (via SSLParameters). Note that you can't just comment those security properties out (or unset them in code) as we use a default value in that case (which default for jdk.tls.disabledAlgorithms includes early protocol versions).

Especially if sSock.getSupportedProtocols definitely includes "TLSv1", the algorithm constraints seems the only way this could be failing (of course our test suite uses basically the same code to test each cipher suite at each supported version).

There will be a secondary issue that you need a suitable cipher suite enabled, but in this case the specific alert (protocol_version(70)) is only raised when the server doesn't have any of the client-requested protocols enabled.

[RoganDawes]

Thanks so much for the quick response.

This is my server code, with the properties overridden as the first thing in main():

public class TLSServerExample {
	public static void main(String[] args) throws Exception {
		System.setProperty("jdk.tls.disabledAlgorithms", "SSLv3");
		System.setProperty("jdk.tls.server.protocols", "TLSv1, TLSv1.1, TLSv1.2, TLSv1.3");

		Security.addProvider(new BouncyCastleProvider());
		Security.addProvider(new BouncyCastleJsseProvider());
		
		SSLContext sslContext = SSLContext.getInstance("TLS", "BCJSSE");
		KeyManagerFactory keyMgrFact = KeyManagerFactory.getInstance("PKIX", "BCJSSE");
		keyMgrFact.init(Utils.createServerKeyStore(), Utils.SERVER_PASSWORD);
		sslContext.init(keyMgrFact.getKeyManagers(), null, null);
		SSLServerSocketFactory fact = sslContext.getServerSocketFactory();
		SSLServerSocket sSock = (SSLServerSocket) fact.createServerSocket(Utils.PORT_NO);
		System.err.println("Supported Protocols: " + Arrays.asList(sSock.getSupportedProtocols()));
		sSock.setEnabledProtocols(sSock.getSupportedProtocols());
		System.err.println("Enabled Protocols: " + Arrays.asList(sSock.getEnabledProtocols()));
		sSock.setEnabledCipherSuites(sSock.getSupportedCipherSuites());
		SSLSocket sslSock = (SSLSocket) sSock.accept();
		Protocol.doServerSide(sslSock);
	}
}

This is the output when run, and connected to using openssl:

Jul 10, 2024 6:32:52 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFO: Found string security property [jdk.tls.disabledAlgorithms]: anon, NULL
Jul 10, 2024 6:32:52 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFO: Found string security property [jdk.certpath.disabledAlgorithms]:
Jul 10, 2024 6:32:52 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSystemProperty
INFO: Found string system property [jdk.tls.server.protocols]: TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
Supported Protocols: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3]
Enabled Protocols: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3]
session started.
Jul 10, 2024 6:32:59 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeBeginning
INFO: [server #1 @f14a7d4] accepting connection from 127.0.0.1:62786
Jul 10, 2024 6:32:59 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyAlertReceived
INFO: [server #1 @f14a7d4] received fatal(2) protocol_version(70) alert
Jul 10, 2024 6:32:59 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyConnectionClosed
INFO: [server #1 @f14a7d4] disconnected from 127.0.0.1:62786
Exception in thread "main" org.bouncycastle.tls.TlsFatalAlertReceived: protocol_version(70)
	at org.bouncycastle.tls.TlsProtocol.handleAlertMessage(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.processAlertQueue(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
	at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
	at org.bouncycastle.tls.TlsServerProtocol.accept(Unknown Source)
	at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
	at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.handshakeIfNecessary(Unknown Source)
	at org.bouncycastle.jsse.provider.ProvSSLSocketDirect$AppDataOutput.write(Unknown Source)
	at java.base/java.io.OutputStream.write(OutputStream.java:127)
	at Protocol.doServerSide(Protocol.java:33)
	at TLSServerExample.main(TLSServerExample.java:36)

This is also with the disabledAlgorithms modified in the java.security file.

[peterdettman]

FYI, "jdk.tls.disabledAlgorithms" is a security property, not a system property (so Security.setProperty should be used). However the logs show a value for it that doesn't include the protocols anyway, so it's a bit mysterious.

[peterdettman]

I had assumed the server was raising the exception, but the stack trace shows in fact the client does. Can you see what version the server negotiated (either with wireshark or in the openssl log or in the BCJSSE log if you set the level down to FINE)?

[peterdettman]

We never supported EXPORT anything, RC4 was removed 7 years ago, and MD5... is maybe still around in the non-FIPS version if the Provider were to actually include any of those cipher suites in the supported list (?) - and algorithm constraints permitting of course.

[RoganDawes]

We have an Efergy Power meter that wants to report its values to an online service. DNS shenanigans can make it connect to your own server, and it doesn't validate the certificate that the server presents (expired 3 years ago). Unfortunately, it tries to negotiate SSLv3 with SSL_RSA_EXPORT_WITH_RC4_40_MD5 or SSL_RSA_WITH_RC4_128_MD5 ciphers. Those are the only ciphers supported, since it is a microcontroller (PIC18F). We spent about 24 hours trying to get something that it could connect to successfully, before installing ubuntu 8.04(!) to get a version of openssl s_server that could actually negotiate a connection!

In general, for a tool (Mallet) that aims to test security of SSL clients, having it report failures to negotiate because of protocol or cipher mismatches caused by limitations in the tool is a very different result to the client properly validating the certificate that is presented, and rejecting the negotiation as a result.

[mouse07410]

Between RC4-40bit and NULL, maybe NULL is a better option - user won't have any illusion of privacy.

[RoganDawes]

So, basically, BouncyCastle also cannot use either of those two protocols? Again, this is not about what is secure or best practise, this is purely about interoperability with an existing system that I have zero control over, and is likely to never be updated.

[peterdettman]

In the case of RC4, the TLS implementation was removed, not just de-configured. There's no inherent barrier to re-adding it. RSA_EXPORT was never implemented; I gather it wouldn't be a huge amount of work to implement, but never familiarized myself with the details.

[RoganDawes]

As a final conclusion, it turns out I was just being an idiot, and not actually trying the native JDK/JRE implementation in the first place. Or stopped trying after failing initially, before correctly configuring the java.security properties.

Anyway, I have been able to negotiate my SSLv3/SSL_RSA_EXPORT_WITH_RC4_40_MD5 connections successfully now. Thanks all for contributing.

Now the last thing to figure out is how to determine the remote end's supported ciphers when the handshake fails.