Ranch 1.7, issues upgrading a tcp to ssl/tls connection about ranch

[juhlig]

I'm not too good with Elixir I have to admit...

Neither am I, so this is a bit like donkeys discussing the best way to lay an egg (if that is a saying outside of Germany) ^^;;;

There is a test in the acceptor_SUITE for upgrading, ssl_upgrade_from_tcp, you may want to examine it and the ssl_upgrade_protocol it uses for reference.

The test case and associated protocol are entirely working in {active, false} mode, so there is no explicit setting the socket(s) to {active, false}, in case you're wondering.

gen_smtp uses ranch and does TCP-to-SSL upgrading, too, here (around line 703). It generally puts the socket in {active, once} mode when it expects a command from the client, and the client does the same whenever it expects a response from the server, so after receiving a command or response, their sockets are automatically put in {active, false} mode.

• client and server use a plain TCP connection, server has it's active set to once, client has it's active set to false
• client sends STARTTLS and sets it's active to once
• server receives STARTTLS (it's active goes to false), sends 220 OK and does not set it's active back to once (!) but calls ranch_ssl:handshake
• client receives 220 OK (it's active goes to false), and calls ssl:handshake
• when the handshake has been performed, the server sets it's active to once again so it can receive commands from the client on the upgraded socket

[Maria-12648430]

I'm not too good with Elixir I have to admit... but I'll try ;) Are you having problems during the upgrade (handshake), or afterwards? Because I think you may just have to update the transport in your state from ranch_tcp to ranch_ssl (it is not a plain TCP connection any more then, it is SSL) after the upgrade, which I can't see in your file.

[Teifion]

The two main differences for this bit to help:

• Variables are lowercase instead of Uppercase for the first letter
• Atoms are a colon and a word instead of just lowercase

I believe it's during it. The result of the code flow is I get (in erlang terms) {error, timeout}. The case statement is expecting {ok, NewSocket} and doesn't get it hence my assumption of during the handshake. The setting the socket to be active happens after the handshake finishes (in this case, it doesn't happen).

[Maria-12648430]

• Variables are lowercase instead of Uppercase for the first letter
• Atoms are a colon and a word instead of just lowercase

I know ;) And if that was all there was to it... j/k, to business ;)

I believe it's during it. The result of the code flow is I get (in erlang terms) {error, timeout}. The case statement is expecting {ok, NewSocket} and doesn't get it hence my assumption of during the handshake. The setting the socket to be active happens after the handshake finishes (in this case, it doesn't happen).

Hm in that case it may be that the client is not performing his side of the upgrade properly? I also believe that the client socket has to be in {active, false} mode before attempting his side of the upgrade, otherwise the SSL handshake packet from the server will be "eaten" (same reason why you have to do that on the server side), so maybe that is it?

In any case, ranch_ssl:handshake/3 is more or less just a wrapper around ssl:ssl_accept/3 in ranch 1.7, or ssl:handshake/3 in ranch 2.x (btw, ssl:ssl_accept/3 is removed in OTP/24, so ranch 1.7 will not work with it, see #314). There is no ranch-magic happening.

There is a test in the acceptor_SUITE for upgrading, ssl_upgrade_from_tcp, you may want to examine it and the ssl_upgrade_protocol it uses for reference.

[Teifion]

The client application already has this functionality in place and to my understanding works correctly.

Thank you for your response, I think it'll point me in the right direction. In particular the test suite. I'll post here if I have further issues and post + close if I resolve it :)

[Teifion]

Thank you both for your help (and the new saying, that is quite honestly fantastic).

The issue was I upgrading the connection and subsequently not changing the socket and transport held by the state, thus it was trying to interact with a ranch_tcp rather than ranch_ssl.

I'm completely happy for you to mark this issue as resolved if you want to.

[essen]

Cheers.