This commit moves generic/client/server handshake handling
code from ssl_tls.c, ssl_cli.c and ssl_srv.c to the newly
created files ssl_12_gen.c, ssl_12_cli.c and ssl_12_srv.c.
No functional changes have been made. Changes are confined to
moving, reordering, and commenting the code for ease of reading.
This commit introduces source files
- `ssl_12_gen.c`
- `ssl_12_srv.c`
- `ssl_12_cli.c`
which will subsequently be populated with implementations
for handshake reading and writing functions for all TLS
versions <= 1.2. `ssl_12_gen.c` shall contain functions
shared between client and server, while `ssl_12_cli.c`
and `ssl_12_srv.c` shall contain client/server-specific
functions only.
In order to retain git history, those files are so far
identical copies of `ssl_tls.c`, `ssl_srv.c` and `ssl_cli.c`,
and those latter files have been moved to temporary files
`ssl_xxx_old.c`. Subsequent commits will rename them back
to their original name and do the actual code split.
This commit makes some SSL functions public-internal -- moving them to
to the mbedtls_ namespace but declaring them within ssl_internal.h --
which a currently shared between the SSL logic layer implementation in
ssl_tls.c and the SSL messaging layer implementation in ssl_msg.c
Broadly, the file `ssl_tls.c` functionality from two categories:
1) An implementation of the TLS and DTLS messaging layer, that is,
the record layer as well as the DTLS retransmission state machine.
2) Handshake parsing and writing functions shared between client and
server (functions specific to either client or server are implemented
in ssl_cli.c and ssl_srv.c, respectively).
This commit is a first step towards separating those functionalities
by moving a number of messaging layer related functions from ssl_tls.c
to the newly created ssl_msg.c.
Because of implementation-specific dependencies between handshake logic
and messaging layer, a number of internal SSL functions are currently
used from both the handshake and the messaging layer. Those functions
will need to made public internal (i.e. declared in the mbedtls_ name-
space in ssl_internal.h), but this is left for the next commit in order
to ease review through `git diff --color-moved`. Also, the analysis of
whether their use can/should be restricted to either ssl_tls.c or ssl_msg.c
is left for future commits.
This commit is the first step in implementing the TLS handshake logic
and the low-level (D)TLS messaging functionality (record layer and
retransmission state machine) in separate source files. So far, they're
both implemented in ssl_tls.c.
To begin, this commit creates unmodified copies ssl_tls_old.c and ssl_msg.c
of ssl_tls.c, which in turn is deleted. Subsequent commits will then rename
ssl_tls_old.c back into ssl_tls.c and remove code so that each piece of
functionality is contained in precisely one of ssl_tls.c or ssl_msg.c.
This approach allows to maintain the git line history.
ssl_decompress_buf() was operating on data from the ssl context, but called at
a point where this data is actually in the rec structure. Call it later so
that the data is back to the ssl structure.
The library style is to start with the includes corresponding to the
current module and then the rest in alphabetical order. Some modules
have several header files (eg. ssl_internal.h).
The recently added error.h includes did not respect this convention and
this commit restores it. In some cases this is not possible just by
moving the error.h declarations. This commit fixes the pre-existing
order in these instances too.
* origin/pr/2854:
Shorter version of mbedtls_ssl_send_fatal_handshake_failure
Resolve#2801 - remove repetitive assignment to ssl->in_msg (the first value was never used)
Resolve#2800 - move declaration to avoid unused variable warning in case MBEDTLS_SSL_PROTO_DTLS was undefined
Resolve#2717 - remove erroneous sizeof (the operator was applied to constant integer number)
Record checking fails if mbedtls_ssl_check_record() is called with
external buffer. Received record sequence number is available in the
incoming record but it is not available in the ssl contexts `in_ctr`-
variable that is used when decoding the sequence number.
To fix the problem, temporarily update ssl context `in_ctr` to
point to the received record header and restore value later.
In TLS, the master secret is always a key. But EAP-TLS uses the TLS
PRF to derive an IV with an empty string for the "secret" input. The
code always stored the secret into a key slot before calling the TLS
PRF, but this doesn't work when the secret is empty, since PSA Crypto
no longer supports empty keys. Add a special case for an empty secret.
The SSL context maintains a set of 'out pointers' indicating the
address at which to write the header fields of the next outgoing
record. Some of these addresses have a static offset from the
beginning of the record header, while other offsets can vary
depending on the active record encryption mechanism: For example,
if an explicit IV is in use, there's an offset between the end
of the record header and the beginning of the encrypted data to
allow the explicit IV to be placed in between; also, if the DTLS
Connection ID (CID) feature is in use, the CID is part of the
record header, shifting all subsequent information (length, IV, data)
to the back.
When setting up an SSL context, the out pointers are initialized
according to the identity transform + no CID, and it is important
to keep them up to date whenever the record encryption mechanism
changes, which is done by the helper function ssl_update_out_pointers().
During context deserialization, updating the out pointers according
to the deserialized record transform went missing, leaving the out
pointers the initial state. When attemping to encrypt a record in
this state, this lead to failure if either a CID or an explicit IV
was in use. This wasn't caught in the tests by the bad luck that
they didn't use CID, _and_ used the default ciphersuite based on
ChaChaPoly, which doesn't have an explicit IV. Changing either of
this would have made the existing tests fail.
This commit fixes the bug by adding a call to ssl_update_out_pointers()
to ssl_context_load() implementing context deserialization.
Extending test coverage is left for a separate commit.
Breaking into a series of statements makes things easier when stepping through
the code in a debugger.
Previous comments we stating the opposite or what the code tested for (what we
want vs what we're erroring out on) which was confusing.
Also expand a bit on the reasons for these restrictions.
Modelled after the config-checking header from session s11n.
The list of relevant config flags was established by manually checking the
fields serialized in the format, and which config.h flags they depend on.
This probably deserves double-checking by reviewers.
Since the type of cid_len is unsigned but shorter than int, it gets
"promoted" to int (which is also the type of the result), unless we make the
other operand an unsigned int which then forces the expression to unsigned int
as well.
The number of meaning of the flags will be determined later, when handling the
relevant struct members. For now three bytes are reserved as an example, but
this number may change later.
This mainly follows the design document (saving all fields marked "saved" in
the main structure and the transform sub-structure) with two exceptions:
- things related to renegotiation are excluded here (there weren't quite in
the design document as the possibility of allowing renegotiation was still
on the table, which is no longer is) - also, ssl.secure_renegotiation (which
is not guarded by MBEDTLS_SSL_RENEGOTIATION because it's used in initial
handshakes even with renegotiation disabled) is still excluded, as we don't
need it after the handshake.
- things related to Connection ID are added, as they weren't present at the
time the design document was written.
The exact format of the header (value of the bitflag indicating compile-time
options, whether and how to merge it with the serialized session header) will
be determined later.
Enforce restrictions indicated in the documentation.
This allows to make some simplifying assumptions (no need to worry about
saving IVs for CBC in TLS < 1.1, nor about saving handshake data) and
guarantees that all values marked as "forced" in the design document have the
intended values and can be skipped when serialising.
Some of the "forced" values are not checked because their value is a
consequence of other checks (for example, session_negotiated == NULL outside
handshakes). We do however check that session and transform are not NULL (even
if that's also a consequence of the initial handshake being over) as we're
going to dereference them and static analyzers may appreciate the info.
