| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
The link should be between the connection process and the tls_sender
process. But the start of the tls_sender process needs to be done
by the process that also starts the connection process in order to
correctly create the opaque #ssl_socket{}.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/ssl/src/tls_connection.erl
|
|
ERL-539
|
|
* origin/raimo/ssl-dist-bench/OTP-14657:
Write SSL distribution benchmarks
Polish SSL distribution
Handle whitebox test message
Correct distribution doc
Use SNI when connecting
Use -ssl_dist_optfile options
Read in -ssl_dist_optfile to ETS
Facilitate test certs with common root
Stop checking DNS name for SNI
|
|
|
|
|
|
* ingela/ssl/ERL-521/OTP-14794:
ssl: Make sure all possible data is delivered
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
|
|
|
|
Also make tls code a little more direct for easier uderstanding
|
|
This code is only relevant in version is was written in.
|
|
|
|
Conflicts:
OTP_VERSION
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
public_key: verify ip (both v4 and v6)
public_key: Added IP4 address checks to hostname_verification tests
ssl: Fix test cases to work on all test platforms
public_key: Fix dialyzer spec
ssl: Sessions must be registered with SNI if exists
ssl: Extend hostname check to fallback to checking IP-address
public_key, ssl: Handles keys so that APIs are preserved correctly
ssl: Use ?FUNCTION_NAME
ssl: Prepare for release
ssl: Countermeasurements for Bleichenbacher attack
Conflicts:
lib/public_key/doc/src/public_key.xml
lib/public_key/test/public_key_SUITE.erl
lib/public_key/test/public_key_SUITE_data/pkix_verify_hostname_subjAltName_IP.pem
lib/public_key/test/public_key_SUITE_data/verify_hostname_ip.conf
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
|
|
'ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766' into maint-20
* ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766:
ssl: Fix test cases to work on all test platforms
public_key: Fix dialyzer spec
ssl: Sessions must be registered with SNI if exists
ssl: Extend hostname check to fallback to checking IP-address
public_key, ssl: Handles keys so that APIs are preserved correctly
ssl: Use ?FUNCTION_NAME
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
lib/ssl/src/tls_connection.erl
|
|
|
|
Use ?FUNCTION_NAME macro to enhance code as we will not back-port this
version of the ssl application to versions pre OTP 19.
|
|
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
|
|
Use ?FUNCTION_NAME macro to enhance code as we will not back-port this
version of the ssl application to versions pre OTP 19.
|
|
|
|
|
|
|
|
|
|
|
|
This is taken from
https://github.com/erlang/otp/pull/1479#issuecomment-304667528 with
permission from Ingela Andin and improves commit 8abe16c22d.
|
|
The commit 8b10920 (OTP 19.3.1) fixed the non-delivery of final TLS
record in {active, once}, but this causes the ssl_closed message to be
lost when the TCP connection closes before ssl:close/1. The patch
restores the behavior of OTP 18.
This is the second part to fix https://bugs.erlang.org/browse/ERL-420
|
|
|
|
|
|
Note this is a change form how it works for earlier versions that will
send the first hello message on the lowest supported version.
From RFC 5246
Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server.
A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is
willing to use) only versions greater than client_version, it MUST
send a "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
|
|
Conflicts:
OTP_VERSION
erts/vsn.mk
lib/crypto/c_src/crypto.c
lib/crypto/src/crypto.erl
lib/ssh/src/ssh.erl
|
|
Emulate active once in such a way that data recived by the TLS
connection process, but not fetch via active once option
by the user, can be delivered at next active once before final close.
|
|
|
|
Change retransmissions timers to use gen_statem state timeouts. We do
not need a retransmission timer in the state connection as data traffic in
DTLS over UDP is not retransmitted. If the last flight before
transitioning into connection is lost, it will be resent when the peer
resends its last flight. This will also make hibernation testing more
straight forward.
We need more adjustments later to handle a reliable DTLS transport
such as SCTP.
|
|
DTLS does not support stream ciphers and needs diffrent
handling of the "#ssl_socket{}" handle .
|
|
If a handshake message is really big it could happen that the ssl
process would hang due to failing of requesting more data from the
socket. This has been fixed.
Also added option to limit max handshake size. It has a default
value that should be big enough to handle normal usage and small
enough to mitigate DoS attacks.
|
|
Beta DTLS, not production ready. Only very basically tested, and
not everything in the SPEC is implemented and some things
are hard coded that should not be, so this implementation can not be consider
secure.
Refactor "TLS connection state" and socket handling, to facilitate
DTLS implementation.
Create dtls "listner" (multiplexor) process that spawns
DTLS connection process handlers.
Handle DTLS fragmentation.
Framework for handling retransmissions.
Replay Detection is not implemented yet.
Alerts currently always handled as in TLS.
|
|
* ingela/ssl/ECC-selection-fix/OTP-13918:
ssl: Correct ECC curve selection, the error could cause default to always be selected.
|
