date:20170126

Re: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

2017-01-26 Thread Ethan Rahn

Scott, I just checked the CVE ID's on mitre, and as of now ( 11:18 AM PST
1/26/17 ) they are all listed as 'reserved' and don't have any information
about the issue. NVD shows the same information. In either case, it seems
like an extra hoop to jump through to have to go to a third party site to
find a commit #, when the third party chooses to release the information.

On Thu, Jan 26, 2017 at 10:53 AM, Scott Neugroschl 
wrote:

> The CVE itself contains the commit info.  Find it at cve.mitre.org
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Ethan Rahn
> *Sent:* Thursday, January 26, 2017 10:40 AM
> *To:* openssl-users@openssl.org
> *Subject:* [openssl-users] Should openssl publish the commit #'s that
> fixed each CVE?
>
>
>
> Hello,
>
>
>
> When looking a the latest security announcement, something that I notice
> is that it's hard to find the actual commits that fixed an issue. If you
> search git.openssl.org you can find some of them if they are mentioned in
> the change message, but it still requires some active effort.
>
>
>
> Would it be a good idea for openssl to publish the commit(s) that fixed
> each CVE? It would make it easier to see what changed, which is great for
>
> a.) backporting.
>
> b.) satisfying curiosity of armchair cryptographers.
>
> c.) better assessing an issue.
>
>
>
> Cheers,
>
>
>
> Ethan
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

2017-01-26 Thread Scott Neugroschl

The CVE itself contains the commit info.  Find it at cve.mitre.org

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Ethan Rahn
Sent: Thursday, January 26, 2017 10:40 AM
To: openssl-users@openssl.org
Subject: [openssl-users] Should openssl publish the commit #'s that fixed each 
CVE?

Hello,

When looking a the latest security announcement, something that I notice is 
that it's hard to find the actual commits that fixed an issue. If you search 
git.openssl.org you can find some of them if they are 
mentioned in the change message, but it still requires some active effort.

Would it be a good idea for openssl to publish the commit(s) that fixed each 
CVE? It would make it easier to see what changed, which is great for
a.) backporting.
b.) satisfying curiosity of armchair cryptographers.
c.) better assessing an issue.

Cheers,

Ethan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Should openssl publish the commit #'s that fixed each CVE?

2017-01-26 Thread Ethan Rahn

Hello,

When looking a the latest security announcement, something that I notice is
that it's hard to find the actual commits that fixed an issue. If you
search git.openssl.org you can find some of them if they are mentioned in
the change message, but it still requires some active effort.

Would it be a good idea for openssl to publish the commit(s) that fixed
each CVE? It would make it easier to see what changed, which is great for
a.) backporting.
b.) satisfying curiosity of armchair cryptographers.
c.) better assessing an issue.

Cheers,

Ethan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

2017-01-26 Thread Senthil Raja Velu

Thanks again!

-Senthil.


On Thu, Jan 26, 2017 at 9:27 PM, Matt Caswell  wrote:

>
>
> On 26/01/17 15:53, Senthil Raja Velu wrote:
> > Hi Matt,
> > One other quick question, Is there a openssl utility code to just check
> > PRNG is initialized or NOT_SEEDED.
>
> See RAND_status().
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

2017-01-26 Thread Matt Caswell



On 26/01/17 15:53, Senthil Raja Velu wrote:
> Hi Matt,
> One other quick question, Is there a openssl utility code to just check
> PRNG is initialized or NOT_SEEDED.

See RAND_status().

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

2017-01-26 Thread Senthil Raja Velu

Hi Matt,
One other quick question, Is there a openssl utility code to just check
PRNG is initialized or NOT_SEEDED.
That way I could verify the current running state of the application. The
other thing I am after is, it works some times but not other times.

Thanks,
Senthil.


On Thu, Jan 26, 2017 at 8:54 PM, Senthil Raja Velu  wrote:

