Commit graph

2656 commits

Author SHA1 Message Date
Manuel Pégourié-Gonnard a771160799 Introduce new config.h flag for TLS
For now the option has no effect.

Adapted existing example config files. The fact that I needed to do this
highlights that this is a slightly incompatible change: existing users need to
update their existing custom configs (if standalone as opposed to based on the
default config) in order to still get the same behaviour.

The alternative would be to have a negative config option (eg NO_TLS or
DTLS_ONLY) but this doesn't fit as nicely with the existing options, so
hopefully the minor incompatibility is acceptable.

I don't think it's worth adding a new component to all.sh:
- builds with both DTLS and TLS are done in the default (and full) config
- TLS-only builds are done with eg config-suite-b.h in test-ref-configs
- a DTLS-only build is done with config-thread.h in test-ref-configs
- builds with none of them (and SSL_TLS_C enabled) are forbidden
2019-06-06 12:59:48 +02:00
Simon Butcher 21d1c32b2b Merge remote-tracking branch 'origin/pr/574' into baremetal 2019-06-04 15:08:32 +01:00
Manuel Pégourié-Gonnard f3c43dde54 Merge branch 'mbedtls-2.16' into baremetal
* mbedtls-2.16:
  test: Always use `make clean` by itself
  list-symbols.sh: if the build fails, print the build transcript
  Document "check-names.sh -v"
  all.sh: invoke check-names.sh in print-trace-on-exit mode
  Print a command trace if the check-names.sh exits unexpectedly
  Only use submodule if present
  Update change log
  Reword ssl_conf_max_frag_len documentation for clarity
  Ignore more generated files: seedfile, apidoc
  Improve .gitignore grouping and documentation
  Generate tags for Vi, for Emacs and with Global
2019-06-04 09:39:51 +02:00
Hanno Becker 5dbcc9f441 Introduce specific error for ver/cfg mismatch on deserialization
This commit introduces a new SSL error code

  `MBEDTLS_ERR_SSL_VERSION_MISMATCH`

which can be used to indicate operation failure due to a
mismatch of version or configuration.

It is put to use in the implementation of `mbedtls_ssl_session_load()`
to signal the attempt to de-serialize a session which has been serialized
in a build of Mbed TLS using a different version or configuration.
2019-06-03 13:01:21 +01:00
Manuel Pégourié-Gonnard 35ccdbb636 Normalize spelling to serialiZation
We have explicit recommendations to use US spelling for technical writing, so
let's apply this to code as well for uniformity. (My fingers tend to prefer UK
spelling, so this needs to be fixed in many places.)

