| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
lib/ssl/test/ssl_ECC_SUITE.erl
|
|
Failing to recognize psk as an anonymous key exchange would fail the connection
when trying to decode an undefined certificate.
|
|
|
|
The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
In SSL/TLS, when the server certificate contains a RSA key, then:
either a DHE or ECDHE cipher suite is used, in which case the RSA key
is used for a signature (see section 7.4.3 of RFC 5246: the "Server
Key Exchange" message); this exercises the digitalSignature key usage;
or "plain RSA" is used, with a random value (the 48-byte pre-master
secret) being encrypted by the client with the server's public key
(see section 7.4.7.1 of RFC 5246); this is right in the definition of
the keyEncipherment key usage flag.
dataEncipherment does not apply, because what is encrypted is not
directly meaningful data, but a value which is mostly generated
randomly and used to derive symmetric keys. keyAgreement does not
apply either, because that one is for key agreement algorithms which
are not a case of asymmetric encryption (e.g. Diffie-Hellman). The
keyAgreement usage flag would appear in a certificate which contains a
DH key, not a RSA key. nonRepudiation is not used, because whatever is
signed as part of a SSL/TLS key exchange cannot be used as proof for a
third party (there is nothing in a SSL/TLS tunnel that the client
could record and then use to convince a judge when tring to sue the
server itself; the data which is exchanged within the tunnel is not
signed by the server).
When a ECDSA key is used then "keyAgreement" flag is needed for beeing
ECDH "capable" (as opposed to ephemeral ECDHE)
|
|
|
|
ECDH suite handling did not use the EC parameters form the certs
as expected.
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
Fix test case code to use keyAgreement for ECDH_ECDSA
Conflicts:
lib/ssl/test/ssl_ECC.erl
lib/ssl/test/ssl_ECC_openssl_SUITE.erl
lib/ssl/test/ssl_to_openssl_SUITE.erl
|
|
When test handling was corrected it was obvious that DTLS ECC handling
was not compleated.
Conflicts:
lib/ssl/src/ssl.erl
lib/ssl/test/Makefile
lib/ssl/test/ssl_ECC.erl
lib/ssl/test/ssl_ECC_SUITE.erl
lib/ssl/test/ssl_ECC_openssl_SUITE.erl
|
|
When doing ssl:controlling_process on a ssl socket that has not
performed the TLS/DTLS handshake that call will succeed even though
the documentation stated otherwise. However if some other ssl option
was incorrect the call would hang. Now {error, closed} will be
returned in the latter case, which is logical independent on if it
should succeed or not in the former case. The former case will continue
to succeed, as it is not dependent of the TLS/DTLS connection being
established, and the documentation is altered slightly to not
explicitly disallow it. If the TLS/DTLS connection later fails and
the socket mode is active, the new controlling process will be
notified as expected.
|
|
IngelaAndin/ingela/ssl/no-ca-sign-restriction-TLS-1.2/ERL-381/OTP-15173
Ingela/ssl/no ca sign restriction tls 1.2/erl 381/otp 15173
|
|
|
|
|
|
|
|
|
|
|
|
Failing to recognize psk as an anonymous key exchange would fail the connection
when trying to decode an undefined certificate.
|
|
|
|
|
|
* origin/henrik/Update-copyright:
Update copyright year
|
|
|
|
|
|
* ingela/ssl/21-enhanchment:
ssl: Add handle_continue/2 and document enhancements
|
|
* deprecation of ssl:ssl_accept/[1,2,3]
* deprecation of ssl:cipher_suites/[0,1]
* More consistent naming
|
|
* ingela/ssl/test-ecdh-check:
ssl: Update interop conditions
|
|
|
|
* peterdmv/ssl/suite_to_str/ERL-600/OTP-15106:
ssl: Add new API function suite_to_str/1
Change-Id: Icf214ece4e1d281da12b02dadc63d4a2ca346563
|
|
Add new API function for converting cipher suite maps
to their textual representation.
Change-Id: I43681930b38e0f3bdb4dfccbf9e8895aa2d6a281
|
|
* raimo/better-TLS-distribution/OTP-15058:
Test nodename whitelist
Use public_key to verify client hostname
|
|
|
|
|
|
|
|
This reverts commit fd8e49b5bddceaae803670121b603b5eee8c5c08.
|
|
|
|
ssl: Generalize DTLS packet multiplexing
OTP-14888
|
|
We want to prepare the code for more advanced DTLS usage and possibility
to run over SCTP. First assumption was that the demultiplexer process
"dtls listener" was needed for UDP only and SCTP could be made more TLS
like. However the assumption seems not to hold. This commit prepares
for customization possibilities.
|
|
* ingela/ssl/openssl-test-cuddle:
ssl: anon test should use dh or ecdh anon keyexchange
ssl: Cuddle no delivery guarantee at application level
ssl: Cuddle timeout
ssl: Correct option handling to OpenSSL
|
|
* lukas/ssl/fix_erl_epmd_usage/OTP-15086:
ssl: Fix usage of erl_epmd in tls dist
|
|
Fixes: 662f3c7ba50ff8ec13d8
|
|
|
|
|
|
|
|
|
|
|
|
ssl: Correct key_usage check
|
|
This makes it possible to create a custom integration with a
key-value store for example. The key would then point to the
actual address. You would have to write your own epmd module
to make use of that feature.
|
|
The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
In SSL/TLS, when the server certificate contains a RSA key, then:
either a DHE or ECDHE cipher suite is used, in which case the RSA key
is used for a signature (see section 7.4.3 of RFC 5246: the "Server
Key Exchange" message); this exercises the digitalSignature key usage;
or "plain RSA" is used, with a random value (the 48-byte pre-master
secret) being encrypted by the client with the server's public key
(see section 7.4.7.1 of RFC 5246); this is right in the definition of
the keyEncipherment key usage flag.
dataEncipherment does not apply, because what is encrypted is not
directly meaningful data, but a value which is mostly generated
randomly and used to derive symmetric keys. keyAgreement does not
apply either, because that one is for key agreement algorithms which
are not a case of asymmetric encryption (e.g. Diffie-Hellman). The
keyAgreement usage flag would appear in a certificate which contains a
DH key, not a RSA key. nonRepudiation is not used, because whatever is
signed as part of a SSL/TLS key exchange cannot be used as proof for a
third party (there is nothing in a SSL/TLS tunnel that the client
could record and then use to convince a judge when tring to sue the
server itself; the data which is exchanged within the tunnel is not
signed by the server).
When a ECDSA key is used then "keyAgreement" flag is needed for beeing
ECDH "capable" (as opposed to ephemeral ECDHE)
|
|
* ingela/ssl/testcuddling:
ssl: Exclude DTLS tests for one more OpenSSL version for now
ssl: Use sane input data
ssl: Make sure help function works from all parts of test suite
|
|
* maint:
Updated OTP version
Update release notes
Update version numbers
ssl: Prepare for release
ssl: Proper handling of clients that choose to send an empty answer to a certificate request
heart: Use ntohs instead of manual conversion
|
|
|