> Hi Matt,
> Thanks for such a detailed reply. I will work on the pointers provided.
> And will plan to move openssl implementation to 1.0.2 series as suggested.
> I will check the random method used if that is the cause of this issue.
>
> Many thanks,
> Senthil.
>
>
> On Thu, Jan 26, 2017 at 3:38 PM, Matt Caswell  wrote:
>
>>
>>
>> On 26/01/17 04:38, Senthil Raja Velu wrote:
>> > Hi,
>> > I have a setup where the handshake between openssl server and client
>> > fails at times but not always. And when it does,  the client keeps
>> > retrying and all of trials fail. Only way to recover is to restart the
>> > server.
>> >
>> > Currently on the server side the openssl version that I have installed
>> > is 1.0.1m.
>>
>> That's quite an old version and is likely to be vulnerable to various
>> security issues. You should upgrade. Further the 1.0.1 series is no
>> longer supported (unless your 1.0.1m is actually supplied by your OS
>> vendor - in which case they may be backporting security fixes to it). If
>> you are not using an OS supplied version then I recommend you upgrade to
>> version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
>> (which may be more difficult). Those versions will be released later
>> today.
>>
>> > The SSL code path  refers to the
>> > following section of code in ssl3_get_client_hello() routine in
>> s3_srvr.c.
>> >
>> > 
>> --
>> > /*
>> >  * Check if we want to use external pre-shared secret for this
>> handshake
>> >  * for not reused session only. We need to generate server_random
>> before
>> >  * calling tls_session_secret_cb in order to allow SessionTicket
>> >  * processing to use it in key derivation.
>> >  */
>> > {
>> > unsigned char *pos;
>> > pos = s->s3->server_random;
>> > if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
>> > #ifdef USER_EXTENSIONS
>> > SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
>> > #endif // USER_EXTENSIONS
>> > goto f_err;
>> > }
>> > }
>> > 
>> --
>> >
>> > Note, I have edited the SSL library to include this USER_EXTENSIONS
>> > section, so that I could confirm where exactly this issue is happening
>> > in the library.
>> >
>> > Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
>> > less than zero.
>>
>> Well zero or less to be exact. The code for ssl_fill_hello_random()
>> looks like this:
>>
>> int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
>> len)
>> {
>> int send_time = 0;
>>
>> if (len < 4)
>> return 0;
>> if (server)
>> send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
>> else
>> send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
>> if (send_time) {
>> unsigned long Time = (unsigned long)time(NULL);
>> unsigned char *p = result;
>> l2n(Time, p);
>> return RAND_pseudo_bytes(p, len - 4);
>> } else
>> return RAND_pseudo_bytes(result, len);
>> }
>>
>>
>> As you can see it can return 0 if len < 4 - but in this case it is clear
>> that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).
>>
>> Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
>> reasons why that function returns <= 0:
>>
>> 1) It can't find the random method to use (either built-in or default).
>> This is really a "should never happen" type condition.
>>
>> 2) If using the default random method then it has insufficient entropy.
>>
>> 3) If using an engine supplied random method, then it has failed for
>> some engine specific reason.
>>
>> Are you using an engine that might supply its own random method? If so
>> you might want to look at whether that is failing.
>>
>> If not, then look here:
>> https://www.openssl.org/docs/faq.html#USER1
>>
>> Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
>> would probably get an additional error message confirming that it is a
>> low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
>> changed to RAND_bytes(). These two are very similar, but on failure due
>> to low entropy RAND_bytes() puts an error in the error queue.
>>
>> Matt
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

2017-01-26 Thread Senthil Raja Velu

Hi Matt,
Thanks for such a detailed reply. I will work on the pointers provided. And
will plan to move openssl implementation to 1.0.2 series as suggested. I
will check the random method used if that is the cause of this issue.

Many thanks,
Senthil.


On Thu, Jan 26, 2017 at 3:38 PM, Matt Caswell  wrote:

>
>
> On 26/01/17 04:38, Senthil Raja Velu wrote:
> > Hi,
> > I have a setup where the handshake between openssl server and client
> > fails at times but not always. And when it does,  the client keeps
> > retrying and all of trials fail. Only way to recover is to restart the
> > server.
> >
> > Currently on the server side the openssl version that I have installed
> > is 1.0.1m.
>
> That's quite an old version and is likely to be vulnerable to various
> security issues. You should upgrade. Further the 1.0.1 series is no
> longer supported (unless your 1.0.1m is actually supplied by your OS
> vendor - in which case they may be backporting security fixes to it). If
> you are not using an OS supplied version then I recommend you upgrade to
> version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
> (which may be more difficult). Those versions will be released later today.
>
> > The SSL code path  refers to the
> > following section of code in ssl3_get_client_hello() routine in
> s3_srvr.c.
> >
> > 
> --
> > /*
> >  * Check if we want to use external pre-shared secret for this
> handshake
> >  * for not reused session only. We need to generate server_random
> before
> >  * calling tls_session_secret_cb in order to allow SessionTicket
> >  * processing to use it in key derivation.
> >  */
> > {
> > unsigned char *pos;
> > pos = s->s3->server_random;
> > if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
> > #ifdef USER_EXTENSIONS
> > SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
> > #endif // USER_EXTENSIONS
> > goto f_err;
> > }
> > }
> > 
> --
> >
> > Note, I have edited the SSL library to include this USER_EXTENSIONS
> > section, so that I could confirm where exactly this issue is happening
> > in the library.
> >
> > Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
> > less than zero.
>
> Well zero or less to be exact. The code for ssl_fill_hello_random()
> looks like this:
>
> int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
> len)
> {
> int send_time = 0;
>
> if (len < 4)
> return 0;
> if (server)
> send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
> else
> send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
> if (send_time) {
> unsigned long Time = (unsigned long)time(NULL);
> unsigned char *p = result;
> l2n(Time, p);
> return RAND_pseudo_bytes(p, len - 4);
> } else
> return RAND_pseudo_bytes(result, len);
> }
>
>
> As you can see it can return 0 if len < 4 - but in this case it is clear
> that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).
>
> Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
> reasons why that function returns <= 0:
>
> 1) It can't find the random method to use (either built-in or default).
> This is really a "should never happen" type condition.
>
> 2) If using the default random method then it has insufficient entropy.
>
> 3) If using an engine supplied random method, then it has failed for
> some engine specific reason.
>
> Are you using an engine that might supply its own random method? If so
> you might want to look at whether that is failing.
>
> If not, then look here:
> https://www.openssl.org/docs/faq.html#USER1
>
> Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
> would probably get an additional error message confirming that it is a
> low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
> changed to RAND_bytes(). These two are very similar, but on failure due
> to low entropy RAND_bytes() puts an error in the error queue.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Security Advisory

