Extend SSL_CONF to return command value types.
Add certificate and key options.
Update documentation.
(cherry picked from commit ec2f7e568ea18a22ab57326fffe78ef2aa6884f5)
PR: 2808
With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and
FORWARD-TSN chunks. The key for this extension is derived from the
master secret and changed with the next ChangeCipherSpec, whenever a new
key has been negotiated. The following Finished then already uses the
new key. Unfortunately, the ChangeCipherSpec and Finished are part of
the same flight as the ClientKeyExchange, which is necessary for the
computation of the new secret. Hence, these messages are sent
immediately following each other, leaving the server very little time to
compute the new secret and pass it to SCTP before the finished arrives.
So the Finished is likely to be discarded by SCTP and a retransmission
becomes necessary. To prevent this issue, the Finished of the client is
still sent with the old key.
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.
This is a forward-port of commits:
4af793036f6ef4f0a1078e5d7155426a98d50e37
f4c93b46edb51da71f09eda99e83eaf193a33c08
3da721dac9382c48812c8eba455528fd59af2eef
2583270191a8b27eed303c03ece1da97b9b69fd3
While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear. This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:
* It's quite possible to open two TLS connections in one second.
* If the PRNG output is prone to repeat itself, ephemeral
handshakes (and who knows what else besides) are broken.
Removing RSA+MD5 from the default signature algorithm list
prevents its use by default.
If a broken implementation attempts to use RSA+MD5 anyway the sanity
checking of signature algorithms will cause a fatal alert.
(cherry picked from commit 77a0f740d00ecf8f6b01c0685a2f858c3f65a3dd)
Make DTLS behave like TLS when negotiating version: record layer has
DTLS 1.0, message version is 1.2.
Tolerate different version numbers if version hasn't been negotiated
yet.
(cherry picked from commit 40088d8b8190a2a33828a769c23bf35de542c7dc)
Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.
Add code to d1_pkt.c to send message headers to the message callback.
(cherry picked from commit 890f2f8b92b385ef3898cdb4a15a071ffcf8107f)
Conflicts:
ssl/ssl_locl.h
Check for Suite B support using method flags instead of version numbers:
anything supporting TLS 1.2 cipher suites will also support Suite B.
Return an error if an attempt to use DTLS 1.0 is made in Suite B mode.
(cherry picked from commit 4544f0a69161a37ee3edce3cc1bc34c3678a4d64)
If we successfully match a cookie don't set return value to 2 as this
results in other error conditions returning 2 as well.
Instead set return value to -2 which can be checked later if everything
else is OK.
(cherry picked from commit c56f5b8edfbcec704f924870daddd96a5f768fbb)
Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.
As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.
(cherry picked from commit c6913eeb762edffddecaaba5c84909d7a7962927)
Conflicts:
CHANGES
Port TLS 1.2 GCM code to DTLS. Enable use of TLS 1.2 only ciphers when in
DTLS 1.2 mode too.
(cherry picked from commit 4221c0dd3004117c63b182af5e8ab345b7265902)
Add DTLS1.2 support for cached records when computing handshake macs
instead of the MD5+SHA1 case for DTLS < 1.2 (this is a port of the
equivalent TLS 1.2 code to DTLS).
(cherry picked from commit 04fac50045929e7078cad4835478dd7f16b6d4bd)
Add correct flags for DTLS 1.2, update s_server and s_client to handle
DTLS 1.2 methods.
Currently no support for version negotiation: i.e. if client/server selects
DTLS 1.2 it is that or nothing.
(cherry picked from commit c3b344e36a088283731b4f65a70e85b100f55686)
Conflicts:
apps/s_server.c
Since this is always called from DTLS code it is safe to assume the header
length should be the DTLS value. This avoids the need to check the version
number and should work with any version of DTLS (not just 1.0).
(cherry picked from commit 9cf0f187542f080031f83c5e538d3e1872ac09d1)
Extend DTLS method creation macros to support version numbers and encryption
methods. Update existing code.
(cherry picked from commit cfd298b7aef2b095bee8d172a6a40d6c59d1574b)
Some TLS extensions were disabled for DTLS. Possibly because they caused
problems with the old duplicated code. Enable them again.
(cherry picked from commit 874a18cfadc6bac0ad73482325f2ca72dfccdb82)
Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.
(cherry picked from commit cbd64894ec687c6f37d8e43c16dff78e63f6be87)
Conflicts:
ssl/ssl_locl.h
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
(cherry picked from commit 173e72e64c6a07ae97660c322396b66215009f33)
This change adds support for ALPN[1] in OpenSSL. ALPN is the IETF
blessed version of NPN and we'll be supporting both ALPN and NPN for
some time yet.
Cherry-picked from 6f017a8f9db3a79f3a3406cf8d493ccd346db691.
[1] https://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
(cherry picked from commit b62f4daac00303280361924b9cc19b3e27528b15)
Reported by: Prashant Jaikumar <rmstar@gmail.com>
Fix handling of application data received before a handshake.
(cherry picked from commit 0c75eeacd3285b395dc75b65c3e6fe6ffbef59f0)
