Re: [openssl-users] OpenSSL handshake failure with RSA bad signature error
Hi, Could someone shed some light on this above mentioned RSA bad signature issue. Thanks, Senthil. On Thu, Feb 23, 2017 at 12:31 AM, Senthil Raja Velu <vsr...@gmail.com> wrote: > Hi, > I have recently updated my openssl server version from 1.0.1m to 1.0.2j. > After updating the handshake fails with the client. The client still use > openssl version 1.0.1e-fips. > > Note: With older openssl server version (1.0.1m) the handshake works with > the same set of certificates. > > Here is the complete handshake message sequence from the server side with > all debugs: > > TlsInfoCB HANDSHAKE_START(time:4849) sCount(0) cCount(1) > undefined:before/accept initialization > > TlsInfoCB SSL_accept:before/accept initialization > > TlsMsgCB TLS-MSG: <<< ??? len=5 > > TlsHexDumpCB > - 16 03 01 00 94. > > TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=148 ClientHello > > TlsHexDumpCB > - 01 00 00 90 03 03 58 ad-d7 b5 64 af 9e d2 38 c4 ..X...d...8. > 0010 - 4a 8b fc 7c 3b 2f 12 64-68 70 c4 57 73 54 54 ce J..|;/.dhp.WsTT. > 0020 - 82 dd f2 58 c7 85 00 00-24 00 0a 00 2f 00 32 00 ...X$.../.2. > 0030 - 33 00 35 c0 14 c0 03 c0-04 c0 05 c0 08 c0 09 c0 3.5. > 0040 - 0a c0 0d c0 0e c0 0f c0-12 c0 13 00 ff 01 00 00 > 0050 - 43 00 0b 00 04 03 00 01-02 00 0a 00 08 00 06 00 C... > 0060 - 19 00 18 00 17 00 23 00-00 00 0d 00 22 00 20 06 ..#.". . > 0070 - 01 06 02 06 03 05 01 05-02 05 03 04 01 04 02 04 > 0080 - 03 03 01 03 02 03 03 02-01 02 02 02 03 01 01 00 > 0090 - 0f 00 01 01 > > TlsExtCB TLS-EXT: client "EC point formats" (id=11) len=4 > > TlsHexDumpCB > - 03 00 01 02 > > TlsExtCB TLS-EXT: client "elliptic curves" (id=10) len=8 > > TlsHexDumpCB > - 00 06 00 19 00 18 00 17- > > TlsExtCB TLS-EXT: client "session ticket" (id=35) len=0 > > TlsExtCB TLS-EXT: client "signature algorithms" (id=13) len=34 > > TlsHexDumpCB > - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01 . .. > 0010 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03 > 0020 - 01 01 .. > > TlsExtCB TLS-EXT: client "heartbeat" (id=15) len=1 > > TlsHexDumpCB > - 01. > > TlsInfoCB SSL_accept:SSLv3 read client hello A > > TlsMsgCB TLS-MSG: >>> ??? len=5 > > TlsHexDumpCB > - 16 03 03 00 3a: > > TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=58 ServerHello > > TlsHexDumpCB > - 02 00 00 36 03 03 b6 97-ce 9a 96 74 98 52 c0 4a ...6...t.R.J > 0010 - c4 2e f4 20 1f 47 c0 b3-2e e4 8c ed 79 9e 22 e1 ... .G..y.". > 0020 - 57 f9 1f 56 c4 b5 00 00-0a 00 00 0e ff 01 00 01 W..V > 0030 - 00 00 23 00 00 00 0f 00-01 01 ..#... > > TlsInfoCB SSL_accept:SSLv3 write server hello A > > TlsMsgCB TLS-MSG: >>> ??? len=5 > > TlsHexDumpCB > - 16 03 03 04 f1. > > TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=1265 Certificate > > TlsHexDumpCB > - 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82 ..0...0. > 0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f0 30 0d 06 .z.m.M...0.. > 0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b .*.H0N1. > 0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...UUS1.0.. > 0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .UCalifornia > 0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...USanJo > 0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77 se1.0...Uwww > 0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d .nuageCA.com0... > 0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32 140904095750Z..2 > 0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b 40901095750Z0L1. > 00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...UUS1.0.. > 00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .UCalifornia > 00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...USanJo > 00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77 se1.0...Uwww > 00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06 .nuage.com0..0.. > 00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00 .*.H > 0100 - 30 81 89 02 81 81 00 d1-2f 3b 18 80 af 87 aa f3 0.../;.. > 0110 - dd 62 5f
[openssl-users] OpenSSL handshake failure with RSA bad signature error
Hi,
I have recently updated my openssl server version from 1.0.1m to 1.0.2j.
After updating the handshake fails with the client. The client still use
openssl version 1.0.1e-fips.
Note: With older openssl server version (1.0.1m) the handshake works with
the same set of certificates.
Here is the complete handshake message sequence from the server side with
all debugs:
TlsInfoCB HANDSHAKE_START(time:4849) sCount(0) cCount(1)
undefined:before/accept initialization
TlsInfoCB SSL_accept:before/accept initialization
TlsMsgCB TLS-MSG: <<< ??? len=5
TlsHexDumpCB
- 16 03 01 00 94.
TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=148 ClientHello
TlsHexDumpCB
- 01 00 00 90 03 03 58 ad-d7 b5 64 af 9e d2 38 c4 ..X...d...8.
0010 - 4a 8b fc 7c 3b 2f 12 64-68 70 c4 57 73 54 54 ce J..|;/.dhp.WsTT.
0020 - 82 dd f2 58 c7 85 00 00-24 00 0a 00 2f 00 32 00 ...X$.../.2.
0030 - 33 00 35 c0 14 c0 03 c0-04 c0 05 c0 08 c0 09 c0 3.5.
0040 - 0a c0 0d c0 0e c0 0f c0-12 c0 13 00 ff 01 00 00
0050 - 43 00 0b 00 04 03 00 01-02 00 0a 00 08 00 06 00 C...
0060 - 19 00 18 00 17 00 23 00-00 00 0d 00 22 00 20 06 ..#.". .
0070 - 01 06 02 06 03 05 01 05-02 05 03 04 01 04 02 04
0080 - 03 03 01 03 02 03 03 02-01 02 02 02 03 01 01 00
0090 - 0f 00 01 01
TlsExtCB TLS-EXT: client "EC point formats" (id=11) len=4
TlsHexDumpCB
- 03 00 01 02
TlsExtCB TLS-EXT: client "elliptic curves" (id=10) len=8
TlsHexDumpCB
- 00 06 00 19 00 18 00 17-
TlsExtCB TLS-EXT: client "session ticket" (id=35) len=0
TlsExtCB TLS-EXT: client "signature algorithms" (id=13) len=34
TlsHexDumpCB
- 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01 . ..
0010 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03
0020 - 01 01 ..
TlsExtCB TLS-EXT: client "heartbeat" (id=15) len=1
TlsHexDumpCB
- 01.
TlsInfoCB SSL_accept:SSLv3 read client hello A
TlsMsgCB TLS-MSG: >>> ??? len=5
TlsHexDumpCB
- 16 03 03 00 3a:
TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=58 ServerHello
TlsHexDumpCB
- 02 00 00 36 03 03 b6 97-ce 9a 96 74 98 52 c0 4a ...6...t.R.J
0010 - c4 2e f4 20 1f 47 c0 b3-2e e4 8c ed 79 9e 22 e1 ... .G..y.".
0020 - 57 f9 1f 56 c4 b5 00 00-0a 00 00 0e ff 01 00 01 W..V
0030 - 00 00 23 00 00 00 0f 00-01 01 ..#...
TlsInfoCB SSL_accept:SSLv3 write server hello A
TlsMsgCB TLS-MSG: >>> ??? len=5
TlsHexDumpCB
- 16 03 03 04 f1.
TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=1265 Certificate
TlsHexDumpCB
- 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82 ..0...0.
0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f0 30 0d 06 .z.m.M...0..
0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b .*.H0N1.
0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...UUS1.0..
0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .UCalifornia
0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...USanJo
0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77 se1.0...Uwww
0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d .nuageCA.com0...
0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32 140904095750Z..2
0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b 40901095750Z0L1.
00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...UUS1.0..
00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .UCalifornia
00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...USanJo
00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77 se1.0...Uwww
00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06 .nuage.com0..0..
00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00 .*.H
0100 - 30 81 89 02 81 81 00 d1-2f 3b 18 80 af 87 aa f3 0.../;..
0110 - dd 62 5f 96 d6 69 ba 28-cf f6 56 7f c8 56 62 de .b_..i.(..V..Vb.
0120 - 7a 9d fc 6d 26 17 df 0d-5f 09 15 5e 24 68 04 37 z..m&..._..^$h.7
0130 - e0 02 47 e3 18 64 5c 2e-0a 2e 89 57 f9 54 b0 97 ..G..d\W.T..
0140 - 93 24 06 8b 22 55 54 68-89 ea 8d 1d 97 b0 d2 8b .$.."UTh
0150 - 5b 34 19 ba 41 c0 da ca-49 82 d4 76 a3 de 5f fc [4..A...I..v.._.
0160 - cf fa 6b 22 6c 8c c9 af-c2 e4 2b 08 75 cf 3d 5a ..k"l.+.u.=Z
0170 - eb 32 9c 23 ac 6a 09 a7-7a 7b 67 36 08 17 e0 76 .2.#.j..z{g6...v
0180 - a0 9c f5 5b dc 0a a1 02-03 01 00 01 30 0d 06 09 ...[0...
0190 - 2a 86 48 86 f7 0d 01 01-05 05 00 03 81 81 00 09 *.H.
01a0 - ef 65 ee e8 3d b9 5f 11-5c 8a 8b 97 f7 3f 75 78 .e..=._.\?ux
01b0 - f3 11 5f 09 0e b8 fe a0-6b 70 53 1e 34 1b 66 55
Re: [openssl-users] OpenSSL handshake failure in ssl3_get_client_hello() routine
Thanks again! -Senthil. On Thu, Jan 26, 2017 at 9:27 PM, Matt Caswell <m...@openssl.org> 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
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 <vsr...@gmail.com> 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 <m...@openssl.org> 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
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 <m...@openssl.org> 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 handshake failure in ssl3_get_client_hello() routine
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.
Both server and client are written in C and are in non-blocking mode. I
have added InfoCallBack and printCallBack routines on the server side.
On the server side application, I have set the following options;
pCtx = SSL_CTX_new(SSLv23_server_method());
SSL_CTX_set_options(pCtx, SSL_OP_NO_SSLv2);
SSL_CTX_set_options(pCtx, SSL_OP_NO_SSLv3);
SSL_CTX_set_options(pCtx, SSL_OP_NO_TLSv1);
Now when the failure occurs, I get the following error message on the
server side:
InfoCB
HANDSHAKE_START(time:5093879) undefined: before/accept initialization
InfoCB
SSL_accept:before/accept initialization
InfoCB
SSL3 alert write:fatal:internal error
PrintCB
error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal
error:/server/openssl/ssl/s3_srvr.c:1265:
InfoCB
SSL_accept:error in SSLv3 read client hello C
InfoCB
SSL_accept:error in SSLv3 read client hello C
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.
I do not hit this issue always.
Any pointers on addressing this issue will be a big help.
Thanks,
Senthil.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
