3

I am reviewing TLS configurations in my code, there are several places where there is TLS.

In these places, TLS version is hardcoded to TLSv1.2. I want to make sure that TLS 1.3 is also supported. To do so, which is better, to add tls 1.3 in the code? or to make this variable as a property that is configurable by a flag?

4
  • "Better" in order to accomplish what? Security? Backwards compatibility? Future-proofing? Ease of coding? Maintaining code? What do you want to accomplish and what bad thing do you want to avoid?
    – schroeder
    Commented yesterday
  • @schroeder better at different aspects, sercurity wise, compatibility wise, ease of coding wise.
    – anonymous
    Commented 22 hours ago
  • Then use configurable setting.
    – Crypt32
    Commented 18 hours ago
  • Then doesn't the question answer itself?
    – schroeder
    Commented 1 hour ago

3 Answers 3

3

It's always better to not use hardcoded values. Changing a property on a configuration file is trivial, changing a hardcoded value is not.

One could say that if you are supporting both TLS 1.2 and 1.3 there's nothing else left to configure. But if you have a reverse proxy, load balancer or IPS/IDS in place and there's an issue, being able to easily select protocols without recompiling makes troubleshooting easier.

2
  • 3
    "Changing a property on a configuration file is trivial, changing a hardcoded value is not." - depends on your deployment process. It might be easier to change the code and roll out a new version than to tell thousands of customers to change their configuration files.
    – Bergi
    Commented 11 hours ago
  • 1
    @Bergi Support both in config, default to the original. When you feel it's time to upgrade across the board, default to the new. Anyone who hasn't explicitly declared the version in their config will transit automatically; everyone who has presumably did so for a reason and will know what to change. Commented 2 hours ago
2

It depends, but using flag may be reasonable when your application works in various environments where newer protocols may not be available. Though a better approach would be to define "minimum supported version". For compatibility purposes you can define TLS 1.2 as minimum, but 1.3 is preferred when available. Or strictly define TLS 1.3 and newer for highly secure environments.

Hardcoded protocol version is useful to reduce potential misconfiguration, but will not support newer protocols without application re-compilation and application upgrade. It is important when you rely on OS-provided TLS stack (similar to SChannel in Microsoft Windows), where you configure TLS stack behavior depending on external availability.

0

If you have some specific TLS version hard-coded in several places, and if you need to change all those parts of the code whenever you want to adjust the version, that's clearly not a good approach. You make security-related updates unnecessarily annoying (especially if the application is used by other people), which increases the risk that they don't happen. And you may end up with inconsistencies where different components use different TLS versions and configurations for no good reason.

However, the problem is more about the several places and not the hard-coding. You should have an abstraction layer which hides TLS-related details. For example, if you want to make HTTPS requests, then there should be an abstract HTTPS client which takes care of the choosing the right TLS version and settings. This version can then be defined in a single place, be it as a constant in the code, a parameter in a configuration file or whatever seems sensible.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.