| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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".
|
|
* kennethlakin/beast-mitigation-options/PR-1041/OTP-13629:
ssl: Add BEAST mitigation selection option
|
|
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).
|
|
If the -epmd_module flag has been specified on the command line, use
that module to register and look up node names instead of the default,
erl_epmd.
Also document this option.
|
|
|
|
|
|
|
|
Turns out we can not count on the "hashsigns" sent by the client and
the supported "hashigns" sets to have required properties of ordsets.
|
|
* kennethlakin/tls-use-negotiated-prf/PR-1042/OTP-13546:
ssl: Use cipher suite's PRF in prf/5
|
|
|
|
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.
|
|
DTLS is not in working mode yet, but the gen_statem rewrite should make
completion easier.
|
|
Also reduce timing issues in tests
|
|
* ingela/ssl-max-session-table/OTP-13490:
ssl: Adjust max table to work as expected from documentation
|
|
* ingela/ssl/signature_algs_bug:
ssl: Correct guard expression
|
|
* ingela/ssl/cipher_suites:
ssl: Correct cipher suites conversion
|
|
The guard should check that the TLS version is at least TLS-1.2.
|
|
Correct conversion errors form commit d2381e1a8d7cd54f7dc0a5105d172460b005a8fb
Please enter the commit message for your changes. Lines starting
|
|
The guard should check that the TLS version is at least TLS-1.2.
|
|
Correct conversion errors form commit d2381e1a8d7cd54f7dc0a5105d172460b005a8fb
|
|
Conflicts:
OTP_VERSION
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/tls_v1.erl
lib/ssl/test/ssl_basic_SUITE.erl
|
|
* ingela/ssl/config-signature-algs/OTP-13261:
ssl: Prepare for release
ssl: Add option signature_algs
|
|
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.
|
|
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
|
|
The session table max size should be the configurable value Max and
not Max + 1.
|
|
* 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.
|
|
|
|
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.
|
|
This module is an implementation of the ssl_crl_cache_api behaviour.
It can be used when there is a directory containing CRLs for all
relevant CAs, in the form used by e.g. Apache. The module assumes
that the directory is being updated through an external process.
|
|
Change the ssl_crl_cache_api callback specification, passing the
certificate issuer name as an argument to the lookup callback
function. Support the previous API too, for the time being.
The purpose of this change is to accomodate CRL cache modules that
index CRLs by issuer name, not by distribution point URL.
While in most cases such lookups could be performed using the select/2
callback function, that doesn't work when the CRL in question contains
an Issuing Distribution Point (IDP) extension, since RFC 5280
specifies different processing rules for CRLs specified in a
distribution point (DP) and other CRLs. For the latter, a DP is
assumed that most likely will not match the IDP of the CRL.
In order to accommodate cache modules that index CRLs by issuer name,
let's pass them the issuer as well.
|
|
In ssl_tls_dist_proxy:accept_loop/3, handle {error, closed} by
exiting normally. This prevents a spurious error report at node
shutdown.
|
|
Allow specifying the crl_check and crl_cache options for TLS
distribution connections.
|
|
Accept a value of the form {Module, Function, State} from the command
line. This is different from the {Fun, State} that ssl:connect etc
expect, since there's no clean way to parse a fun from a command line
argument.
|
|
|
|
|
|
|
|
* legoscia/tls_ipv6_dist:
Add inet6_tls_dist, for TLS distribution over IPv6
Conflicts:
lib/ssl/src/ssl_tls_dist_proxy.erl
OTP-13391
|
|
|
|
* legoscia/fix-ssl-example/PR-976/OTP-13363:
ssl: Modernize utility function
Fix ssl example
|
|
|
|
* legoscia/crl-check-without-dp:
Be suspicious of certificates without CRL DPs
Refactor ssl_crl_SUITE: extract crl_verify_error/6
OTP-13378
|
|
* legoscia/critical-extension-verify-none:
ssl: with verify_none, accept critical extensions
OTP-13377
|
|
Use application:ensure_all_started/2 instead of hard coding dependencies
|
|
|
|
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.
|
