| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If the peer sends an incomplete chain that we can reconstruct with
our known CA-certs it will be accepted.
We will assume that the peer honors the protocol and sends an orded
chain, however if validation fails we will try to order the chain in
case it was unorded. Will also handle that extraneous cert where present.
See Note form RFC 8446
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
|
|
|
|
If no SNI is available and the hostname is an IP-address also check
for IP-address match. This check is not as good as a DNS hostname check
and certificates using IP-address are not recommended.
|
|
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.
|
|
|
|
Changes made to ssl_certificate:validate appear to be preventing CRL
validation from happening when an id-ce-extKeyUsage extension is
present in the cert before the DistributionPoint extension.
https://github.com/erlang/otp/blob/448e8aca77dd29ed5b37d56f0700d24ac26a7243/lib/ssl/src/ssl_certificate.erl#L131
See also ERL-338 and PR-1302
|
|
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).
|
|
|
|
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.
|
|
|
|
|
|
|
|
A selfsigned trusted anchor should not be in the certifcate chain passed to
the certificate path validation.
Conflicts:
lib/ssl/src/ssl_certificate.erl
|
|
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."
|
|
When dealing with older certificates that does not indicate its signer
with a certificate extension, we must search the database for the issure.
Finding the issuer is not enough, we need to verify the signature
with the key in the found issuer cert.
|
|
Conflicts:
lib/ssl/src/ssl.app.src
lib/ssl/src/ssl_manager.erl
|
|
|
|
Some certificates may use these OIDs instead of the ones defined by
PKIX/PKCS standard.
Refactor code so that all handling of the "duplicate" oids is done by
public_key.
Update algorithm information in documentation.
|
|
|
|
|
|
|
|
ets:next needs an explicit safe_fixtable call to be safe, we
rather use ets:foldl and throw to get out of it when we find the
correct entry.
|
|
We want the certificate table to be handled the same way as the
session table and not have a global name, so that we may easier
create a separate ssl-manager to handle erlang distribution over ssl.
|
|
Data to sign and verify should be inputed as binaries.
Also cleaned up and moved some dialyzer specs.
|
|
Conflicts:
lib/public_key/src/pubkey_cert.erl
|
|
maint-r14
* ia/ssl-and-public_key/verify_fun_peer_awarness/OTP-8873:
Peer awarness
|
|
Changed the verify fun so that it differentiate between the peer
certificate and CA certificates by using valid_peer or valid as the
second argument to the verify fun. It may not always be trivial or
even possible to know when the peer certificate is reached otherwise.
|
|
* ia/ssl-and-public_key/backwards-compatibility/OTP-8858:
Backwards compatibility
Conflicts:
lib/ssl/src/ssl_certificate_db.erl
Use short INFO-message. Debugging information can be fairly
easily recreated so we do not want to clutter the logs.
|
|
Changed implementation to retain backwards compatibility for old
option {verify, 0} that shall be equivalent to {verify, verify_none},
also separate the cases unknown CA and selfsigned peer cert, and
restored return value of deprecated function public_key:pem_to_der/1.
|
|
|
|
Added the functionality so that the verification fun will be called
when a certificate is considered valid by the path validation to allow
access to eachs certificate in the path to the user application.
Removed clause that only check that a extension is not critical,
it does alter the verification rusult only withholds information from
the application.
Try to verify subject-AltName, if unable to verify it let
application try.
|
|
Changed the behavior of the verify_fun option so that
the application can be responsible for handling path validation
errors even on the server side. Also replaced the not yet
documented validate_extensions_fun to be handled by the
verify_fun instead.
If the verify callback fun returns {fail, Reason}, the verification process is
immediately stopped and an alert is sent to the peer and the TLS/SSL
handshake is terminated. If the verify callback fun returns {valid,
UserState}, the verification process is continued. If the verify callback
fun always returns {valid, UserState}, the TLS/SSL handshake will not be
terminated with respect to verification failures and the connection
will be established. The verify callback fun will also be
able to verify application specific extensions.
|
|
|
|
Handling of unkown CA certificats was changed in ssl and
public_key to work as intended.
In the process of doing this some test cases has been corrected as
they where wrong but happened to work together with the
incorrect unknown CA handling.
|
|
Cleaned up and documented the public_key API to
make it useful for general use.
|
|
|
|
|
|
New ssl now support client/server-certificates signed by dsa keys.
|
|
|
|
|
|
|