sed -i 's/\([Ss]eriali\)s/\1z/g' **/*.[ch] **/*.function **/*.data ChangeLog
2019-06-03 09:55:16 +02:00
Manuel Pégourié-Gonnard e0cd1d0184 Improve documentation 2019-06-03 09:51:08 +02:00
Manuel Pégourié-Gonnard 5363e1f496 Add list of coupled functions to struct definition 2019-06-03 09:51:08 +02:00
Manuel Pégourié-Gonnard 32ce596c35 Improve save API by always updating olen
This allows callers to discover what an appropriate size is. Otherwise they'd
have to either try repeatedly, or allocate an overly large buffer (or some
combination of those).

Adapt documentation an example usage in ssl_client2.
2019-06-03 09:51:08 +02:00
Manuel Pégourié-Gonnard 37a5324c74 Add mbedtls_ssl_get_session_pointer()
Avoid useless copy with mbedtls_ssl_get_session() before serialising.

Used in ssl_client2 for testing and demonstrating usage, but unfortunately
that means mbedtls_ssl_get_session() is no longer tested, which will be fixed
in the next commit.
2019-06-03 09:51:08 +02:00
Manuel Pégourié-Gonnard 2843fe10b9 Declare and document session save/load functions
The next commit with make the implementation publicly available as well.

For now the API is kept unchanged. The save function API has a serious drawback in that the user
must guess what an appropriate buffer size is.
Internally so far this didn't matter because we were only using that API for
ticket creation, and tickets are written to the SSL output buffer whose size
is fixed anyway, but for external users this might not be suitable. Improving
that is left for later.

Also, so far the functions are defined unconditionally. Whether we want to
re-use existing flags or introduce a new one is left for later.

Finally, currently suggested usage of calling get_session() then
session_save() is memory-inefficient in that get_session() already makes a
copy. I don't want to recommend accessing `ssl->session` directly as we want
to prohibit direct access to struct member in the future. Providing a clean
and efficient way is also left to a later commit.
2019-06-03 09:51:08 +02:00
Simon Butcher 0d1d76f987 Merge remote-tracking branch 'origin/pr/561' into baremetal 2019-05-29 15:09:24 +01:00
Simon Butcher d5e1bfc6b4 Merge remote-tracking branch 'origin/pr/569' into baremetal 2019-05-24 15:07:10 +01:00
Simon Butcher 0edb924e16 Merge remote-tracking branch 'origin/pr/565' into baremetal 2019-05-24 15:06:56 +01:00
Simon Butcher 5a790f9214 Merge remote-tracking branch 'origin/pr/563' into baremetal 2019-05-24 15:06:16 +01:00
Hanno Becker 4753e65e9b Disable Connection ID feature by default 2019-05-23 17:02:14 +01:00
Hanno Becker 948d2d5611 Expand CID to Connection ID in documentation of mbedtls_ssl_conf_cid 2019-05-23 16:55:50 +01:00
Jaeden Amero cbcd327376 Merge remote-tracking branch 'origin/pr/2611' into mbedtls-2.16
* origin/pr/2611:
  Update change log
  Reword ssl_conf_max_frag_len documentation for clarity
2019-05-23 15:14:06 +01:00
Hanno Becker 633d604837 Allow passing NULL pointers to mbedtls_ssl_get_peer_cid()
This commit modifies mbedtls_ssl_get_peer_cid() to also allow passing
NULL pointers in the arguments for the peer's CID value and length, in
case this information is needed.

For example, some users might only be interested in whether the use of
the CID was negotiated, in which case both CID value and length pointers
can be set to NULL. Other users might only be interested in confirming
that the use of CID was negotiated and the peer chose the empty CID,
in which case the CID value pointer only would be set to NULL.
It doesn't make sense to pass a NULL pointer for the CID length but a
non-NULL pointer for the CID value, as the caller has no way of telling
the length of the returned CID - and this case is therefore forbidden.
2019-05-22 16:50:35 +01:00
Hanno Becker 2f8c804d79 Fix typo in Doxygen documentation of mbedtls_ssl_conf_cid() 2019-05-20 15:35:36 +01:00
Hanno Becker a5a2b08a05 Rename MBEDTLS_SSL_CID to MBEDTLS_SSL_DTLS_CONNECTION_ID
Files modified via

sed -i 's/MBEDTLS_SSL_CID\([^_]\|$\)/MBEDTLS_SSL_DTLS_CONNECTION_ID\1/g' **/*.c **/*.h **/*.sh **/*.function
2019-05-20 15:35:36 +01:00
Hanno Becker 3cdf8fe50b Consistently reference CID draft through name + URL 2019-05-20 15:32:36 +01:00
Hanno Becker cfa6be76bd Fix typo in documentation of mbedtls_ssl_context::cid_in_use 2019-05-20 15:32:36 +01:00
Hanno Becker 96f35b4f06 Improve wording of documentation of mbedtls_ssl_get_peer_cid() 2019-05-20 15:32:36 +01:00
Hanno Becker 5fcac0dc99 Slightly reword documentation of mbedtls_ssl_set_cid() 2019-05-20 15:32:36 +01:00
Hanno Becker 53f36e9230 Use full sentences in Doxygen documentation of mbedtls_ssl_set_cid() 2019-05-20 15:32:36 +01:00
Hanno Becker dc19b41eb3 Use uniform spacing in def's of MBEDTLS_SSL_CID_{IN|OUT}_LEN_MAX 2019-05-20 15:32:36 +01:00
Hanno Becker f83017ccd1 Improve wording in documentation of mbedtls_ssl_set_cid() 2019-05-20 15:32:36 +01:00
Hanno Becker 75b334f33a Update references to CID draft to version 5 2019-05-20 15:32:36 +01:00
Hanno Becker ef2b8b0dcf Improve wording in documentation of MBEDTLS_SSL_CID 2019-05-20 15:32:36 +01:00
Hanno Becker a69b4315eb Modify MBEDTLS_SSL_UNEXPECTED_CID_{FAIL|IGNORE} to ignore by default 2019-05-20 15:32:36 +01:00
Hanno Becker e8eff9a517 Allow to configure the stack's behaviour on unexpected CIDs
This commit modifies the CID configuration API mbedtls_ssl_conf_cid_len()
to allow the configuration of the stack's behaviour when receiving an
encrypted DTLS record with unexpected CID.
2019-05-20 15:32:36 +01:00
Hanno Becker 7c3cdb62de Add specific SSL error code for unexpected CIDs
Currently, the stack silently ignores DTLS frames with an unexpected CID.
However, in a system which performs CID-based demultiplexing before passing
datagrams to the Mbed TLS stack, unexpected CIDs are a sign of something not
working properly, and users might want to know about it.

This commit introduces an SSL error code MBEDTLS_ERR_SSL_UNEXPECTED_CID
which the stack can return in response to an unexpected CID. It will
conditionally be put to use in subsequent commits.
2019-05-20 15:32:36 +01:00
Hanno Becker 7842609e3b Remove restriction on value of MBEDTLS_SSL_CID_PADDING_GRANULARITY 2019-05-20 15:32:36 +01:00
Hanno Becker 241947d062 Reword CID documentation 2019-05-20 15:32:36 +01:00
Hanno Becker 550e1662c7 Allow the configuration of padding when using CID extension 2019-05-20 15:32:36 +01:00
Hanno Becker 043a2a4869 Remove indicators and warnings about unfinished CID implementation 2019-05-20 15:32:36 +01:00
Hanno Becker 70e7928d76 Add pointers to in/out CID fields to mbedtls_ssl_context
mbedtls_ssl_context contains pointers in_buf, in_hdr, in_len, ...
which point to various parts of the header of an incoming TLS or
DTLS record; similarly, there are pointers out_buf, ... for
outgoing records.

This commit adds fields in_cid and out_cid which point to where
the CID of incoming/outgoing records should reside, if present,
namely prior to where the record length resides.

Quoting https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-04:

   The DTLSInnerPlaintext value is then encrypted and the CID added to
   produce the final DTLSCiphertext.

        struct {
            ContentType special_type = tls12_cid; /* 25 */
            ProtocolVersion version;
            uint16 epoch;
            uint48 sequence_number;
            opaque cid[cid_length];               // New field
            uint16 length;
            opaque enc_content[DTLSCiphertext.length];
        } DTLSCiphertext;

