configuring tls1.1 in erlang otp 22/23 or 24

I am needing to configure my erlang otp 22 to accept TLS1.0. I know it was discontinued due to security issues, but I need to test it with TLS1.0 on my notebook.

Could someone help me, because in the ERLANG manual it says that it was discontinued but I can configure it, but it does not say how to configure it.

thanks

1 Like

So I’m not seeing a configure option to enable that, so I think that’s just bad terminology being used on their changelog… Might be a way to enable/use it via :ssl_app perhaps?

1 Like

I’m more curious why you want TLS 1.0/1.1? Even 1.2 is ancient and supported by everything I’ve seen for a long long time now?

It’s looking like it’s just not default enabled, but you can enable it via the tls_version option type? From:
https://erlang.org/doc/man/ssl.html

 tls_version() = 'tlsv1.2' | 'tlsv1.3' | tls_legacy_version()
 tls_legacy_version() = tlsv1 | 'tlsv1.1'

Passed in to the options in the connect/listen/handshake and such calls I think?

1 Like

Hi

Two friends and I are developing an application and they decided to make a RADIUS AAA, but they had difficulties and started with TLS 1.0. So for my application to accept I need to change Erlang to work. As the documentation says it can be configured but doesn’t say how, I found it difficult to get TLS 1.0 to work. As the documentation says configure, I thought there was some configuration file in erlang where I could specify version 1.0. When I compile a test program with parameter TLSV1 or TLSV1.2 the error is executed. below the program code

-module(ssltest).

-compile(export_all).

-define(PORT, 11000).

server() →
application:load(ssl),
logger:set_application_level(ssl, debug),
{ok, _} = application:ensure_all_started(ssl),
Port = ?PORT,
LOpts = [{certfile, “server1.pem”},
{keyfile, “server.pub”},
{versions, [‘tlsv1’]},
{log_level, debug}
],
{ok, LSock} = ssl:listen(Port, LOpts),
{ok, CSock} = ssl:transport_accept(LSock),
{ok, _} = ssl:handshake(CSock).

client() →
application:load(ssl),
logger:set_application_level(ssl, debug),
{ok, _} = application:ensure_all_started(ssl),
Port = ?PORT,
COpts = [{verify, verify_peer},
{cacertfile, “server1.pem”},
{versions, [‘tlsv1’]},
{log_level, debug}
],
{ok, Sock} = ssl:connect(“localhost”, Port, COpts).

thanks

1 Like

sorry I missed TLSV1 and TLSV1.1, in the previous text in the compilation of the test program

1 Like

Cool, so does it work now? :slight_smile:

The LAB service is running and active, the idea is for the user-side application to make RADIUS calls with tlsv1.

When I type this parameter, the testssl.erl program works

erl -ssl protocol_version “[‘tlv1.3’,‘tlsv1.2’, ‘tlsv1.1’,‘tlsv1’]”

My big problem is that I can’t pass this parameter in lab.service, it always gives an error and doesn’t activate the service.

Below screen print of the systemctl status lab. I can’t in ExecStart configure the erlang daemon to accept -ssl protocol_version …

lab.service - “Labortorio Universidade Federal.”
Loaded: loaded (/lib/systemd/system/lab.service; enabled; vendor preset: e>
Active: active (running) since Fri 2021-06-04 15:35:17 UTC; 24h ago
Process: 71045 ExecStart=/usr/lib/erlang/bin/run_erl -daemon /run/lab/ log >
Tasks: 54 (limit: 486)
Memory: 54.8M
CGroup: /system.slice/lab.service
├─71047 /usr/lib/erlang/bin/run_erl -daemon /run/lab/ log ERL_LIBS>
├─71048 /usr/lib/erlang/erts-10.6.4/bin/beam.smp -K true -A 32 -Bi>
├─71092 erl_child_setup 1024
├─71119 sh -s disksup
├─71120 /usr/lib/erlang/lib/os_mon-2.5.1/priv/bin/memsup
└─71122 /usr/lib/erlang/lib/os_mon-2.5.1/priv/bin/cpu_sup

Is there any solution? Thanks.

1 Like

I’m not sure that’s where it would be passed in, but rather in the ssl setup calls I would think in the code?

[Hi

I also think like you, will have to change the code. They will have to change their version of TLS from 1.0 to 1.2.

I’ve already exhausted all possibilities to avoid changing the code, and I’ve always received failures in these attempts.

Thanks for your attention.quote=“OvermindDL1, post:10, topic:40240”]
I’m not sure that’s where it would be passed in, but rather in the ssl setup calls I would think in the code?
[/quote]