Join Log in
Score:3
UncleBob avatar Server

Cannot connect to Amazon RDS with TLSv1.2

in flag
UncleBob

I set up a new machine with Ubuntu 20, and found I wasn't able to connect to my RDS databases anymore.

The spring-boot application that was supposed to connect to the development environment throws the following exception:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

So I dug out mySql workbench and tried with that. That resulted in this error:
ssl_choose_client_version:unsupported protocol

Looking for that taught me that Ubuntu 20 had TLSv1.2 set as the minimum TLS version, and that this error happens if your MySQL server didn't support it (from here: https://askubuntu.com/questions/1193629/why-mysql-workbench-8-x-errors-out-with-an-ssl-connection-error-choose-client-v). I tried workbench with SSL turned off, and sure enough it could establish the connection.

The obvious issue with this being, this is Amazon RDS... TLS 1.2 is the only version that can't be disabled, since it's the version used internally, as pointed out here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Ciphers.html

So really, there shouldn't be a problem. I was starting to doubt whether the TLS version was really the problem. But since I didn't have any other leads, I followed the cookbook in the answer here to reconfigure my local openssl to allow minimum TLS version 1 and downgrade the security level: https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level

And wouldn't you know, Workbench now connected with SSL set to required. Spring-Boot still doesn't, I guess I have to configure that somewhere else for it to get the memo. But instead of wasting time on that, I'd rather solve the real issue, which is that I can't connect through TLSv1.2, while for all I can tell I really should be able to. That would be vastly preferable to downgrading my security. I tried to renew the database certificate in case that might be the problem, but the management console found nothing wrong with the certificate and apparently won't let me replace it if I don't need to. So I'm a bit out of ideas on what to try next.

1887
1 + 0
ssl
in flag
BrunoJCM
Related: https://stackoverflow.com/questions/67246010/the-server-selected-protocol-version-tls10-is-not-accepted-by-client-preferences
0
Reply
Score:2
UncleBob avatar Server
in flag
UncleBob

Turns out TLS support depends on the exact database engine version you're using on RDS. Aurora mySQL 5.6 has only support for TLSv1.0 until version 1.23.1, at which point TLSv1.1 and 1.2 become available. Our version was 1.22.something, so I had to upgrade the engine.

Even then it won't work though, because Ubuntu 20 also enforces a minimum dhe key length of 2048 bits, which Aurora mysql 5.6 just doesn't deliver, and for all I can tell this cannot be changed. You will find documentation for database parameters thatcan be used to chenge the diffie-helman key langth, but it turns out those are only for SqlServer, not MySQL. So, you still have to go and apply changes to your openssl.cnf as described in the accepted answer here: https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level THis changes your SECLEVEL to 1, so openssl will accept the shorter DHE-keys.

Even then my spring-boot applications wouldn't connect, although workbench now did. This is because JDBC doesn't tell the server that it can do TLSv1.2 although it totally can (weird decision, that), so the server will never attempt to send a 1.2 handshake even if it could.

In order to tell JDBC to actually use TLSv1.2 you have to append it to the connection string:

jdbc:myslq://<host>/<db>?enabledTLSProtocols=TLSv1.2

Now everything connects.

I would have loved to make aurora deliver a longer key rather than lowering Ubuntu's security, but there seems to be no way. If anybody knows of one, please let me know.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.