| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We want to be able to save a specific session to reuse, and make sure
it is reusable immediatly when the connection has been established.
Add client option {reuse_session, SessionID::binary()}
We also do not want clients to save sessions that it did not verify.
Additionaly change behaviour of the client and server to not save sessions
if reuse_session is set to false.
|
|
If the socket option is set to {packet, 1|2|3|4} sender process needs to
add a packet length header. If packet is changed with ssl:setopts/2 this needs
to be communicated to tls_sender.
|
|
Separate sending and receiving when using TCP as transport
as prim_inet:send may block which in turn may result
in a deadlock between two Erlang processes communicating over
TLS, this is especially likely to happen when running Erlang distribution
over TLS.
|
|
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.
|
|
|
|
* 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
|
|
* 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
|
|
|
|
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.
|
|
|
|
|
|
|
|
When test handling was corrected it was obvious that DTLS ECC handling
was not compleated.
|
|
|
|
The interoperability option to fallback to insecure renegotiation
now has to be explicitly turned on.
|
|
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
lib/ssl/src/ssl_cipher.erl
lib/ssl/test/ssl_basic_SUITE.erl
lib/ssl/test/ssl_test_lib.erl
|
|
Preferably customized cipher suites will be based on the default value.
But all may be used as base and hence it will be good to
handle anonymous suites separately as they are intended for testing purposes.
|
|
Authenticated encryption (AE) and authenticated encryption with
associated data (AEAD, variant of AE) is a form of encryption which
simultaneously provides confidentiality, integrity, and authenticity
assurances on the data.
This is more logical value then null that was used, this happened to
work as the AEAD property was derived form other data, but it is confusing!
|
|
|
|
|
|
* ingela/ssl/cipher-suites/OTP-14749:
ssl: Use maps for cipher suites internally
|
|
This is a preparation for improvements to come in option handling and
support for TLS-1.3
|
|
|
|
|
|
* ingela/dtls/no-packet-upd/OTP-14664:
ssl: No support for packet option over unreliable transport
|
|
* ingela/ssl/extend-hostname-check/OTP-14632/OTP-14655:
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
|
|
|
|
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.
|
|
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.
|
|
|
|
Current implementation expects Seed to be a list.
Correct type specification to match.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
The new_options_in_accept test is not working yet, however DTLS is still
work in progress and we want to make a progress merge to avoid merge conflicts
with other progress of the ssl application.
|
|
DTLS does not support stream ciphers and needs diffrent
handling of the "#ssl_socket{}" handle .
|
|
The PEM cache handling has proven to be too disruptive of the manager process.
|
|
If a handshake message is really big it could happen that the ssl
process would hang due to failing of requesting more data from the
socket. This has been fixed.
Also added option to limit max handshake size. It has a default
value that should be big enough to handle normal usage and small
enough to mitigate DoS attacks.
|
|
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.
|
