| Age | Commit message (Collapse) | Author |
|---|
|
|
|
state can not be determined
|
|
|
|
When the server_name_indication is sent automatize the
clients check of that the hostname is present in the
servers certificate. Currently server_name_indication shall
be on the dns_id format. If server_name_indication is disabled
it is up to the user to do its own check in the verify_fun.
|
|
|
|
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.
|
|
for the CRL
|
|
|
|
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.
|
|
* ferd/bypass-pem-cache/PR-1143/OTP-13883:
ssl: Add documentation of bypass_pem_cache application environment configuration
ssl: Add new benchmarks to skip file for normal testing
Adding PEM cache bypass benchmark entries
Fixing CRL searching in cache bypass
Add option to bypass SSL PEM cache
|
|
|
|
ssl_handshake:update_handshake_history
This proably a much bigger problem for DTLS than TLS, but should be
disabled for both unless explicitly configured for TLS.
|
|
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
The current SSL implementation has a PEM cache running through the ssl
manager process, whose primary role is caching CA chains from files on
disk. This is intended as a way to save on disk operation when the
requested certificates are often the same, and those cache values are
both time-bound and reference-counted. The code path also includes
caching the Erlang-formatted certificate as decoded by the public_key
application
The same code path is used for DER-encoded certificates, which are
passed in memory and do not require file access. These certificates are
cached, but not reference-counted and also not shared across
connections.
For heavy usage of DER-encoded certificates, the PEM cache becomes a
central bottleneck for a server, forcing the decoding of every one of
them individually through a single critical process. It is also not
clear if the cache remains useful for disk certificates in all cases.
This commit adds a configuration variable for the ssl application
(bypass_pem_cache = true | false) which allows to open files and decode
certificates in the calling connection process rather than the manager.
When this action takes place, the operations to cache and return data
are replaced to strictly return data.
To provide a transparent behaviour, the 'CacheDbRef' used to keep track
of the certificates in the cache is replaced by the certificates itself,
and all further lookup functions or folds can be done locally.
This has proven under benchmark to more than triple the performance of
the SSL application under load (once the session cache had also been
disabled).
|
|
|
|
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/vsn.mk
lib/common_test/doc/src/notes.xml
lib/common_test/vsn.mk
lib/ssl/doc/src/notes.xml
lib/ssl/src/ssl.appup.src
lib/ssl/vsn.mk
lib/stdlib/test/ets_SUITE.erl
otp_versions.table
|
|
Use the list of versions that the server allows and among those choose
the highest version that is not higher than the client's version.
Note that this chosen version might be lower than the client's version,
but is used to improve interoperability.
Patch suggested by Dimitry Borisov refering to RFC 5246 appendix E.1.
|
|
In TLS-1.2 the selection of the servers algorithms and the the
possible selection of algorithms for the client certificate verify
message have different requirements.
|
|
* ingela/ssl/dtls-next-step-flights/OTP-13678:
dtls: Avoid dialyzer errors
dtls: add implementation for msg sequence
dtls: Remove TODO
dtls: sync dtls_record DTLS version and crypto handling with TLS
dtls: handle Hello and HelloVerify's in dtls_handshake
dtls: rework/simplify DTLS fragment decoder
dtls: add support first packet and HelloVerifyRequest
dtls: sync handle_info for connection close with TLS
dtls: sync handling of ClientHello with TLS
dtls: rework handshake flight encodeing
dtls: implement next_tls_record
dtls: sync init and initial_state with tls_connection
dtls: update start_fsm for new ssl_connection API
ssl: introduce the notion of flights for dtls and tls
ssl: move available_signature_algs to ssl_handshake
|
|
* legoscia/ssl_crl_hash_dir-bis/PR-982/OTP-13530:
Skip crl_hash_dir_expired test for LibreSSL
Add ssl_crl_hash_dir module
Function for generating OpenSSL-style name hashes
Add public_key:pkix_match_dist_point
Improve formatting for crl_{check,cache} options
Add issuer arg to ssl_crl_cache_api lookup callback
Conflicts:
lib/public_key/test/public_key_SUITE.erl
|
|
available_signature_algs is also needed for DTLS, move it
into a shared place and export it.
Conflicts:
lib/ssl/src/tls_handshake.erl
|
|
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.
|
|
We do not want error reports that can leek secret information
into the logs.
|
|
|
|
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".
|
|
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.
|
|
* 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.
|
|
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.
|
|
|
|
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.
|
|
|
|
Conflicts:
OTP_VERSION
lib/inets/test/httpd_SUITE.erl
lib/inets/vsn.mk
lib/ssh/src/ssh.erl
lib/ssh/vsn.mk
lib/ssl/src/ssl.appup.src
lib/ssl/vsn.mk
|
|
alert records needs to be thrown from
ssl_handshake:premaster_secret/[2/3] so that operations will end up in
the catch clause of the invokation of certify_client_key_exchange/3 in
ssl_connection.erl, and hence terminate gracefully and not continue to try
and calculate the master secret with invalid inputs and crash.
|
|
pre TLS 1.2 server should ignore the signature_algorithms extension.
The server code would attempt to select the signature/hash algorithm
even when using TLS 1.0 or 1.1. Instead it should simply use the default
algorithm on those versions.
|
|
|
|
This commit adds support for RFC7301, application-layer protocol
negotiation. ALPN is the standard based approach to the NPN
extension, and is required for HTTP/2.
ALPN lives side by side with NPN and provides an equivalent
feature but in this case it is the server that decides what
protocol to use, not the client.
When both ALPN and NPN are sent by a client, and the server is
configured with both ALPN and NPN options, ALPN will always
take precedence. This behavior can also be found in the OpenSSL
implementation of ALPN.
ALPN and NPN share the ssl:negotiated_protocol/1 function for
retrieving the negotiated protocol. The previously existing
function ssl:negotiated_next_protocol/1 still exists, but has
been deprecated and removed from the documentation.
The tests against OpenSSL require OpenSSL version 1.0.2+.
|
|
|
|
|
|
|
|
|
|
|
|
Check that the certificate chain ends with a trusted ROOT CA e.i. a
self-signed certificate, but provide an option partial_chain to
enable the application to define an intermediat CA as trusted.
TLS RFC says:
"unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This
message is always fatal."
and also states:
"certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case."
X509 RFC says:
"The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI. The path
validation procedure is the same regardless of the choice of trust
anchor. In addition, different applications may rely on different
trust anchors, or may accept paths that begin with any of a set of
trust anchors."
|
|
|
|
|
|
|
|
FROM TLS 1.2 RFC:
The interaction of the certificate_types and
supported_signature_algorithms fields is somewhat complicated.
certificate_types has been present in TLS since SSLv3, but was
somewhat underspecified. Much of its functionality is superseded by
supported_signature_algorithms. The following rules apply:
- Any certificates provided by the client MUST be signed using a
hash/signature algorithm pair found in
supported_signature_algorithms.
- The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_algorithms.
- For historical reasons, the names of some client certificate types
include the algorithm used to sign the certificate. For example,
in earlier versions of TLS, rsa_fixed_dh meant a certificate
signed with RSA and containing a static DH key. In TLS 1.2, this
functionality has been obsoleted by the
supported_signature_algorithms, and the certificate type no longer
restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA-
SHA1.
|
|
|
|
Also fix DTLS call to supply its corresponding TLS version
|
