| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We want to avoid failing test cases but still be able to merge
DTLS progress for 19.3
|
|
The new_options_in_accept test is not working yet, however DTLS is still
work in progress and we want to make a progress merge to avoid merge conflicts
with other progress of the ssl application.
|
|
|
|
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 .
|
|
The PEM cache handling has proven to be too disruptive of the manager process.
|
|
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.
|
|
ECC certs should preferably use SHA2, this is what we want to be
testing. Also assembling of all available test suites must consider TLS version.
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
|
|
Test suite did not take TLS-version in to account. Also
some anonymous suites where included incorrectly in some TLS versions.
|
|
|
|
|
|
init_per_testcase timeout for renegotiation tests would be overridden
by local timeout in test case help function.
|
|
Skip some test on really slow solaris machines
|
|
Tests in ECC_SUITE did not always use the certs implied by the
name. Variable naming also confused the intent.
ssl_certificate_verify_SUITE did not clean up properly and tests could
fail due to cache problems.
|
|
* ingela/ssl/ssl_basic_SUITE-timeouts:
ssl: Tune timeouts
|
|
These functions call getstat on the underlying TCP socket.
The only way to do this before now was to use a hack, either
by looking inside the #sslsocket{} record directly, or by
not using the SSL listen/accept functions and upgrading
from a TCP socket that is kept around for the purpose of
calling getstat later on.
|
|
|
|
ssl servers can recognize sslv2 client hellos to interop with clients
that support higher version of SSL/TLS but also offers sslv2
Conflicts:
lib/ssl/src/tls_connection.erl
|
|
|
|
gen_tcp:recv allows this, and if you're doing something like
Transport:recv(Socket, 0, 0), TCP will work and SSL will exit with
function_clause
There were other cases of this throughout the module. This PR cleans
them all up.
|
|
There are a lot of cases where `ssl` application just returns unhelpful
`handshake failure` or `internal error`. This patch tries to provide
better diagnostics so operator can debug his SSL misconfiguration
without doing hardcore erlang debugging.
Here is an example escript that incorrectly uses server certificate as a
client one:
https://gist.github.com/binarin/35c34c2df7556bf04c8a878682ef3d67
With the patch it is properly reported as an error in "extended key
usage".
|
|
|
|
Some legacy TLS 1.0 software does not tolerate the 1/n-1 content
split BEAST mitigation technique. This commit adds a beast_mitigation
SSL option (defaulting to one_n_minus_one) to select or disable the
BEAST mitigation technique.
Valid option values are (one_n_minus_one | zero_n | disabled).
|
|
|
|
We are working on including DTLS support. And we want to include
the contributed tests now before making planned enhancements to the
test suits.
|
|
Consolidate code that logs TLS/DTLS version during testing
into ssl_test_lib.
|
|
|
|
Use the negotiated cipher suite's PRF algorithm in calls to
ssl:prf/5, rather than a hard-coded one.
For TLS 1.0 the PRF algorithm was hard-coded to MD5/SHA1. This
was correct 100% of the time.
For TLS 1.1 and 1.2 the PRF algorithm was hard-coded to SHA256.
This was correct only some of the time for TLS 1.2 and none of the
time for TLS 1.1. Because the TLS handshake code calls tls_v1:prf/5
through another path, the handshaking process used the negotiated
PRF and did not encounter this bug.
A new test (prf) has been added to ssl_basic_SUITE to guard against future
breakage.
|
|
Also reduce timing issues in tests
|
|
Correct conversion errors form commit d2381e1a8d7cd54f7dc0a5105d172460b005a8fb
|
|
It was not possible to mix ssl 3 and 4 tuple cipher suites in the
ciphers option.
Some ssl_cipher:suite/1 clauses wrongly returned 3-tuples that
should have been 4 tuples
Conflicts:
lib/ssl/test/ssl_basic_SUITE.erl
|
|
ssl already used crypto:strong_rand_bytes/1 for most operations as
its use cases are mostly cryptographical. Now crypto:strong_rand_bytes/1
will be used everywhere.
However crypto:rand_bytes/1 was used as fallback if
crypto:strong_rand_bytes/1 throws low_entropy, this
will no longer be the case. This is a potential incompatibility.
The fallback was introduced a long time ago for interoperability reasons.
Now days this should not be a problem, and if it is, the security
compromise is not acceptable anyway.
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
In TLS-1.2 The signature algorithm and the hash function algorithm
used to produce the digest that is used when creating the digital signature
may be negotiated through the signature algorithm extension RFC 5246.
We want to make these algorithm pairs configurable.
In connections using lower versions of TLS these algorithms are
implicit defined and can not be negotiated or configured.
DTLS is updated to not cause dialyzer errors, but needs to get a real
implementation later.
|
|
|
|
|
|
|
|
Older SSL/TLS versions have cipher suites
that look like {key_exchange(), cipher(), MAC::hash()}
and the hash function used by the PRF (Pseudo Random function)
is implicit and always the same for that protocol version.
In TLS 1.2 a cipher suite is
{key_exchange(), cipher(), MAC::hash(), PRF::hash()}.
Internally a cipher suite is always a four tuple but
for backwards compatibility older cipher suites
will be presented as a three tuples, however new cipher suites
should be presented as four tuples.
|
|
Make sure that options only relevant for one role (client|server) is set
to undefined when the other role is invoked. As there are many options to
ssl, and many are optional, we choose to filter out all undefined options
to avoid overwhelming the user with not relevant information.
This way there is no need for any special handling of the role specific options
which is also nice.
|
|
DES is not considered secure.
Also correct 'Server Name Indication' support description.
|
|
|
|
* rlipscombe/rl-ssl-options:
Ensure single 'raw' option is handled correctly
Pass 'raw' options through
OTP-13166
|
|
Add a test to ensure that a single 'raw' option can be passed to
ssl:listen correctly.
Note: multiple raw options are (incorrectly) handled by
inet:listen_options. See
http://erlang.org/pipermail/erlang-questions/2014-March/078371.html
|
|
Needed after the fix in 120975c4fcb57ecd14031ac046f483e56a3daa4d.
|
|
|
|
Add possibility to downgrade an SSL/TLS connection to a tcp connection,
and give back the socket control to a user process.
Add application setting to be able to change fatal alert shutdown
timeout, also shorten the default timeout. The fatal alert timeout is
the number of milliseconds between sending of a fatal alert and
closing the connection. Waiting a little while improves the
peers chances to properly receiving the alert so it may
shutdown gracefully.
|
