"Client Hello" from HP Insight Manager crashes application

[Josue Andrade Gomes-2]

Hi,

Shortly: HP Insight Manager (a management tool) crashes my server SSL
application.
Operating system: Windows 2003 Server
OpenSSL version: 0.9.8k
Post-mortem debugger points the crash ocurring in a call to
CRYPTO_malloc() inside SSLv3_client_method()
(wich is weird since I never call this function).

Any idea? Have someone seen this already?

regards,
josue

The packet that causes the crash:

No.     Time        Source                Destination           Protocol Info
  34446 117.798401  <removed> <removed>           SSL      Client Hello

Frame 34446 (164 bytes on wire, 164 bytes captured)
    Arrival Time: Oct 29, 2009 08:03:37.301438000
    [Time delta from previous captured frame: 0.000602000 seconds]
    [Time delta from previous displayed frame: 0.000602000 seconds]
    [Time since reference or first frame: 117.798401000 seconds]
    Frame Number: 34446
    Frame Length: 164 bytes
    Capture Length: 164 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp:ssl]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: HewlettP_68:24:67 (00:0b:cd:68:24:67), Dst:
Vmware_9a:54:7d (00:50:56:9a:54:7d)
    Destination: Vmware_9a:54:7d (00:50:56:9a:54:7d)
        Address: Vmware_9a:54:7d (00:50:56:9a:54:7d)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
    Source: HewlettP_68:24:67 (00:0b:cd:68:24:67)
        Address: HewlettP_68:24:67 (00:0b:cd:68:24:67)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: <removed>, Dst: <removed>
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 150
    Identification: 0x65e7 (26087)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0x3a0b [correct]
        [Good: True]
        [Bad : False]
    Source: <removed>
    Destination:<removed>
Transmission Control Protocol, Src Port: cas-mapi (3682), Dst Port:
https (443), Seq: 1, Ack: 1, Len: 110
    Source port: cas-mapi (3682)
    Destination port: https (443)
    [Stream index: 64]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 111    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgement: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 65535
    Checksum: 0xc791 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [SEQ/ACK analysis]
        [Number of bytes in flight: 110]
Secure Socket Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 105
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 101
            Version: TLS 1.0 (0x0301)
            Random
                gmt_unix_time: Oct 29, 2009 08:03:37.000000000
                random_bytes:
E2103A68F025B061AF0FFB9DDF45E62EA52724CDE47FEE79...
            Session ID Length: 32
            Session ID: D2D7B8577F842D69A074F3F90ABD2AE9BF979E78DB2E6631...
            Cipher Suites Length: 30
            Cipher Suites (15 suites)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
                Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
                Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
                Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
                Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)

