| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
answer to a certificate request
Solves ERL-599
|
|
|
|
* ingela/ssl/no-sslv2-hello-support/OTP-14824:
ssl: Remove interoperability option v2_hello_compatible
|
|
* 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
|
|
|
|
|
|
|
|
Anonymous cipher suites were broken altogether, and
there was an earlier issue where the server would send a signature
in the server key exchange if a certificate was configured, even
if an anonymous suite was actually negotiated.
Backport of PR-1729
|
|
|
|
completely deprecated operation with no effect.
|
|
|
|
|
|
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/ssl_handshake.erl
|
|
This is a preparation for improvements to come in option handling and
support for TLS-1.3
|
|
Conflicts:
OTP_VERSION
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
public_key: verify ip (both v4 and v6)
public_key: Added IP4 address checks to hostname_verification tests
ssl: Fix test cases to work on all test platforms
public_key: Fix dialyzer spec
ssl: Sessions must be registered with SNI if exists
ssl: Extend hostname check to fallback to checking IP-address
public_key, ssl: Handles keys so that APIs are preserved correctly
ssl: Use ?FUNCTION_NAME
ssl: Prepare for release
ssl: Countermeasurements for Bleichenbacher attack
Conflicts:
lib/public_key/doc/src/public_key.xml
lib/public_key/test/public_key_SUITE.erl
lib/public_key/test/public_key_SUITE_data/pkix_verify_hostname_subjAltName_IP.pem
lib/public_key/test/public_key_SUITE_data/verify_hostname_ip.conf
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
|
|
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
lib/ssl/src/tls_connection.erl
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
state can not be determined
|
|
|
|
When the server_name_indication is sent automatize the
clients check of that the hostname is present in the
servers certificate. Currently server_name_indication shall
be on the dns_id format. If server_name_indication is disabled
it is up to the user to do its own check in the verify_fun.
|
|
|
|
Note this is a change form how it works for earlier versions that will
send the first hello message on the lowest supported version.
From RFC 5246
Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server.
A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is
willing to use) only versions greater than client_version, it MUST
send a "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
|
|
for the CRL
|
|
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
* ferd/bypass-pem-cache/PR-1143/OTP-13883:
ssl: Add documentation of bypass_pem_cache application environment configuration
ssl: Add new benchmarks to skip file for normal testing
Adding PEM cache bypass benchmark entries
Fixing CRL searching in cache bypass
Add option to bypass SSL PEM cache
|
|
|
|
ssl_handshake:update_handshake_history
This proably a much bigger problem for DTLS than TLS, but should be
disabled for both unless explicitly configured for TLS.
|
|
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
The current SSL implementation has a PEM cache running through the ssl
manager process, whose primary role is caching CA chains from files on
disk. This is intended as a way to save on disk operation when the
requested certificates are often the same, and those cache values are
both time-bound and reference-counted. The code path also includes
caching the Erlang-formatted certificate as decoded by the public_key
application
The same code path is used for DER-encoded certificates, which are
passed in memory and do not require file access. These certificates are
cached, but not reference-counted and also not shared across
connections.
For heavy usage of DER-encoded certificates, the PEM cache becomes a
central bottleneck for a server, forcing the decoding of every one of
them individually through a single critical process. It is also not
clear if the cache remains useful for disk certificates in all cases.
This commit adds a configuration variable for the ssl application
(bypass_pem_cache = true | false) which allows to open files and decode
certificates in the calling connection process rather than the manager.
When this action takes place, the operations to cache and return data
are replaced to strictly return data.
To provide a transparent behaviour, the 'CacheDbRef' used to keep track
of the certificates in the cache is replaced by the certificates itself,
and all further lookup functions or folds can be done locally.
This has proven under benchmark to more than triple the performance of
the SSL application under load (once the session cache had also been
disabled).
|
|
|
|
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/vsn.mk
lib/common_test/doc/src/notes.xml
lib/common_test/vsn.mk
lib/ssl/doc/src/notes.xml
lib/ssl/src/ssl.appup.src
lib/ssl/vsn.mk
lib/stdlib/test/ets_SUITE.erl
otp_versions.table
|
|
Use the list of versions that the server allows and among those choose
the highest version that is not higher than the client's version.
Note that this chosen version might be lower than the client's version,
but is used to improve interoperability.
Patch suggested by Dimitry Borisov refering to RFC 5246 appendix E.1.
|
|
In TLS-1.2 the selection of the servers algorithms and the the
possible selection of algorithms for the client certificate verify
message have different requirements.
|
|
* ingela/ssl/dtls-next-step-flights/OTP-13678:
dtls: Avoid dialyzer errors
dtls: add implementation for msg sequence
dtls: Remove TODO
dtls: sync dtls_record DTLS version and crypto handling with TLS
dtls: handle Hello and HelloVerify's in dtls_handshake
dtls: rework/simplify DTLS fragment decoder
dtls: add support first packet and HelloVerifyRequest
dtls: sync handle_info for connection close with TLS
dtls: sync handling of ClientHello with TLS
dtls: rework handshake flight encodeing
dtls: implement next_tls_record
dtls: sync init and initial_state with tls_connection
dtls: update start_fsm for new ssl_connection API
ssl: introduce the notion of flights for dtls and tls
ssl: move available_signature_algs to ssl_handshake
|
|
* legoscia/ssl_crl_hash_dir-bis/PR-982/OTP-13530:
Skip crl_hash_dir_expired test for LibreSSL
Add ssl_crl_hash_dir module
Function for generating OpenSSL-style name hashes
Add public_key:pkix_match_dist_point
Improve formatting for crl_{check,cache} options
Add issuer arg to ssl_crl_cache_api lookup callback
Conflicts:
lib/public_key/test/public_key_SUITE.erl
|
|
available_signature_algs is also needed for DTLS, move it
into a shared place and export it.
Conflicts:
lib/ssl/src/tls_handshake.erl
|
|
Use the negotiated cipher suite's PRF algorithm in calls to
ssl:prf/5, rather than a hard-coded one.
For TLS 1.0 the PRF algorithm was hard-coded to MD5/SHA1. This
was correct 100% of the time.
For TLS 1.1 and 1.2 the PRF algorithm was hard-coded to SHA256.
This was correct only some of the time for TLS 1.2 and none of the
time for TLS 1.1. Because the TLS handshake code calls tls_v1:prf/5
through another path, the handshaking process used the negotiated
PRF and did not encounter this bug.
A new test (prf) has been added to ssl_basic_SUITE to guard against future
breakage.
|
|
We do not want error reports that can leek secret information
into the logs.
|
