| Age | Commit message (Collapse) | Author |
|---|
|
|
|
A selfsigned trusted anchor should not be in the certifcate chain passed to
the certificate path validation.
Conflicts:
lib/ssl/src/ssl_certificate.erl
|
|
|
|
disable option
|
|
|
|
disable option
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/ssl_record.erl
lib/ssl/src/tls_record.erl
lib/ssl/test/ssl_cipher_SUITE.erl
|
|
* lemenkov/use_os_getenv_2:
fix missing include
Start using os:getenv/2 fun
Introduce os:getenv/2
|
|
See #535
Signed-off-by: Peter Lemenkov <[email protected]>
|
|
=== OTP-17.4 ===
Changed Applications:
- asn1-3.0.3
- common_test-1.9
- compiler-5.0.3
- crypto-3.4.2
- debugger-4.0.2
- dialyzer-2.7.3
- diameter-1.8
- edoc-0.7.16
- eldap-1.1
- erl_docgen-0.3.7
- erl_interface-3.7.20
- erts-6.3
- eunit-2.2.9
- hipe-3.11.2
- inets-5.10.4
- jinterface-1.5.12
- kernel-3.1
- megaco-3.17.3
- mnesia-4.12.4
- observer-2.0.3
- odbc-2.10.22
- otp_mibs-1.0.10
- parsetools-2.0.12
- percept-0.8.10
- runtime_tools-1.8.15
- snmp-5.1.1
- ssh-3.1
- ssl-5.3.8
- stdlib-2.3
- syntax_tools-1.6.17
- test_server-3.7.2
- tools-2.7.1
- wx-1.3.2
Unchanged Applications:
- cosEvent-2.1.15
- cosEventDomain-1.1.14
- cosFileTransfer-1.1.16
- cosNotification-1.1.21
- cosProperty-1.1.17
- cosTime-1.1.14
- cosTransactions-1.2.14
- et-1.5
- gs-1.5.16
- ic-4.3.6
- orber-3.7.1
- os_mon-2.3
- ose-1.0.2
- public_key-0.22.1
- reltool-0.6.6
- sasl-2.4.1
- typer-0.9.8
- webtool-0.8.10
- xmerl-1.3.7
Conflicts:
OTP_VERSION
erts/vsn.mk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
OTP_VERSION
|
|
* ia/ssl/seperate-clinet-server-session-table/OTP-11365:
ssl: Separate session cache for client and server
|
|
Even though in the most common case an erlang node will not be both client
and server, it may happen (for instance when running the erlang ditribution
over TLS).
Also try to mitigate the affect of dumb clients that could cause a
very lagre session cache on the client side that can cause long delays
in the client. The server will have other means to handle a large
session table and will not do any select operations on it anyhow.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OTP-12200
* matwey/makefile:
Cleanup parse_transform modules in eunit
Cleanup behaviour modules in ssl
Cleanup behaviour modules in ssh
Fix a typo in clean section of otp_mibs makefile
|
|
|
|
|
|
=== OTP-17.3 ===
Changed Applications:
- asn1-3.0.2
- common_test-1.8.2
- compiler-5.0.2
- crypto-3.4.1
- dialyzer-2.7.2
- diameter-1.7.1
- edoc-0.7.15
- erl_docgen-0.3.6
- erl_interface-3.7.18
- erts-6.2
- eunit-2.2.8
- hipe-3.11.1
- ic-4.3.6
- inets-5.10.3
- jinterface-1.5.10
- kernel-3.0.3
- megaco-3.17.2
- mnesia-4.12.3
- observer-2.0.2
- odbc-2.10.21
- os_mon-2.3
- ose-1.0.1
- public_key-0.22.1
- sasl-2.4.1
- snmp-5.1
- ssh-3.0.5
- ssl-5.3.6
- stdlib-2.2
- tools-2.7
- wx-1.3.1
Unchanged Applications:
- cosEvent-2.1.15
- cosEventDomain-1.1.14
- cosFileTransfer-1.1.16
- cosNotification-1.1.21
- cosProperty-1.1.17
- cosTime-1.1.14
- cosTransactions-1.2.14
- debugger-4.0.1
- eldap-1.0.3
- et-1.5
- gs-1.5.16
- orber-3.7
- otp_mibs-1.0.9
- parsetools-2.0.11
- percept-0.8.9
- reltool-0.6.6
- runtime_tools-1.8.14
- syntax_tools-1.6.16
- test_server-3.7.1
- typer-0.9.8
- webtool-0.8.10
- xmerl-1.3.7
Conflicts:
OTP_VERSION
erts/vsn.mk
|
|
|
|
|
|
|
|
|
|
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."
|
|
|
|
The OpenSSL name filter would fail for cipher suites that do not
have an offcial OpenSSL name yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Use generated certs instead of hard coded
|
|
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.
|
|
* dgud/ssl/simple-bench:
ssl: Bench use two nodes
ssl: Add simple benchmarks
|
|
* dnet/parse_sni:
added SNI decode test to SSL handshake suite
ssl: parse SNI in received client hello records
OTP-12048
|
|
Behaviour modules were not cleanuped.
|