0000  00 50 56 9a 54 7d 00 0b cd 68 24 67 08 00 45 00   .PV.T}...h$g..E.
0010  00 96 65 e7 40 00 80 06 3a 0b ac 10 01 0e ac 10   ..e.@...:.......
0020  01 41 0e 62 01 bb bb 16 43 ed 69 b8 1e 71 50 18   .A.b....C.i..qP.
0030  ff ff c7 91 00 00 16 03 01 00 69 01 00 00 65 03   ..........i...e.
0040  01 4a e9 68 79 e2 10 3a 68 f0 25 b0 61 af 0f fb   .J.hy..:h.%.a...
0050  9d df 45 e6 2e a5 27 24 cd e4 7f ee 79 18 bb de   ..E...'$....y...
0060  5d 20 d2 d7 b8 57 7f 84 2d 69 a0 74 f3 f9 0a bd   ] ...W..-i.t....
0070  2a e9 bf 97 9e 78 db 2e 66 31 64 14 ef 60 47 96   *....x..f1d..`G.
0080  43 7a 00 1e 00 04 00 05 00 2f 00 33 00 32 00 0a   Cz......./.3.2..
0090  00 16 00 13 00 09 00 15 00 12 00 03 00 08 00 14   ................
00a0  00 11 01 00                                       ....
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[wolfoftheair]

CRYPTO_malloc is an internally-used function, to allocate memory.  In any event, though, do you do an earlier CRYPTO_malloc_init?

http://openssl.org/support/faq.html#PROG2

-Kyle H

On Thu, Oct 29, 2009 at 11:23 AM, Josue Andrade Gomes <josue.gomes.honeypot@...> wrote:

> Hi,
>
> Shortly: HP Insight Manager (a management tool) crashes my server SSL
> application.
> Operating system: Windows 2003 Server
> OpenSSL version: 0.9.8k
> Post-mortem debugger points the crash ocurring in a call to
> CRYPTO_malloc() inside SSLv3_client_method()
> (wich is weird since I never call this function).
>
> Any idea? Have someone seen this already?
>
> regards,
> josue
>
> The packet that causes the crash:
>
> No.     Time        Source                Destination           Protocol Info
>  34446 117.798401  <removed> <removed>           SSL      Client Hello
>
> Frame 34446 (164 bytes on wire, 164 bytes captured)
>    Arrival Time: Oct 29, 2009 08:03:37.301438000
>    [Time delta from previous captured frame: 0.000602000 seconds]
>    [Time delta from previous displayed frame: 0.000602000 seconds]
>    [Time since reference or first frame: 117.798401000 seconds]
>    Frame Number: 34446
>    Frame Length: 164 bytes
>    Capture Length: 164 bytes
>    [Frame is marked: False]
>    [Protocols in frame: eth:ip:tcp:ssl]
>    [Coloring Rule Name: TCP]
>    [Coloring Rule String: tcp]
> Ethernet II, Src: HewlettP_68:24:67 (00:0b:cd:68:24:67), Dst:
> Vmware_9a:54:7d (00:50:56:9a:54:7d)
>    Destination: Vmware_9a:54:7d (00:50:56:9a:54:7d)
>        Address: Vmware_9a:54:7d (00:50:56:9a:54:7d)
>        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>        .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
>    Source: HewlettP_68:24:67 (00:0b:cd:68:24:67)
>        Address: HewlettP_68:24:67 (00:0b:cd:68:24:67)
>        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>        .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
>    Type: IP (0x0800)
> Internet Protocol, Src: <removed>, Dst: <removed>
>    Version: 4
>    Header length: 20 bytes
>    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>        0000 00.. = Differentiated Services Codepoint: Default (0x00)
>        .... ..0. = ECN-Capable Transport (ECT): 0
>        .... ...0 = ECN-CE: 0
>    Total Length: 150
>    Identification: 0x65e7 (26087)
>    Flags: 0x04 (Don't Fragment)
>        0... = Reserved bit: Not set
>        .1.. = Don't fragment: Set
>        ..0. = More fragments: Not set
>    Fragment offset: 0
>    Time to live: 128
>    Protocol: TCP (0x06)
>    Header checksum: 0x3a0b [correct]
>        [Good: True]
>        [Bad : False]
>    Source: <removed>
>    Destination:<removed>
> Transmission Control Protocol, Src Port: cas-mapi (3682), Dst Port:
> https (443), Seq: 1, Ack: 1, Len: 110
>    Source port: cas-mapi (3682)
>    Destination port: https (443)
>    [Stream index: 64]
>    Sequence number: 1    (relative sequence number)
>    [Next sequence number: 111    (relative sequence number)]
>    Acknowledgement number: 1    (relative ack number)
>    Header length: 20 bytes
>    Flags: 0x18 (PSH, ACK)
>        0... .... = Congestion Window Reduced (CWR): Not set
>        .0.. .... = ECN-Echo: Not set
>        ..0. .... = Urgent: Not set
>        ...1 .... = Acknowledgement: Set
>        .... 1... = Push: Set
>        .... .0.. = Reset: Not set
>        .... ..0. = Syn: Not set
>        .... ...0 = Fin: Not set
>    Window size: 65535
>    Checksum: 0xc791 [validation disabled]
>        [Good Checksum: False]
>        [Bad Checksum: False]
>    [SEQ/ACK analysis]
>        [Number of bytes in flight: 110]
> Secure Socket Layer
>    SSL Record Layer: Handshake Protocol: Client Hello
>        Content Type: Handshake (22)
>        Version: TLS 1.0 (0x0301)
>        Length: 105
>        Handshake Protocol: Client Hello
>            Handshake Type: Client Hello (1)
>            Length: 101
>            Version: TLS 1.0 (0x0301)
>            Random
>                gmt_unix_time: Oct 29, 2009 08:03:37.000000000
>                random_bytes:
> E2103A68F025B061AF0FFB9DDF45E62EA52724CDE47FEE79...
>            Session ID Length: 32
>            Session ID: D2D7B8577F842D69A074F3F90ABD2AE9BF979E78DB2E6631...
>            Cipher Suites Length: 30
>            Cipher Suites (15 suites)
>                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
>                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
>                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
>                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
>                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
>                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
>                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
>                Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
>                Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
>                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
>                Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
>                Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
>                Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
>            Compression Methods Length: 1
>            Compression Methods (1 method)
>                Compression Method: null (0)
>
> 0000  00 50 56 9a 54 7d 00 0b cd 68 24 67 08 00 45 00   .PV.T}...h$g..E.
> 0010  00 96 65 e7 40 00 80 06 3a 0b ac 10 01 0e ac 10   ..e.@...:.......
> 0020  01 41 0e 62 01 bb bb 16 43 ed 69 b8 1e 71 50 18   .A.b....C.i..qP.
> 0030  ff ff c7 91 00 00 16 03 01 00 69 01 00 00 65 03   ..........i...e.
> 0040  01 4a e9 68 79 e2 10 3a 68 f0 25 b0 61 af 0f fb   .J.hy..:h.%.a...
> 0050  9d df 45 e6 2e a5 27 24 cd e4 7f ee 79 18 bb de   ..E...'$....y...
> 0060  5d 20 d2 d7 b8 57 7f 84 2d 69 a0 74 f3 f9 0a bd   ] ...W..-i.t....
> 0070  2a e9 bf 97 9e 78 db 2e 66 31 64 14 ef 60 47 96   *....x..f1d..`G.
> 0080  43 7a 00 1e 00 04 00 05 00 2f 00 33 00 32 00 0a   Cz......./.3.2..
> 0090  00 16 00 13 00 09 00 15 00 12 00 03 00 08 00 14   ................
> 00a0  00 11 01 00                                       ....
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@...
> Automated List Manager                           majordomo@...
>

