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
By looking just at that test, it looks like 2 + dn_size could overflow. In
fact that can't happen as that would mean we've read a CA cert of size is too
big to be represented by a size_t.
However, it's best for code to be more obviously free of overflow without
having to reason about the bigger picture.
In case an entry with the given OID already exists in the list passed to
mbedtls_asn1_store_named_data() and there is not enough memory to allocate
room for the new value, the existing entry will be freed but the preceding
entry in the list will sill hold a pointer to it. (And the following entries
in the list are no longer reachable.) This results in memory leak or a double
free.
The issue is we want to leave the list in a consistent state on allocation
failure. (We could add a warning that the list is left in inconsistent state
when the function returns NULL, but behaviour changes that require more care
from the user are undesirable, especially in a stable branch.)
The chosen solution is a bit inefficient in that there is a time where both
blocks are allocated, but at least it's safe and this should trump efficiency
here: this code is only used for generating certificates, which is unlikely to
be done on very constrained devices, or to be in the critical loop of
anything. Also, the sizes involved should be fairly small anyway.
fixes#367
When the peer retransmits a flight with many record in the same datagram, and
we already saw one of the records in that datagram, we used to drop the whole
datagram, resulting in interoperability failure (spurious handshake timeouts,
due to ignoring record retransmitted by the peer) with some implementations
(issues with Chrome were reported).
So in those cases, we want to only drop the current record, and look at the
following records (if any) in the same datagram. OTOH, this is not something
we always want to do, as sometime the header of the current record is not
reliable enough.
This commit introduces a new return code for ssl_parse_header() that allows to
distinguish if we should drop only the current record or the whole datagram,
and uses it in mbedtls_ssl_read_record()
fixes#345
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
Not a security issue as here we know the buffer is large enough (unless
something else if badly wrong in the code), and the value cast to int is less
than 2^16 (again, unless issues elsewhere).
Still changing to a more correct check as a matter of principle
In BER encoding, any boolean with a non-zero value is considered as
TRUE. However, DER encoding require a value of 255 (0xFF) for TRUE.
This commit makes `mbedtls_asn1_write_bool` function uses `255` instead
of `1` for BOOLEAN values.
With this fix, boolean values are now reconized by OS X keychain (tested
on OS X 10.11).
Fixes#318.
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
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.
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
Especially for resumed handshake, it's entirely possible for an epoch=0
ClientHello to be retransmitted or arrive so late that the server is already
at epoch=1. There is no good way to detect whether it's that or a reconnect.
However:
- a late ClientHello seems more likely that client going down and then up
again in the middle of a handshake
- even if that's the case, we'll time out on that handshake soon enough
- we don't want to break handshake flows that used to work
So the safest option is to not treat that as a reconnect.
