| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
The functions are not performance critical. Will be used
when errors occurs, CRL data base is managed or legacy OpenSSL names
are used for ciphers.
|
|
|
|
|
|
* raimo/ssl-dist-skip-loopback/OTP-14465:
Update runtime dependencies
Disable debug function
Pass all info's to the ssl_connection state function
Remove ssl_tls_dist_ctrl module
Remove ssl_tls_dist_ctrl process
Remove ssl_tls_dist_proxy
Avoid dialyzer warning
Separate in and out in dist ctrl
Rewrite dist ctrl from port to process
Conflicts:
lib/ssl/src/ssl.app.src
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OTP-14236 requires ssl runtime dependencies to update to latest public_key.
OTP-14181 makes ssl test cases dependent on latest version latest public_key.
|
|
|
|
|
|
|
|
|
|
|
|
ssl_pkix_db should not hard code names. On the other hand the names
are nicer with as <Prefix>_dist than <Prefix>dist.
|
|
|
|
* ingela/ssl/session-cache-max/OTP-14556:
ssl: Mend Max session handling
|
|
The commit 256e01ce80b3aadd63f303b9bda5722ad313220f was a misunderstanding
that actually broke the implementation.
It is not so important to keep specific max, rather max is a threshold
when the table should be shrinked as to not grow indefinitely.
New sessions are created when the id is created and may be short lived
it they are not registered for reuse due to handshake failure.
|
|
|
|
It is desirable to be as specific as possible in the info message, so
there can be no mistake if the alert is form the peer or generated by
us. This use to be an error message, but it is better to make it an
info message as sending an ALERT ending the connection is an expected
behaviour.
|
|
|
|
* ingela/ssl/dtls-alert-handling/OTP-14078:
dtls: Customize alert handling for DTLS over UDP
|
|
|
|
Test that DTLS handles "high" level packet types as http-packet types.
Low level packet type as {packet, 2} we will consider later if they
should be relevant to support or not.
|
|
|
|
Only DTLS specific code deals with DTLS version, when common code
is used the DTLS version should be converted to the corresponding TLS version.
|
|
RFC: ecdhe_psk cipher suites
OTP-14547
|
|
From RFC 6347:
4.1.2.7. Handling Invalid Records
Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.). In general, invalid
records SHOULD be silently discarded, thus preserving the
association; however, an error MAY be logged for diagnostic
purposes. Implementations which choose to generate an alert
instead, MUST generate fatal level alerts to avoid attacks where
the attacker repeatedly probes the implementation to see how it
responds to various types of error. Note that if DTLS is run over
UDP, then any implementation which does this will be extremely
susceptible to denial-of-service (DoS) attacks because UDP forgery
is so easy. Thus, this practice is NOT RECOMMENDED for such
transports.
|
|
|
|
* ingela/ssl/cert-handling:
ssl: Correct cipher suite handling
ssl: Modernize DSA cert chain generation
ssl: Clean
ssl: Remove test of OpenSSL
ssl: Use new cert generation
|
|
* maint:
sys_core_fold: Fix unsafe optimization of non-variable apply
Correct type specification in ssl:prf/5
|
|
Correct type specification in ssl:prf/5
|
|
This is mainly fixing the test suites so that they test the intended cipher
suites, issue reported in ERL-460.
Also ssl_cipher:anonymous_suites was corrected for DTLS.
|
|
Fix a proliferated typo in ssl
|
|
|
|
Add the GCM ciphers from draft-mattsson-tls-ecdhe-psk-aead and the
specification for the CCM cipher (but leave them commented out as
we don't support CCM yet).
|
|
|
|
whatever the SSL options say, when we negotiated a anonymous,
PSK or SRP cipher suites, client certificates and certificate
requests are not permitted.
|
|
Current implementation expects Seed to be a list.
Correct type specification to match.
|
|
|
|
state can not be determined
|
|
|
|
|
|
|
|
ERL-434
RFC6347 says about hello_verify_request version field as follow
https://tools.ietf.org/html/rfc6347#page-16
The server_version field has the same syntax as in TLS. However, in
order to avoid the requirement to do version negotiation in the
initial handshake, DTLS 1.2 server implementations SHOULD use DTLS
version 1.0 regardless of the version of TLS that is expected to be
negotiated.
But current DTLS server responses DTLS1.2 instead of DTLS1.0.
|