[Josue Andrade Gomes-2]

Thanks for the tip. No, I don't call CRYPTO_malloc_init. But I don't
think it is necessary. I'm pretty sure
that I'm not mixing compiler options.
Also, if this was the case it was crashing all the time, right?
SSL connections work fine with any client except this HP Insight Manager thing.

Of course I can give it a try and see what happens.

Thanks a lot.

On Thu, Oct 29, 2009 at 5:40 PM,  <aerowolf@...> wrote:

> CRYPTO_malloc is an internally-used function, to allocate memory.  In any
> event, though, do you do an earlier CRYPTO_malloc_init?
>
> http://openssl.org/support/faq.html#PROG2
>
> -Kyle H
>
> On Thu, Oct 29, 2009 at 11:23 AM, Josue Andrade Gomes
> <josue.gomes.honeypot@...> wrote:
>>
>> Hi,
>>
>> Shortly: HP Insight Manager (a management tool) crashes my server SSL
>> application.
>> Operating system: Windows 2003 Server
>> OpenSSL version: 0.9.8k
>> Post-mortem debugger points the crash ocurring in a call to
>> CRYPTO_malloc() inside SSLv3_client_method()
>> (wich is weird since I never call this function).
>>
>> Any idea? Have someone seen this already?
>>
>> regards,
>> josue
>>
>> The packet that causes the crash:
>>
>> No.     Time        Source                Destination           Protocol
>> Info
>>  34446 117.798401  <removed> <removed>           SSL      Client Hello
>>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dave Thompson-4]

> From: owner-openssl-users@... On Behalf Of Josue Andrade Gomes
> Sent: Thursday, 29 October, 2009 14:23