For outgoing records, out_cid is set in ssl_update_out_pointers()
based on the settings in the current outgoing transform.

For incoming records, ssl_update_in_pointers() sets in_cid as if no
CID was present, and it is the responsibility of ssl_parse_record_header()
to update the field (as well as in_len, in_msg and in_iv) when parsing
records that do contain a CID. This will be done in a subsequent commit.

Finally, the code around the invocations of ssl_decrypt_buf()
and ssl_encrypt_buf() is adapted to transfer the CID from the
input/output buffer to the CID field in the internal record
structure (which is what ssl_{encrypt/decrypt}_buf() uses).

Note that mbedtls_ssl_in_hdr_len() doesn't need change because
it infers the header length as in_iv - in_hdr, which will account
for the CID for records using such.
2019-05-20 15:32:36 +01:00
Hanno Becker add0190059 Account for additional record expansion when using CIDs
Using the Connection ID extension increases the maximum record expansion
because
- the real record content type is added to the plaintext
- the plaintext may be padded with an arbitrary number of
  zero bytes, in order to prevent leakage of information
  through package length analysis. Currently, we always
  pad the plaintext in a minimal way so that its length
  is a multiple of 16 Bytes.

This commit adapts the various parts of the library to account
for that additional source of record expansion.
2019-05-20 15:32:36 +01:00
Hanno Becker eec2be9c9f Add CID configuration API
Context:
The CID draft does not require that the length of CIDs used for incoming
records must not change in the course of a connection. Since the record
header does not contain a length field for the CID, this means that if
CIDs of varying lengths are used, the CID length must be inferred from
other aspects of the record header (such as the epoch) and/or by means
outside of the protocol, e.g. by coding its length in the CID itself.

Inferring the CID length from the record's epoch is theoretically possible
in DTLS 1.2, but it requires the information about the epoch to be present
even if the epoch is no longer used: That's because one should silently drop
records from old epochs, but not the entire datagrams to which they belong
(there might be entire flights in a single datagram, including a change of
epoch); however, in order to do so, one needs to parse the record's content
length, the position of which is only known once the CID length for the epoch
is known. In conclusion, it puts a significant burden on the implementation
to infer the CID length from the record epoch, which moreover mangles record
processing with the high-level logic of the protocol (determining which epochs
are in use in which flights, when they are changed, etc. -- this would normally
determine when we drop epochs).

Moreover, with DTLS 1.3, CIDs are no longer uniquely associated to epochs,
but every epoch may use a set of CIDs of varying lengths -- in that case,
it's even theoretically impossible to do record header parsing based on
the epoch configuration only.

We must therefore seek a way for standalone record header parsing, which
means that we must either (a) fix the CID lengths for incoming records,
or (b) allow the application-code to configure a callback to implement
an application-specific CID parsing which would somehow infer the length
of the CID from the CID itself.

