Reported-by: Claus Assmann

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Also tweak some of the code in demos/bio, to enable interactive
testing of BIO_s_accept's use of SSL_dup.  Changed the sconnect
client to authenticate the server, which now exercises the new
SSL_set1_host() function.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>

If there's a failure allocating md_data, the destination pctx will have
a shared pointer with the source EVP_MD_CTX, which will lead to problems
when either the source or the destination is freed.

Reviewed-by: Stephen Henson <steve@openssl.org>

The protocol selection code is now consolidated in a few consecutive
short functions in a single file and is table driven.  Protocol-specific
constraints that influence negotiation are moved into the flags
field of the method structure.  The same protocol version constraints
are now applied in all code paths.  It is now much easier to add
new protocol versions without reworking the protocol selection
logic.

In the presence of "holes" in the list of enabled client protocols
we no longer select client protocols below the hole based on a
subset of the constraints and then fail shortly after when it is
found that these don't meet the remaining constraints (suiteb, FIPS,
security level, ...).  Ideally, with the new min/max controls users
will be less likely to create "holes" in the first place.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>

It served a purpose, but not any more.

Reviewed-by: Stephen Henson <steve@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

SIZE_MAX is a great macro, and does unfortunately not exist everywhere.
Since we check against half of it, using bitwise shift to calculate the
value of half SIZE_MAX should be safe enough.

Reviewed-by: Tim Hudson <tjh@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

If DSA parameters are absent return -1 (for unknown) in DSA_security_bits.

If parameters are absent when a certificate is set in an SSL/SSL_CTX
structure this will reject the certificate by default. This will cause DSA
certificates which omit parameters to be rejected but that is never (?)
done in practice.

Thanks to Brian 'geeknik' Carpenter for reporting this issue.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reuse is deprecated and ReuseAddr is prefered, according to documentation.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

Previous versions of OpenSSL had the max size limit for a CertificateRequest
message as |s->max_cert_list|. Previously master had it to be
SSL3_RT_MAX_PLAIN_LENGTH. However these messages can get quite long if a
server is configured with a long list of acceptable CA names. Therefore
the size limit has been increased to be consistent with previous versions.

RT#4198

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Move all calls of the OCSP callback into one place, rather than repeating it
in two different places.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Describe the usage of the OCSP callback functions on both the client and
the server side.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

It makes no sense to call the OCSP status callback if we are resuming a
session because no certificates will be sent.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

If a server sends the status_request extension then it may choose
to send the CertificateStatus message. However this is optional.
We were treating it as mandatory and the connection was failing.

Thanks to BoringSSL for reporting this issue.

RT#4120

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

If the client sends a status_request extension in the ClientHello
and the server responds with a status_request extension in the
ServerHello then normally the server will also later send a
CertificateStatus message. However this message is *optional* even
if the extensions were sent. This adds a test to ensure that if
the extensions are sent then we can still omit the message.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

RT: #4192, MR: #1533