Age | Commit message (Collapse) | Author |
|
Extention handling need some fixes to work
correctly for ALPN and SSL-3.0 only client/servers
do not support extensions
|
|
Implement support for ECDSA certificates in TLS 1.3
|
|
TLS 1.2 ClientHello caused handshake failure in the TLS 1.2 server
if the signature_algorithms_cert extension contained legacy algorithms.
Update TLS 1.2 server to properly handle legacy signature algorithms
in the signature_algorithms_cert extension.
Update TLS 1.3 client so that it can send legacy algorithms in its
signature_algorithms_cert extension.
|
|
|
|
|
|
Handle legacy signature algorithms in TLS 1.3 ClientHello to
improve debug logging.
Change-Id: If5548c828aabab83a2b147dffa7e937bd98916c6
|
|
This commit fixes the IV length (12 bytes) and the calculation of
the nonce for the Chacha20-Poly1305 ciphers.
Change-Id: I4c9efc0bf012bc287c84c7b62c252ecf49ffe32f
|
|
|
|
Validate peer certificate against supported signature algorithms.
Send 'Hanshake Failure' Alert if signature algorithm is not
supported by the server.
Change-Id: Iad428aad337f0f9764d23404c203f966664c4555
|
|
* maint:
Inline local function
Optimize binary matching
Clean up module boundaries
Remove redundant return of CipherState
Use iovec() internally in send path
Small binary handling optimizations
Optimize read_application_data with Okasaki queue
Try to optimize decode_cipher_text/3
Optimize application data aggregation
Optimize TLS record parsing with Okasaki queue
Cache strong_random_bytes for IV
Optimize padding
Produce less garbage in encrypt loop
Reorganize #data{}
Tidy up state machine
Add server GC info to bench results
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_connection.hrl
lib/ssl/src/ssl_logger.erl
lib/ssl/src/ssl_record.erl
lib/ssl/src/ssl_record.hrl
lib/ssl/src/tls_connection.erl
lib/ssl/src/tls_record.erl
lib/ssl/src/tls_sender.erl
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
Could cause ssl to claim to support 3des_ede_cbc when cryptolib does not
|
|
- Update calculation of nonce and additional data
- Update cipher_aead, decipher_aead
- Add test for TLS 1.3 encode/decode
Change-Id: Id0a5cc68d8746079fb42c0192c0c64405f6d7a72
|
|
Change-Id: I1a2e9b1b639cae0d78b6d25d7b6e761a2d90b7b1
|
|
Change-Id: I206b851fc616c53475f4a2935f6f52baf8f3e1e6
|
|
Change-Id: Ifdf8978c58c15313e8a7973cff97dda3458f7721
|
|
Accept only TLS 1.3 ciphers when TLS 1.3 is selected.
Change-Id: I4e934d344f52208263ffdeb31c357dd5727472b9
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_connection.hrl
lib/ssl/src/tls_connection.erl
lib/ssl/src/tls_record.erl
|
|
|
|
This change adds the capability to the TLS 1.3 server to process
ClientHello messages and answer with ServerHello.
Change-Id: I13f6cfac932574300338e7301c6162252a591c70
|
|
Change-Id: Ie7409675dd7a35825f32822df259286bbb95fd62
|
|
|
|
|
|
|
|
|
|
TLS-1.3 needs to handle AEAD inputs diffrently than previous versions.
Refactor code to facilitate TLS-1.3 additions.
Change CHACHA20_POLY1305 NONCE to match RFC 7905. This will be
important later when we fix interop with TLS compatible crypto
invocation.
|
|
Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2. That is, a TLS 1.3 ClientHello shall
advertise support for TLS 1.2 ciphers in order to be able to connect
to TLS 1.2 servers.
This commit changes the list of the advertised cipher suites to
include old TLS 1.2 ciphers.
Change-Id: Iaece3ac4b66a59dfbe97068b682d6010d74522b8
|
|
Change-Id: I8a5c11b3503b44cfc6cbd6e4fd8ff3005a8669dd
|
|
This commit filters out cipher suites not to be used in TLS-1.3
We still need to add new cipher suites for TLS-1.3 and possible
add new information to the suite data structure.
|
|
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
The conversion code for different representations of cipher suites
is long an repetitive. We want to hide it in a module that does not
have other functions that we like to look at.
|
|
|
|
The keyexchange ECDHE-RSA requires an RSA-keyed server cert
(corresponding for ECDHE-ECDSA), the code did not assert this
resulting in that a incorrect cipher suite could be selected.
Alas test code was also wrong hiding the error.
|
|
- Add 'tlsv1.3' to the available versions. It can be used to
trigger experimental behavior while implementing TLS 1.3.
- Add dummy clauses for handling version {3,4} of TLS.
- Update ssl_logger to handle unknown versions of TLS.
Change-Id: I564ffa47dca18b59f0dc16c9809dfd7adaf2d333
|
|
|
|
|
|
Add new API function for converting cipher suite maps
to their textual representation.
Change-Id: I43681930b38e0f3bdb4dfccbf9e8895aa2d6a281
|
|
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.
|
|
* maint:
Updated OTP version
Update release notes
ssl: Prepare for release
ssl: Remove duplicate release note
ssl: Fix filter function to not discard AEAD cipher suites
Conflicts:
OTP_VERSION
|
|
|
|
* hasse/dialyzer/extra-range/OTP-14970:
ssl: Correct some specs
os_mon: Correct a spec
Fix broken spec in beam_asm
Dialyzer should not throw away spec information because of overspec
|
|
|
|
|