Supporting multiple lengths for incoming CIDs significantly increases
complexity while, on the other hand, the restriction to a fixed CID length
for incoming CIDs (which the application controls - in contrast to the
lengths of the CIDs used when writing messages to the peer) doesn't
appear to severely limit the usefulness of the CID extension.

Therefore, the initial implementation of the CID feature will require
a fixed length for incoming CIDs, which is what this commit enforces,
in the following way:

In order to avoid a change of API in case support for variable lengths
CIDs shall be added at some point, we keep mbedtls_ssl_set_cid(), which
includes a CID length parameter, but add a new API mbedtls_ssl_conf_cid_len()
which applies to an SSL configuration, and which fixes the CID length that
any call to mbetls_ssl_set_cid() which applies to an SSL context that is bound
to the given SSL configuration must use.

While this creates a slight redundancy of parameters, it allows to
potentially add an API like mbedtls_ssl_conf_cid_len_cb() later which
could allow users to register a callback which dynamically infers the
length of a CID at record header parsing time, without changing the
rest of the API.
2019-05-20 15:32:36 +01:00
Hanno Becker ccc2456db9 Re-implement mbedtls_ssl_{in/out}_hdr_len() via in/out pointers 2019-05-20 15:32:36 +01:00
Hanno Becker 4339576208 Split mbedtls_ssl_hdr_len() in separate functions for in/out records
The function mbedtls_ssl_hdr_len() returns the length of the record
header (so far: always 13 Bytes for DTLS, and always 5 Bytes for TLS).

With the introduction of the CID extension, the lengths of record
headers depends on whether the records are incoming or outgoing,
and also on the current transform.

Preparing for this, this commit splits mbedtls_ssl_hdr_len() in two
-- so far unmodified -- functions mbedtls_ssl_in_hdr_len() and
mbedtls_ssl_out_hdr_len() and replaces the uses of mbedtls_ssl_hdr_len()
according to whether they are about incoming or outgoing records.

There is no need to change the signature of mbedtls_ssl_{in/out}_hdr_len()
in preparation for its dependency on the currently active transform,
since the SSL context is passed as an argument, and the currently
active transform is referenced from that.
2019-05-20 15:32:36 +01:00
Hanno Becker 346a590c1c Unify documentation of internal SSL record structure
- Don't use Doxygen style comments
- Document CID and CID length fields.
2019-05-20 14:49:02 +01:00
Hanno Becker 2e7cd5aa4c Use MBEDTLS_ namespace for internal CID length constant 2019-05-17 10:23:47 +01:00
Hanno Becker 92c930f7c4 Implement inner plaintext parsing/writing for CID-based connections 2019-05-17 10:23:47 +01:00
Hanno Becker 80fe63e082 Add CID field to internal structure representing TLS records
This commit adds a static array `cid` to the internal structure
`mbedtls_record` representing encrypted and decrypted TLS records.

The expected evolution of state of this field is as follows:
- When handling an incoming record, the caller of `mbedtls_decrypt_buf()`
  has to make sure the CID array field in `mbedtls_record` has been
  properly set. Concretely, it will be copied from the CID from the record
  header during record parsing.
- During decryption in `mbedtls_decrypt_buf()`, the transforms
  incoming CID is compared to the CID in the `mbedtls_record`
  structure representing the record to be decrypted.
- For an outgoing TLS record, the caller of `mbedtls_encrypt_buf()`
  clears the CID in the `mbedtls_record` structure.
- During encryption in `mbedtls_encrypt_buf()`, the CID field in
  `mbedtls_record` will be copied from the out-CID in the transform.
2019-05-17 10:23:47 +01:00
Hanno Becker 8013b27481 Replace 'ingoing' -> 'incoming' in CID debug messages 2019-05-17 10:20:41 +01:00
Hanno Becker cb063f5a5b Document behaviour of mbedtls_ssl_get_peer_cid() for empty CIDs 2019-05-17 10:20:41 +01:00
Hanno Becker fc7ff9289f Use unused extension ID as tentative ID for CID extension 2019-05-17 10:20:41 +01:00
Hanno Becker 4f0b15faec Add fields holding in/out CIDs to SSL record transformation struct
These will be copied from the CID fields in mbedtls_ssl_handshake_params
(outgoing CID) and mbedtls_ssl_context (incoming CID) when the transformation
is set up at the end of the handshake.
2019-05-17 10:20:41 +01:00
Hanno Becker 46629717c9 Check static bounds of CID lengths in check_config.h 2019-05-17 10:20:41 +01:00