Age | Commit message (Collapse) | Author |
|
|
|
|
|
Conflicts:
lib/ssl/src/tls_connection.erl
|
|
Wtite connection state was not synchronized when peer initiated renegotiation
|
|
Conflicts:
lib/ssl/src/ssl_connection.hrl
lib/ssl/src/tls_connection.erl
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_connection.hrl
lib/ssl/src/tls_connection.erl
lib/ssl/src/tls_record.erl
|
|
|
|
As the stop wrapper functions are no longer needed after tls_sender
that altered the behaviour of the TLS distribution code.
|
|
Both test case and code needed updates to work as intended. Code needed update due to
new tls_sender process and the test case gave false positive reusult erarlier probably
due to beeing to sloopy in order to avoid timeouts.
|
|
|
|
Rename Connection:handle_common_event Connection:handle_protocol_record
removing use of unnecessary argument and making code easier to understand.
|
|
State values created at init
|
|
Conflicts:
lib/ssl/test/ssl_dist_bench_SUITE.erl
|
|
* raimo/ssl/tls_dist-optimization:
Handle socket close in state downgrade
Handle dead sender at terminate
Handle tls_sender exit properly
Optimize split_bin
Improve dist send throughput
|
|
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/tls_connection.erl
|
|
Also avoid code duplication
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/tls_connection.erl
|
|
When internaly using active N, bugs in shutdown implementation where reveled.
|
|
Make next_record an internal help function to next_event and avoid
duplicate calls to tls_socket:setopts for setting the active option.
|
|
|
|
|
|
with handshake
Fix of commit 68d9244ae33e5eea36250c3bb9ffe046a4db5647
|
|
|
|
other purposes than handshaking
|
|
Implement Signature Algorithms (TLS 1.3)
|
|
Implement handling of the signature algorithms extension described by
RFC 8446. This commit updates the behavior of legacy TLS versions to
align them with RFC 8446 (TLS 1.3) and RFC 5246 (TLS 1.2).
- TLS 1.0/1.1 clients validate the client certificate against the
certificate_type field of the CertificateRequest message.
- TLS 1.2 client verifies the hash/signature algorithm pair of the
client certificate when processing a CertificateRequest. Old
behavior only checked the signature algorithms.
- TLS 1.2 server verifies that the server certificate is signed by
a hash/signature algorithm pair that appears in the
"singature_algorithms" or "signature_algorithms_cert" (RFC 8446)
extensions of the ClientHello.
Change-Id: I3e0a0d7408984f5e5b1233968934fe34d64eb2b7
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
lib/ssl/src/tls_connection.erl
|
|
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.
|
|
As TLS 1.3 introduces more extensions in other places than in hello messages
we like to have generalize extension handling encode/decode with some
hello wrappers.
Also extend property tests of handshake encod/decode
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
lib/ssl/src/tls_connection.erl
|
|
* ingela/ssl/send-recv-dead-lock/ERL-622:
ssl: Improve close handling
ssl: Adopt distribution over TLS to use new sender process
ssl: Add new sender process for TLS state machine
|
|
* maint:
ssl: Fix dialyzer errors detected when crypto.erl is typed
|
|
We want to make sure that the sender process that may get stuck in
prim_inet:send will die if the tls_connection process is
terminated. And we also like to make sure that it terminates as
gracefully as possible. So when the tls_connection process dies it
spawns a killer process that will brutaly kill the sender if it is
unresponsive and does not terminate due to its monitor of the
tls_connetion process triggering.
When the sender process also acts as distribution controller it
may also have other processess that it is linked with that it
should bring down or that could bring the connection down.
|
|
|
|
Separate sending and receiving when using TCP as transport
as prim_inet:send may block which in turn may result
in a deadlock between two Erlang processes communicating over
TLS, this is especially likely to happen when running Erlang distribution
over TLS.
|
|
|
|
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
The conversion code for different representations of cipher suites
is long an repetitive. We want to hide it in a module that does not
have other functions that we like to look at.
|
|
|
|
Transport accepted sockets that are in the error state, was not closed
properly.
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes
of their Random value to the bytes:
44 4F 57 4E 47 52 44 01
If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2
servers SHOULD set the last eight bytes of their Random value to the
bytes:
44 4F 57 4E 47 52 44 00
Change-Id: If35112f63f42a9af351f4ca9b1846fd3f5b08167
|
|
|
|
IngelaAndin/ingela/ssl/unexpected-call/ERL-664/OTP-15174
ssl: Improve error handling
|
|
When doing ssl:controlling_process on a ssl socket that has not
performed the TLS/DTLS handshake that call will succeed even though
the documentation stated otherwise. However if some other ssl option
was incorrect the call would hang. Now {error, closed} will be
returned in the latter case, which is logical independent on if it
should succeed or not in the former case. The former case will continue
to succeed, as it is not dependent of the TLS/DTLS connection being
established, and the documentation is altered slightly to not
explicitly disallow it. If the TLS/DTLS connection later fails and
the socket mode is active, the new controlling process will be
notified as expected.
|
|
|
|
|
|
|
|
|
|
|