> Shortly: HP Insight Manager (a management tool) crashes my server SSL
> application.
> Operating system: Windows 2003 Server
> OpenSSL version: 0.9.8k
> Post-mortem debugger points the crash ocurring in a call to
> CRYPTO_malloc() inside SSLv3_client_method()
> (wich is weird since I never call this function).
>
Even if you did, it doesn't allocate anything; it just returns
some static data that is later used to dispatch other calls.

I'd bet the traceback is wrong, which has two common causes:
- the stack and/or regs is clobbered so the trace values are bogus
- you're not using the same executable (and symbols if separate)
as was running, so the debugger decodes it wrongly (note that
a rebuild, even from exact same source, might not be good enough)

Check the latter first. If you (can) run the program (here server)
under an interactive (not postmortem) debugger (and get the fault),
you can usually be sure it's using the right executable.

Another possibility is that it faulted in code for which symbols
are missing, and these happened to be the closest available ones
(or if the debugger is really confused, just some available ones).
Does your debugger show symbol+offset and is the offset(s) large?
Can you get absolute numbers instead and compare them to your
link map or equivalent to see if they are really in the routines?

A final possibility is that you (or whoever) compiled with gcc
with -fomit-frame-pointer (the default config on at least many
platforms) or something analogous on another compiler, and the
resulting not-fully-materialized stack(s) confused the debugger.
But in my experience this usually gives incomplete tracebacks
with missing entries, not wholly absurd ones.

> The packet that causes the crash:
<snip>
> Secure Socket Layer
>     SSL Record Layer: Handshake Protocol: Client Hello
<snip>
>             Session ID Length: 32
>             Session ID:
> D2D7B8577F842D69A074F3F90ABD2AE9BF979E78DB2E6631...

I see it is specifying sessID. If the server is crashing
and being restarted presumably any internal cache is lost;
do you have/configure an external cache? If so is it valid,
and your callback to fetch from it correct?

I see you later say other clients do work. Do they
(does any of them) resume sessIDs? If not you can use
openssl s_client to create a test situation.




______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Josue Andrade Gomes-2]

On Thu, Oct 29, 2009 at 11:42 PM, Dave Thompson
<dave.thompson@...> wrote:

Thanks for your help.

> I'd bet the traceback is wrong.

Indeed a detailed analysis by the debugger show:

ntdll!KiFastSystemCallRet
kernel32!UnhandledExceptionFilter+0x7c0
kernel32!BaseThreadStart+0x4a
kernel32!_except_handler3+0x61
ntdll!ExecuteHandler2+0x26
ntdll!ExecuteHandler+0x24
ntdll!KiUserExceptionDispatcher+0xe
ntdll!RtlAllocateHeap+0x675
msvcr80!malloc+0x7a
WARNING: Stack unwind information not available. Following frames may be wrong.
libeay32!CRYPTO_get_lock_name+0x5b
libeay32!CRYPTO_malloc+0x42
ssleay32!SSLv3_client_method+0x45a5

I have to custom the build of OpenSSL DLLs to generate the symbols.
The crash occurs due to a 'heap corruption' exception (a feature of
Windows runtime) and the origin is a call to a memory allocation
system call.
I'm customizing OpenSSL DLLs makefiles to generate the correct symbols.

> I see it is specifying sessID. If the server is crashing
> and being restarted presumably any internal cache is lost;
> do you have/configure an external cache?

No.

> I see you later say other clients do work. Do they
> (does any of them) resume sessIDs?

I don't really now. This is a webserver and it works with any
mainstream web browser.

> If not you can use openssl s_client to create a test situation.

"openssl s_client" works fine.

I'm still investigating and I'll put my findings here.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dave Thompson-4]

> From: owner-openssl-users@... On Behalf Of Josue Andrade Gomes
> Sent: Tuesday, 03 November, 2009 07:13

> On Thu, Oct 29, 2009 at 11:42 PM, Dave Thompson
> <dave.thompson@...> wrote:

