- in x509_profile_check_pk_alg
- in x509_profile_check_md_alg
- in x509_profile_check_key
and in ssl_cli.c : unsigned char gets promoted to signed integer
Remove reference to `MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED` as branch
`mbedtls-2.1` doesn't have `ECJPAKE`. This definition was accidently
inserted in a backport.
This PR fixes multiple issues in the source code to address issues raised by
tests/scripts/check-files.py. Specifically:
* incorrect file permissions
* missing newline at the end of files
* trailing whitespace
* Tabs present
* TODOs in the souce code
When the "same ciphersuite validation" was backported to 2.1, we
introduced the use of irrelevant defines in ssl_cli.c. all.sh catches
these as "Likely typos". Remove the code for ECJPAKE, a feature that doesn't exist in 2.1, from ssl_cli to fix this test failure.
******************************************************************
* test/build: declared and exported names
* Thu Apr 26 08:23:19 UTC 2018
******************************************************************
1175 macros
143 enum-consts
942 identifiers
771 exported-symbols
Exported symbols declared in header: PASS
Names of actual-macros: PASS
Names of enum-consts: PASS
Names of identifiers: PASS
Likely typos: FAIL
MBEDTLS_KEY_EXCHANGE_ECJPAKE
MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED
FAILED
There are situations in which it is not clear what message to expect
next. For example, the message following the ServerHello might be
either a Certificate, a ServerKeyExchange or a CertificateRequest. We
deal with this situation in the following way: Initially, the message
processing function for one of the allowed message types is called,
which fetches and decodes a new message. If that message is not the
expected one, the function returns successfully (instead of throwing
an error as usual for unexpected messages), and the handshake
continues to the processing function for the next possible message. To
not have this function fetch a new message, a flag in the SSL context
structure is used to indicate that the last message was retained for
further processing, and if that's set, the following processing
function will not fetch a new record.
This commit simplifies the usage of this message-retaining parameter
by doing the check within the record-fetching routine instead of the
specific message-processing routines. The code gets cleaner this way
and allows retaining messages to be used in other situations as well
without much effort. This will be used in the next commits.
In the TLS test client, allow SHA-1 as a signature hash algorithm.
Without this, the renegotation tests failed.
A previous commit had allowed SHA-1 via the certificate profile but
that only applied before the initial negotiation which includes the
signature_algorithms extension.
The routine `mbedtls_ssl_write_server_key_exchange` heavily depends on
what kind of cipher suite is active: some don't need a
ServerKeyExchange at all, some need (EC)DH parameters but no server
signature, some require both. Each time we want to restrict a certain
piece of code to some class of ciphersuites, it is guarded by a
lengthy concatentation of configuration checks determining whether at
least one of the relevant cipher suites is enabled in the config; on
the code level, it is guarded by the check whether one of these
cipher suites is the active one.
To ease readability of the code, this commit introduces several helper
macros and helper functions that can be used to determine whether a
certain class of ciphersuites (a) is active in the config, and
(b) contains the currently present ciphersuite.
fixes#310
Actually all key exchanges that use a certificate use signatures too, and
there is no key exchange that uses signatures but no cert, so merge those two
flags.
Conflicts:
ChangeLog