2017-01-26 Thread OpenSSL

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [26 Jan 2017]


Truncated packet could crash via OOB read (CVE-2017-3731)
=

Severity: Moderate

If an SSL/TLS server or client is running on a 32-bit host, and a specific
cipher is being used, then a truncated packet can cause that server or client
to perform an out-of-bounds read, usually resulting in a crash.

For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305;
users should upgrade to 1.1.0d

For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have
not disabled that algorithm should update to 1.0.2k

This issue was reported to OpenSSL on 13th November 2016 by Robert Święcki of
Google. The fix was developed by Andy Polyakov of the OpenSSL development team.

Bad (EC)DHE parameters cause a client crash (CVE-2017-3730)
===

Severity: Moderate

If a malicious server supplies bad parameters for a DHE or ECDHE key exchange
then this can result in the client attempting to dereference a NULL pointer
leading to a client crash. This could be exploited in a Denial of Service
attack.

OpenSSL 1.1.0 users should upgrade to 1.1.0d

This issue does not affect OpenSSL version 1.0.2.

Note that this issue was fixed prior to it being recognised as a security
concern. This means the git commit with the fix does not contain the CVE
identifier. The relevant fix commit can be identified by commit hash efbe126e3.

This issue was reported to OpenSSL on 14th January 2017 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

BN_mod_exp may produce incorrect results on x86_64 (CVE-2017-3732)
==

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.

OpenSSL 1.1.0 users should upgrade to 1.1.0d
OpenSSL 1.0.2 users should upgrade to 1.0.2k

This issue was reported to OpenSSL on 15th January 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.

Montgomery multiplication may produce incorrect results (CVE-2016-7055)
===

Severity: Low

This issue was previously fixed in 1.1.0c and covered in security advisory
https://www.openssl.org/news/secadv/20161110.txt

OpenSSL 1.0.2k users should upgrade to 1.0.2k


Note


Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20170126.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYifonAAoJENnE0m0OYESRnhYH/1ldFYDEZ894DleZfjRrZulX
OQkEH7w6v+D6YFp8i2v6rJaDq8caOPEhzupQCxPcqYitBUnww9UzUvYJ77aBV0CG
DQ3UvE9XeEn5D7MGAGq/ut5Z5WpvlYL7n7PaciX751vpTsWTBKfGecQ8YV0aT6y+
7V7vHz6NVFnuTQDMUYs9C9aTsCDTNy3Bl84d7gYyoDWXUXds5k008g9LFRI4YQ8l
+4z+GXRVcvAFr6fKH94Yq1RMAp6cJi0RDkyuwcGhSOUwVfSLTN8+i2v4xqzKgsx1
q2qPo3+7uederE5ZaNZScl0xAzEilotxLQyy9XSVx/DDXHz0in1500qxgxNFELU=
=12E/
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL version 1.1.0d published

2017-01-26 Thread OpenSSL

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.0d released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0d of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0d is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.0d.tar.gz
  Size: 5201626
  SHA1 checksum: f423e9253ad8a8617fc9fb3562788a9fa066d46f
  SHA256 checksum: 
7d5ebb9e89756545c156ff9c13cf2aa6214193b010a468a3bc789c3c28fe60df

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.0d.tar.gz
openssl sha256 openssl-1.1.0d.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYifVEAAoJENnE0m0OYESRcPYH/AqSYRJDURNli0/PhHa45ynT
eXGk5v44l0q/TBqHOiUjPEAE6ctMe+Dg2Bw+2UI5msGZDyD+alksUrf94OzFMIll
UC3FPAyAAIxu/DNyL/tRyGwBqOyHrzvKzwl+yGnOtzQ/a9/la79KCSTUMheDDBgk
2LiPoGi35wfNpJ+jBr/ucPto15+dWQfTMxX8aeYWkdVjUGGcO4XmAuqpIo5Jl7gw
szSzpgvLB55sRZ8o6edU9knoIGRad+TH9JjfKAIzAIUH5BWaALmswQUMWhKTQkpX
jHosHsLUPBLqqPJtmlLr1T7bHXGqz3fvQF0/lHYKA9eQDm0Owd0izeJlsiqaCac=
=WZYB
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL version 1.0.2k published

