| Age | Commit message (Collapse) | Author |
|---|
|
Test should be run for all diffrent cert types. ssl_payload_SUITE
should test socket active option.
|
|
Regroup testes after functionality making it easier to
test all variants (all protocols, all cert types etc).
Also extend OpenSSL interop
|
|
* ingela/ssl/handshake-handling/ERL-968/OTP-15879:
ssl: Correct handshake handling
|
|
Solves ERL-968, a refactoring bug could cause part of a server key exchange message to
be appended, to an incorrectly duplicated, certificate handshake message. In the end
causing an ASN1 decoding error. That in turn did not end up the correct error handling branch.
|
|
Server and client use different secrets when sending certificate related
alerts. This is due to a change to the TLS protocol where clients send
their 'certificate' message after they have received the server's 'finished'
message.
|
|
|
|
Change-Id: Ic4895195569073916f158a06b95061939f15cfc0
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
|
|
Change-Id: Ic4895195569073916f158a06b95061939f15cfc0
|
|
TLS-1.0, TLS-1.1 and DTLS-1.0 are now considered legacy
|
|
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
lib/ssl/src/ssl_cipher_format.erl
lib/ssl/src/tls_handshake.erl
|
|
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
lib/ssl/src/tls_connection.erl
|
|
With the new TLS sender process, solving ERL-622, TLS ALERTs sent in
the connection state must be encrypted and sent by the TLS sender
process. This to make sure that the correct encryption state is used
to encode the ALERTS. Care must also be taken to ensure a graceful
close down behavior both for normal shutdown and downgrading from TLS
to TCP.
The original TR ERL-738 is verified by cowboy tests, and close down
behavior by our tests. However we alas have not been able to yet
create a minimal test case for the originating problem.
Also it seems it has become less likely that we run in to the TCP
delivery problem, that is the guarantee is only on transport level,
not application level. Keep work around function in ssl_test_lib but
we can have better test as long as we do not get to much wobbling
tests.
|
|
|
|
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.
|
|
|
|
|
|
answer to a certificate request
Solves ERL-599
|
|
The ssl application uses the new function in many of its test cases.
|
|
Otherwhise test can be wrongly initialized and will fail as they try to run
with a broken setup.
This is an addition to b3ca5727169deaa38917edca8288dcaff9a36800 that accidently
was the wrong version of that branch.
|
|
|
|
With the new help functions for creating test data we can simplify the
code. And sometimes corrections have been made so that the test actually
perform the test intended.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
Consolidate code that logs TLS/DTLS version during testing
into ssl_test_lib.
|
|
|
|
* ingela/ssl-gen-statem/OTP-13464:
ssl: Adapt DTLS to gen_statem
ssl: Use gen_statem instead of gen_fsm
|
|
Active option was not handled correctly in all places. Dead code has
been removed.
|
|
Also reduce timing issues in tests
|
|
|
|
* legoscia/critical-extension-verify-none:
ssl: with verify_none, accept critical extensions
OTP-13377
|
|
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.
|
|
* ia/ssl/modern-timetrap:
ssl: Make init functions fail if make_certs:all fails
ssl: Avoid sleep
ssl: modernize timetrap handling
|
|
|
|
Watchdog is legacy test_server use only ct:timetrap/1
|
|
|
|
The test cases does not use any hooks and including the ts_install_cth
trips up the test case setup on some platforms cuasing the test cases
to fail with {error, enoent}
|
|
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."
|
|
Make sure that test cases does not fail due to timing circumstances,
use selective receive even if it means we can not use test library functions
in some cases. TCP does not have delivery guarantee to application layer,
so sometimes a error message {error, Msg} or {error, closed} can be acceptable.
|
|
As the ASN-1 application relies on a nif in R16 for decodeing (that
was not the case in R15), public_key currently has a runtime
dependency on ASN-1. Hopefully we will be able to remove this
dependency again in the future.
|
|
Also phase in tls module as main API instead of ssl. To
make API clearer. As TLS is the new protocol name.
Maybe keep some API functions in ssl
|
|
|