> > I'd bet the traceback is wrong.
>
> Indeed a detailed analysis by the debugger show:
>
> ntdll!KiFastSystemCallRet
> kernel32!UnhandledExceptionFilter+0x7c0
> kernel32!BaseThreadStart+0x4a
> kernel32!_except_handler3+0x61
> ntdll!ExecuteHandler2+0x26
> ntdll!ExecuteHandler+0x24
> ntdll!KiUserExceptionDispatcher+0xe
> ntdll!RtlAllocateHeap+0x675
> msvcr80!malloc+0x7a
> WARNING: Stack unwind information not available. Following
> frames may be wrong.
> libeay32!CRYPTO_get_lock_name+0x5b
> libeay32!CRYPTO_malloc+0x42
> ssleay32!SSLv3_client_method+0x45a5
>

That last part must be bogus, as the warning suggests.
CRYPTO_get_lock_name doesn't call malloc (at all),
CRYPTO_malloc doesn't call CRYPTO_get_lock_name,
and SSLv3_client_method can't possibly be that large --
as I suggested before, this is probably a location
in a part of your program that doesn't have symbols,
or if the location the debugger is decoding is itself
bogus, it could be outside your program area entirely.

> I have to custom the build of OpenSSL DLLs to generate the symbols.
> The crash occurs due to a 'heap corruption' exception (a feature of
> Windows runtime) and the origin is a call to a memory allocation
> system call.

The top part of the traceback (above the warning) does look
reasonable for heap corruption. Apparently SOMETHING is
calling malloc and triggering the fault, but the above
information gives us no idea what.

> I'm customizing OpenSSL DLLs makefiles to generate the
> correct symbols.
>
> > I see it is specifying sessID. If the server is crashing
> > and being restarted presumably any internal cache is lost;
> > do you have/configure an external cache?
>
> No.
>
> > I see you later say other clients do work. Do they
> > (does any of them) resume sessIDs?
>
> I don't really now. This is a webserver and it works with any
> mainstream web browser.
>

I believe at least some browsers do use sessIDs at least 'normally',
but you'd need to verify specific cases. One possible inhibitor:
if you support 1.1 (as at least most browsers do) and your users
do only short interactions, they might get everything in one https
session, and not *need* resumption.

> > If not you can use openssl s_client to create a test situation.
>
> "openssl s_client" works fine.
>
To be clear: s_client with -sessout to a file, followed by s_client
with -sessin from the same file (to the same server instance) works?
And -sessin to a different server instance is ignored but doesn't fault?

Also, it shouldn't make a difference, but with bizarre problems
like this you never really know: have your test client (s_client)
use the same requested-cipherlist as the problematic client
or at least request the first cipher in that list that
your server will (is configured and enabled to) accept.

> I'm still investigating and I'll put my findings here.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Josue Andrade Gomes-2]

On Tue, Nov 3, 2009 at 11:12 PM, Dave Thompson
<dave.thompson@...> wrote:
> To be clear: s_client with -sessout to a file, followed by s_client
> with -sessin from the same file (to the same server instance) works?
> And -sessin to a different server instance is ignored but doesn't fault?
>

Both cases work fine.


Unfortunately this issue is not reproducible in my environment and I
still didn't get a chance to do some tests in the faulting system.
Hope to get more data by the end of week.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Dave Thompson-4]

 
> From: owner-openssl-users@... On Behalf Of Josue Andrade Gomes
> Sent: Wednesday, 04 November, 2009 09:14

> On Tue, Nov 3, 2009 at 11:12 PM, Dave Thompson
> <dave.thompson@...> wrote:
> > To be clear: s_client with -sessout to a file, followed by s_client
> > with -sessin from the same file (to the same server instance) works?
> > And -sessin to a different server instance is ignored but
> doesn't fault?
> >
>
> Both cases work fine.
>

Wow. At this point you've about got me stumped. In a situation
like this I would start (tediously) debug-stepping through the
smallest reproducible case to localize it. But ...
>
> Unfortunately this issue is not reproducible in my environment and I
> still didn't get a chance to do some tests in the faulting system.
> Hope to get more data by the end of week.

... it sounds like that's difficult for you. Good luck.
If you can't debug in the (only?) faulting system but there are
(any) other debug-related knobs you can turn on (there), like
verbose logging or libc heap checking, I'd say try them.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...