2017-01-26 Thread OpenSSL

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.0.2k released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2k of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2k is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.2k.tar.gz
  Size: 5309236
  SHA1 checksum: 5f26a624479c51847ebd2f22bb9f84b3b44dcb44
  SHA256 checksum: 
6b3977c61f2aedf0f96367dcfb5c6e578cf37e7b8d913b4ecb6643c3cb88d8c0

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.0.2k.tar.gz
openssl sha256 openssl-1.0.2k.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYifggAAoJENnE0m0OYESRHWUIAJXlSdrySe40QGFuOfSUQya0
iWTa0PcIPCPjSaM1Rige1BMSwTVhWwNmdimAyG94I1/y6uAoJzFsfNs4xSPlsGGO
9pdAiqeu9GAnJ3z4H/mkasUAmzXkemeWt5dN9KdANbT7HAg+ROKmthrmWiffftoU
x+sGZ/lThIfKIYf+Ch5EmM4VFuCU9gG6YTwlUSKQAcnmcPt1AVrGlSxyVTx1Ahku
Pl3iYbQors6vfBlh4BZZnxh7NJW4WRpJ77+1OH8xaOobJQMDZ5VQqnPMIIbbMLoM
MAJz7T0nfzTaQ8Yzwv078qNPuwzeumI92NGybETbOI8zThHdEffsOegBaHqV+Jk=
=KDh3
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

2017-01-26 Thread Matt Caswell

On 26/01/17 04:38, Senthil Raja Velu wrote:
> Hi,
> I have a setup where the handshake between openssl server and client
> fails at times but not always. And when it does,  the client keeps
> retrying and all of trials fail. Only way to recover is to restart the
> server.
> 
> Currently on the server side the openssl version that I have installed
> is 1.0.1m.

That's quite an old version and is likely to be vulnerable to various
security issues. You should upgrade. Further the 1.0.1 series is no
longer supported (unless your 1.0.1m is actually supplied by your OS
vendor - in which case they may be backporting security fixes to it). If
you are not using an OS supplied version then I recommend you upgrade to
version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
(which may be more difficult). Those versions will be released later today.

> The SSL code path  refers to the
> following section of code in ssl3_get_client_hello() routine in s3_srvr.c.
> 
> --
> /*
>  * Check if we want to use external pre-shared secret for this handshake
>  * for not reused session only. We need to generate server_random before
>  * calling tls_session_secret_cb in order to allow SessionTicket
>  * processing to use it in key derivation.
>  */
> {
> unsigned char *pos;
> pos = s->s3->server_random;
> if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
> #ifdef USER_EXTENSIONS
> SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
> #endif // USER_EXTENSIONS
> goto f_err;
> }
> }
> --
> 
> Note, I have edited the SSL library to include this USER_EXTENSIONS
> section, so that I could confirm where exactly this issue is happening
> in the library.
> 
> Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
> less than zero.

Well zero or less to be exact. The code for ssl_fill_hello_random()
looks like this:

int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
len)
{
int send_time = 0;

if (len < 4)
return 0;
if (server)
send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
else
send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
if (send_time) {
unsigned long Time = (unsigned long)time(NULL);
unsigned char *p = result;
l2n(Time, p);
return RAND_pseudo_bytes(p, len - 4);
} else
return RAND_pseudo_bytes(result, len);
}

As you can see it can return 0 if len < 4 - but in this case it is clear
that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).

Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
reasons why that function returns <= 0:

1) It can't find the random method to use (either built-in or default).
This is really a "should never happen" type condition.

2) If using the default random method then it has insufficient entropy.

3) If using an engine supplied random method, then it has failed for
some engine specific reason.

Are you using an engine that might supply its own random method? If so
you might want to look at whether that is failing.

If not, then look here:
https://www.openssl.org/docs/faq.html#USER1

Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
would probably get an additional error message confirming that it is a
low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
changed to RAND_bytes(). These two are very similar, but on failure due
to low entropy RAND_bytes() puts an error in the error queue.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

Re: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

[openssl-users] Should openssl publish the commit #'s that fixed each CVE?

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

[openssl-users] OpenSSL Security Advisory

[openssl-users] OpenSSL version 1.1.0d published

[openssl-users] OpenSSL version 1.0.2k published

Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine

11 matches

Site Navigation

Mail list logo

Footer information