- Jan 24, 2017
-
-
Matt Caswell authored
SSL_get0_raw_cipherlist() was a little too "raw" in the case of an SSLv2 compat ClientHello. In 1.0.2 and below, during version negotiation, if we received an SSLv2 compat ClientHello but actually wanted to do SSLv3+ then we would construct a "fake" SSLv3+ ClientHello. This "fake" ClientHello would have its ciphersuite list converted to the SSLv3+ format. It was this "fake" raw list that got saved away to later be returned by a call to SSL_get0_raw_cipherlist(). In 1.1.0+ version negotiation works differently and we process an SSLv2 compat ClientHello directly without the need for an intermediary "fake" ClientHello. This meant that the raw ciphersuite list being saved was in the SSLv2 format. Any caller of this function would not expect that and potentially overread the returned buffer by one byte. Fixes #2189 Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2280)
-
Kazuki Yamaguchi authored
ChaCha20 code uses its own custom cipher_data. Add EVP_CIPH_CUSTOM_IV and EVP_CIPH_ALWAYS_CALL_INIT so that the key and the iv can be set by different calls of EVP_CipherInit_ex(). Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
-
Bernd Edlinger authored
- s == NULL can mean c is a new session *or* lh_insert was unable to create a hash entry. - use lh_SSL_SESSION_retrieve to check for this error condition. - If it happens simply remove the extra reference again. Reviewed-by:
-
ganesh authored
Reviewed-by:
-
ganesh authored
According to the documentation, the return code should be -1 when RAND_status does not return 1. Reviewed-by:
-
ganesh authored
Reviewed-by:
-
- Jan 23, 2017
-
-
Andy Polyakov authored
This comes from a comment in GH issue #1027. Andy wrote the code, Rich made the PR. Reviewed-by:
Andy Polyakov <appro@openssl.org> Reviewed-by:
-
Cory Benfield authored
Reviewed-by:
-
Cory Benfield authored
Reviewed-by:
-
Cory Benfield authored
Reviewed-by:
-
Richard Levitte authored
It seems that the ssl test 20-cert-select.conf dislikes the lack of TLSv1.2 Reviewed-by:
-
FdaSilvaYY authored
it was getting the SerialNumber of a previous cert. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2272)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
In a non client-auth renegotiation where the original handshake *was* client auth, then the server will expect the client to send a Certificate message anyway resulting in a connection failure. Reviewed-by:
-
Matt Caswell authored
In a non client-auth renegotiation where the original handshake *was* client auth, then the client will send a Certificate message anyway resulting in a connection failure. Fixes #1920 Reviewed-by:
-
Matt Caswell authored
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows: B<Server mode:> only request a client certificate on the initial TLS/SSL handshake. Do not ask for a client certificate again in case of a renegotiation. This flag must be used together with SSL_VERIFY_PEER. B<Client mode:> ignored But the implementation actually did nothing. After the server sends its ServerKeyExchange message, the code was checking s->session->peer to see if it is NULL. If it was set then it did not ask for another client certificate. However s->session->peer will only be set in the event of a resumption, but a ServerKeyExchange message is only sent in the event of a full handshake (i.e. no resumption). The documentation suggests that the original intention was for this to have an effect on renegotiation, and resumption doesn't come into it. The fix is to properly check for renegotiation, not whether there is already a client certificate in the session. As far as I can tell this has been broken for a *long* time. Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
Kurt Roeckx <kurt@openssl.org> Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
- Jan 21, 2017
-
-
Andy Polyakov authored
Reviewed-by: -
Andy Polyakov authored
Up to 4% depending on benchmark. Reviewed-by: -
Gaétan Njinang authored
The difference between the AIX MD5 password algorithm and the standard MD5 password algorithm is that in AIX there is no magic string while in the standard MD5 password algorithm the magic string is "$1$" Documentation of '-aixmd5' option of 'openssl passwd' command is added. 1 test is added in test/recipes/20-test-passwd.t Reviewed-by:
-
- Jan 20, 2017
-
-
Richard Levitte authored
When setting the digest parameter for DSA parameter generation, the signature MD was set instead of the parameter generation one. Fortunately, that's also the one that was used for parameter generation, but it ultimately meant the parameter generator MD and the signature MD would always be the same. Fixes github issue #2016 Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
- Jan 19, 2017
-
-
Markus Triska authored
CLA: trivial Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
- Jan 18, 2017
-
-
Rich Salz authored
Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1597)
-
Rich Salz authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
FdaSilvaYY authored
... mostly related to some old discarded modules . Reviewed-by:
-
FdaSilvaYY authored
Reviewed-by:
-
Markus Triska authored
Reviewed-by:
-
- Jan 17, 2017
-
-
EasySec authored
Reviewed-by:
-
- Jan 16, 2017
-
-
xemdetia authored
CLA: trivial Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
- Jan 15, 2017
-
-
Kurt Roeckx authored
Found by oss-fuzz Reviewed-by: -
Kurt Roeckx authored
Reviewed-by: -
Kurt Roeckx authored
Found by afl Reviewed-by: -
Dr. Stephen Henson authored
Reviewed-by:
Emilia Käsper <emilia@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2224)
-
