Fix implementation and documentation missmatch for the function
arguments to mbedtls_gcm_finish(). Also, removed redundant if condition
that always evaluates to true.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
Fix implementation and documentation missmatch for the function
arguments to mbedtls_gcm_finish(). Also, removed redundant if condition
that always evaluates to true.
The certificates are not valid according to the RFC, but are in wide
distribution across the internet. Hence the request to add a
compile-time flag to accept these certificates if wanted by the
application.
If POLARSSL_RELAXED_X509_DATE is enabled it will allow dates without
seconds, and allow dates with timezones (but doesn't actually use
the timezone).
Patch provided by OpenVPN.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
The server code parses the client hello extensions even when the
protocol is SSLv3 and this behaviour is non compliant with rfc6101.
Also the server sends extensions in the server hello and omitting
them may prevent interoperability problems.
armar doesn't understand the syntax without dash. OTOH, the syntax with dash
is the only one specified by POSIX, and it's accepted by GNU ar, BSD ar (as
bundled with OS X) and armar, so it looks like the most portable syntax.
fixes#386
See for example page 8 of
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
The previous constant probably came from a typo as it was 2^26 - 2^5 instead
of 2^36 - 2^5. Clearly the intention was to allow for a constant bigger than
2^32 as the ull suffix and cast to uint64_t show.
fixes#362
Remove check on the pathLenConstraint value when looking for a parent to the
EE cert, as the constraint is on the number of intermediate certs below the
parent, and that number is always 0 at that point, so the constraint is always
satisfied.
The check was actually off-by-one, which caused valid chains to be rejected
under the following conditions:
- the parent certificate is not a trusted root, and
- it has pathLenConstraint == 0 (max_pathlen == 1 in our representation)
fixes#280
* mbedtls-1.3:
Use own implementation of strsep()
Add Changelog entries for this branch
Use symbolic constants in test data
Fixed pathlen contraint enforcement.
Additional corner cases for testing pathlen constrains. Just in case.
Added test case for pathlen constrains in intermediate certificates
* mbedtls-1.3:
Add ChangeLog entry for previous commit
cert_write : fix "Destination buffer is too small" error
Add ChangeLog entry for previous two commits
Test certificate "Server1 SHA1, key_usage" reissued.
Fix boolean values according to DER specs
Fix typo in an OID name
Disable reportedly broken assembly of Sparc(64)
ECHDE-PSK does not use a certificate
Actually ignore most non-fatal alerts
If len is large enough, when cast to an int it will be negative and then the
test if( len > MAX_PATH - 3 ) will not behave as expected.
Ref: IOTSSL-518
backport of 261faed725
* mbedtls-1.3:
Fix spurious #endif from previous cherry-pick
Fix macroization of inline in C++
Add missing warning in doc
Fix compile error in net.c with musl libc
Found by Guido Vranken.
Two possible integer overflows (during << 2 or addition in BITS_TO_LIMB())
could result in far too few memory to be allocated, then overflowing the
buffer in the subsequent for loop.
Both integer overflows happen when slen is close to or greater than
SIZE_T_MAX >> 2 (ie 2^30 on a 32 bit system).
Note: one could also avoid those overflows by changing BITS_TO_LIMB(s << 2) to
CHARS_TO_LIMB(s >> 1) but the solution implemented looks more robust with
respect to future code changes.
There is only one length byte but for some reason we skipped two, resulting in
reading one byte past the end of the extension. Fortunately, even if that
extension is at the very end of the ClientHello, it can't be at the end of the
buffer since the ClientHello length is at most SSL_MAX_CONTENT_LEN and the
buffer has some more room after that for MAC and so on. So there is no
buffer overread.
Possible consequences are:
- nothing, if the next byte is 0x00, which is a comment first byte for other
extensions, which is why the bug remained unnoticed
- using a point format that was not offered by the peer if next byte is 0x01.
In that case the peer will reject our ServerKeyExchange message and the
handshake will fail.
- thinking that we don't have a common point format even if we do, which will
cause us to immediately abort the handshake.
None of these are a security issue.
The same bug was fixed client-side in fd35af15
Backport of f7022d1
