| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Add session_id and remove undocumented ssl:session_info/1
Add client_random, server_random and master_secret, they will not be included
in ssl:connection_information/1 as they may affect the connections security if
used recklessly.
|
|
|
|
Change retransmissions timers to use gen_statem state timeouts. We do
not need a retransmission timer in the state connection as data traffic in
DTLS over UDP is not retransmitted. If the last flight before
transitioning into connection is lost, it will be resent when the peer
resends its last flight. This will also make hibernation testing more
straight forward.
We need more adjustments later to handle a reliable DTLS transport
such as SCTP.
|
|
DTLS does not support stream ciphers and needs diffrent
handling of the "#ssl_socket{}" handle .
|
|
|
|
Use map instead of large tuple, which was not an option when the code
was written originally. More simplifications along these lines may
be done later to the state record.
|
|
When the terminate function is called explicitly, to make guarantees
that for instance the reuseaddr option works as expected, we must
make sure that the clean up code is not run again when gen_statem
calls terminate. This check was broken in the rewrite from gen_fsm to
gen_statem.
Caused PEM cache errors, that in some cases would
cause unexpected connection failures.
|
|
Beta DTLS, not production ready. Only very basically tested, and
not everything in the SPEC is implemented and some things
are hard coded that should not be, so this implementation can not be consider
secure.
Refactor "TLS connection state" and socket handling, to facilitate
DTLS implementation.
Create dtls "listner" (multiplexor) process that spawns
DTLS connection process handlers.
Handle DTLS fragmentation.
Framework for handling retransmissions.
Replay Detection is not implemented yet.
Alerts currently always handled as in TLS.
|
|
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.
|
|
selected.
|
|
|
|
|
|
|
|
We want to share more alert and application data handling code.
Some of the application data handling code, packet handling,
will not be relevant for dtls, but this code can be excluded from dtls
by options checking.
|
|
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.
|
|
When protocol version is proagated from the DTLS connection processes
state into general ssl functions it must be converted to the corresponding
TLS version.
|
|
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
|
|
|
|
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.
|
|
The flight concept was introduced by DTLS (RFC 4347) to optimize
the packing of DTLS records into UDP packets. This change
implments the flight concept in the the generic SSL connection
logic and add the queue logic to the TLS and DTLS stack.
The DTLS required resend handling is not implemented yet.
While the flight handling is only required for DTSL, it turns
out that the same mechanism can be usefull to TCP based TLS as
well.
With the current scheme each TLS record will be mapped into a
separate TCP frame. This causes more TCP frames to be generate
that necessary. On fast network this will have no impact, but
reducing the number of frames and thereby the number of
round trips can result in significant speedups on slow and
unreliable networks.
Conflicts:
lib/ssl/src/tls_connection.erl
|
|
|
|
|
|
There are a lot of cases where `ssl` application just returns unhelpful
`handshake failure` or `internal error`. This patch tries to provide
better diagnostics so operator can debug his SSL misconfiguration
without doing hardcore erlang debugging.
Here is an example escript that incorrectly uses server certificate as a
client one:
https://gist.github.com/binarin/35c34c2df7556bf04c8a878682ef3d67
With the patch it is properly reported as an error in "extended key
usage".
|
|
|
|
* kennethlakin/tls-use-negotiated-prf/PR-1042/OTP-13546:
ssl: Use cipher suite's PRF in prf/5
|
|
|
|
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.
|
|
Also reduce timing issues in tests
|
|
ssl already used crypto:strong_rand_bytes/1 for most operations as
its use cases are mostly cryptographical. Now crypto:strong_rand_bytes/1
will be used everywhere.
However crypto:rand_bytes/1 was used as fallback if
crypto:strong_rand_bytes/1 throws low_entropy, this
will no longer be the case. This is a potential incompatibility.
The fallback was introduced a long time ago for interoperability reasons.
Now days this should not be a problem, and if it is, the security
compromise is not acceptable anyway.
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
In TLS-1.2 The signature algorithm and the hash function algorithm
used to produce the digest that is used when creating the digital signature
may be negotiated through the signature algorithm extension RFC 5246.
We want to make these algorithm pairs configurable.
In connections using lower versions of TLS these algorithms are
implicit defined and can not be negotiated or configured.
DTLS is updated to not cause dialyzer errors, but needs to get a real
implementation later.
|
|
|
|
Make sure that options only relevant for one role (client|server) is set
to undefined when the other role is invoked. As there are many options to
ssl, and many are optional, we choose to filter out all undefined options
to avoid overwhelming the user with not relevant information.
This way there is no need for any special handling of the role specific options
which is also nice.
|
|
|
|
Starting an SSL connection with a nonexistent keyfile will obviously
return an error:
> ssl:connect("www.google.com", 443, [{keyfile, "nonexistent"}]).
{error,{options,{keyfile,"nonexistent",{error,enoent}}}}
But it also generates an error report with the following backtrace:
** Reason for termination =
** {badarg,[{ets,select_delete,
[undefined,[{{{undefined,'_','_'},'_'},[],[true]}]],
[]},
{ets,match_delete,2,[{file,"ets.erl"},{line,700}]},
{ssl_pkix_db,remove_certs,2,[{file,"ssl_pkix_db.erl"},{line,243}]},
{ssl_connection,terminate,3,
[{file,"ssl_connection.erl"},{line,941}]},
{tls_connection,terminate,3,
[{file,"tls_connection.erl"},{line,335}]},
{gen_fsm,terminate,7,[{file,"gen_fsm.erl"},{line,610}]},
{gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,532}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}
This happens because the ssl_connection process receives its cert_db
while handling the {start, Timeout} message, but if the handshake
fails, the cert_db will never be inserted into the state data, and the
terminate function will use 'undefined' as an ETS table name.
Avoid this by checking for 'undefined' in the handle_trusted_certs_db
function.
|
|
Add possibility to downgrade an SSL/TLS connection to a tcp connection,
and give back the socket control to a user process.
Add application setting to be able to change fatal alert shutdown
timeout, also shorten the default timeout. The fatal alert timeout is
the number of milliseconds between sending of a fatal alert and
closing the connection. Waiting a little while improves the
peers chances to properly receiving the alert so it may
shutdown gracefully.
|
|
|
|
This commit adds a new function, ssl:connection_information/[1,2]
to retrive the connection information from a SSLSocket.
And also, this deprecates a function ssl:connection_info/1, and
reimplements connection_info/1 with the new function.
|
|
|
|
This commit adds support for RFC7301, application-layer protocol
negotiation. ALPN is the standard based approach to the NPN
extension, and is required for HTTP/2.
ALPN lives side by side with NPN and provides an equivalent
feature but in this case it is the server that decides what
protocol to use, not the client.
When both ALPN and NPN are sent by a client, and the server is
configured with both ALPN and NPN options, ALPN will always
take precedence. This behavior can also be found in the OpenSSL
implementation of ALPN.
ALPN and NPN share the ssl:negotiated_protocol/1 function for
retrieving the negotiated protocol. The previously existing
function ssl:negotiated_next_protocol/1 still exists, but has
been deprecated and removed from the documentation.
The tests against OpenSSL require OpenSSL version 1.0.2+.
|
|
|
|
|
|
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."
|
|
|
|
|
|
|
|
|
|
|
