Only the tests with client authentication failed, the client accepted
the trusted self-signed certificate even when it was expired. On the
server the lookup (based on the pre-configured SAN) first found the ECDSA
cert, which it dismissed for the RSA authentication the client used, and
since only the first "pretrusted" cert is considered the following RSA
cert was verified more thoroughly.
The lookup on the client always uses the full DN of the server certificate
not the pre-configured identity so it found the correct certificate on
the first try.
While the server signs the ephemeral DH parameters, it can be tricked to its
lowest supported DH group by a man-in-the-middle:
https://weakdh.org/imperfect-forward-secrecy.pdf
While we at least use 2048-bit DH groups as server, the client accepts any
DH prime the server sends. If it supports export ciphers, only a 512-bit prime
may be used.
As TLS does not define nor negotiate a DH group for cipher suites, the client
actually must accept what the server offers. To avoid downgrades to weak
DH groups, we must reject what we consider insecure. We set this limit to
1024-bit primes. While this breaks compatibility with TLS servers using weaker
primes, this is what we expect servers at least use. Most browser vendors use
the same limit in a similar fix.
In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.
Fixes#849.
With the introduction of PT-TLS, we started sending TLS close notifies after
the application layer completes (7bbf7aa9). While this makes sense for TCP based
transports, it is not required in EAP methods. In EAP, handshake completion
can be directly signaled using the outer EAP-SUCCESS message. This also saves
one round-trip in the EAP exchange.
Windows 7/8 does not seem to like TLS close notifies at all in EAP, and either
stalls (EAP-TTLS) or disconnects (PEAP).
Fixes#556.
A type is returned only if upper layers successfully created a record, that is
returns NEED_MORE. If we do not check for the return value, we might check a
previous record or the uninitialized type variable and falsely reset the
sequence number.
When running the tests in GDB the working directory apparently is
different. With the relative path used previously the plugins would not
be found and those installed on the system would get used.
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
While a hardcoded 1.2 version is fine when we offer that in Client Hello, we
should include the actually offered version if it has been reduced before
starting the exchange.
Fixes fragment reassembling if a buffer contains more than one record, but
the last record contains a partial TLS record header. Thanks to Nick Saunders
and Jamil Nimeh for identifying this issue and providing a fix for it.
Tobias Brunner