aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/tls_sender.erl
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2018-10-04 08:14:37 +0200
committerIngela Anderton Andin <[email protected]>2018-10-10 10:28:59 +0200
commita210b0ed49f026919eea9fcef50f140a037b0982 (patch)
tree7b7c4adffba04152437d5906aed46a5153448e76 /lib/ssl/src/tls_sender.erl
parent377f19f25aeec6939a6728bd0c4910086c22ccdc (diff)
downloadotp-a210b0ed49f026919eea9fcef50f140a037b0982.tar.gz
otp-a210b0ed49f026919eea9fcef50f140a037b0982.tar.bz2
otp-a210b0ed49f026919eea9fcef50f140a037b0982.zip
ssl: ERL-738 - Correct alert handling with new TLS sender process
With the new TLS sender process, solving ERL-622, TLS ALERTs sent in the connection state must be encrypted and sent by the TLS sender process. This to make sure that the correct encryption state is used to encode the ALERTS. Care must also be taken to ensure a graceful close down behavior both for normal shutdown and downgrading from TLS to TCP. The original TR ERL-738 is verified by cowboy tests, and close down behavior by our tests. However we alas have not been able to yet create a minimal test case for the originating problem. Also it seems it has become less likely that we run in to the TCP delivery problem, that is the guarantee is only on transport level, not application level. Keep work around function in ssl_test_lib but we can have better test as long as we do not get to much wobbling tests.
Diffstat (limited to 'lib/ssl/src/tls_sender.erl')
-rw-r--r--lib/ssl/src/tls_sender.erl17
1 files changed, 15 insertions, 2 deletions
diff --git a/lib/ssl/src/tls_sender.erl b/lib/ssl/src/tls_sender.erl
index db67d7ddff..ec03000b33 100644
--- a/lib/ssl/src/tls_sender.erl
+++ b/lib/ssl/src/tls_sender.erl
@@ -28,7 +28,8 @@
-include("ssl_api.hrl").
%% API
--export([start/0, start/1, initialize/2, send_data/2, send_alert/2, renegotiate/1,
+-export([start/0, start/1, initialize/2, send_data/2, send_alert/2,
+ send_and_ack_alert/2, renegotiate/1,
update_connection_state/3, dist_tls_socket/1, dist_handshake_complete/3]).
%% gen_statem callbacks
@@ -89,13 +90,21 @@ send_data(Pid, AppData) ->
%%--------------------------------------------------------------------
-spec send_alert(pid(), #alert{}) -> _.
-%% Description: TLS connection process wants to end an Alert
+%% Description: TLS connection process wants to send an Alert
%% in the connection state.
%%--------------------------------------------------------------------
send_alert(Pid, Alert) ->
gen_statem:cast(Pid, Alert).
%%--------------------------------------------------------------------
+-spec send_and_ack_alert(pid(), #alert{}) -> ok.
+%% Description: TLS connection process wants to send an Alert
+%% in the connection state and recive an ack.
+%%--------------------------------------------------------------------
+send_and_ack_alert(Pid, Alert) ->
+ gen_statem:cast(Pid, {ack_alert, Alert}).
+
+%%--------------------------------------------------------------------
-spec renegotiate(pid()) -> {ok, WriteState::map()} | {error, closed}.
%% Description: So TLS connection process can synchronize the
%% encryption state to be used when handshaking.
@@ -207,6 +216,10 @@ connection({call, From}, {dist_handshake_complete, _Node, DHandle}, #data{connec
process_flag(priority, normal),
Events = dist_data_events(DHandle, []),
{next_state, ?FUNCTION_NAME, StateData#data{dist_handle = DHandle}, [{reply, From, ok} | Events]};
+connection(cast, {ack_alert, #alert{} = Alert}, #data{connection_pid = Pid} =StateData0) ->
+ StateData = send_tls_alert(Alert, StateData0),
+ Pid ! {self(), ack_alert},
+ {next_state, ?FUNCTION_NAME, StateData};
connection(cast, #alert{} = Alert, StateData0) ->
StateData = send_tls_alert(Alert, StateData0),
{next_state, ?FUNCTION_NAME, StateData};