Age | Commit message (Collapse) | Author |
|
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.
|
|
* ia/ssl/remove-default-DES/OTP-13195:
ssl: Remove DES ciphers from default configuration
|
|
DES is not considered secure.
Also correct 'Server Name Indication' support description.
|
|
Previously, if certificate revocation checking was turned on, and a
certificate didn't contain a CRL Distribution Points extension, and
there was no relevant CRL in the cache, then ssl_handshake:crl_check
would accept the certificate even if the crl_check option was set to
reject certificates for which the revocation status could not be
determined. With this change, such certificates will only be accepted
if the crl_check option was set to best_effort.
The process for CRL validation is described in section 6.3 of RFC
5280. The text doesn't mention any special treatment to be given to
certificates without distribution points: it just says "For each
distribution point..." (section 6.3.3), which would leave the
revocation status undetermined, unless there were "any available CRLs
not specified in a distribution point but issued by the certificate
issuer". Thus the result of this algorithm should be UNDETERMINED in
this case, not UNREVOKED, and the crl_check option should govern how
the implementation reacts to this result.
|
|
When establishing a TLS connection with {verify, verify_none}, if the
server has a certificate with a critical extension, for example a
"Netscape Cert Type" extension, certificate verification would fail,
which is surprising given that the name of the option suggests that no
verification would be performed.
With this change, certificate extensions marked as critical are
ignored when using verify_none.
|
|
|
|
When searching for a certificate's issuer in the `CertDB`, verify the signature
against the original DER certificate from the handshake instead of a re-encoding
of the parsed certificate. This avoids false negatives due to differences
between DER encoding implementations of OTP and other platforms.
|
|
|
|
|