[openssl-users] Maintaining a file for session cache - server side

[Shubham Chauhan]

Hey,

I wanted to store sessions to a file (on the server side), every time a
session is negotiated, and then eventually read that file for the presence
of a particular session. If the session is present, I would like to do an
abbreviated handshake, i.e. session resumption.

So, basically maintaining a server side external cache.
Any ideas on how to go about it?
A small code snippet would be really useful,

Thanks
--
Regards
Shubham Chauhan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is anyone else getting spammed by databreachtoday.com, or is it just me?

[Erik Forsberg]

Havent seen any.

>-- Original Message --
>
>Over the last many months, I have received a constant flow of
>"newsletters" from databreachtoday.com to my OpenSSL posting
>address.
>
>I am wondering if this is specific to me, or if they are
>sending to most other subscribers too.
>
>Enjoy
>
>Jakob
>-- 
>Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
>This public discussion message is non-binding and may contain errors.
>WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>-- 
>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] Failed TLSv1.2 handshake with error 67702888--bad signature

[Nounou Dadoun]

Curiouser and curiouser - I have attached two minimal packet captures in which 
the only difference in the server build was a change in one line (using boost 
with openssl):
   : m_context(pIoService->GetNative(), 
boost::asio::ssl::context::tlsv1)
to
   : m_context(pIoService->GetNative(), 
boost::asio::ssl::context::sslv23)

They both disable sslv2 and sslv3.
The former resulted in a handshake that completed, the latter failed with the 
aforementioned "67702888--bad signature" logged error.  The respective packet 
captures are attached.

This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails?

Is tls1.2 more strict about accepting the client certificate since it's 
complaining about a "bad signature" where tlsv1 doesn't?

Anybody have any ideas? ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Nounou Dadoun
Sent: Thursday, February 25, 2016 2:42 PM
To: openssl-users@openssl.org
Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad 
signature

  I'm trying to troubleshoot some development code which is enabling TLSv1.1 
and 1.2 and failing. Have an odd tls handshake failure, with an error number 
that I can find any documentation about (is there any?) that indicates 
"67702888--bad signature" which is being logged on the server side; and I'm 
trying to see where in the handshake things are falling apart.

Looks like it's negotiating tls1.2 and agreeing on 
TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a 
certificate although I don't see it requesting mutual authentication.

I've attached a very short wireshark capture - does anyone know what that error 
code might be related to or can give me a hint as to what's going awry here?  
Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


This email, including any files attached hereto (the "email"), contains 
privileged and confidential information and is only for the intended 
addressee(s). If this email has been sent to you in error, such sending does 
not constitute waiver of privilege and we request that you kindly delete the 
email and notify the sender. Any unauthorized use or disclosure of this email 
is prohibited. Avigilon and certain other trade names used herein are the 
registered and/or unregistered trademarks of Avigilon Corporation and/or its 
affiliates in Canada and other jurisdictions worldwide.




tlsv1_successful_handshake.pcapng
Description: tlsv1_successful_handshake.pcapng


tlsv1.2_failed_handshake.pcapng
Description: tlsv1.2_failed_handshake.pcapng
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Is anyone else getting spammed by databreachtoday.com, or is it just me?

[Jakob Bohm]

Over the last many months, I have received a constant flow of
"newsletters" from databreachtoday.com to my OpenSSL posting
address.

I am wondering if this is specific to me, or if they are
sending to most other subscribers too.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

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

Re: [openssl-users] Helps needed regarding the error "fingerprint does not match:fips.c:232:"

[cloud force]

By running the command fips_premain.dso, I found that my lib crypto.so
library file does not have the following two symbols:

FINGERPRINT_ascii_value
FINGERPRINT_remain

Could the missing of these two symbols caused the problems of fingerprint
mismatch which I ran into (during the run time)?

Where do these two symbols come from and what could cause them not being
added to the libcrypto.so?


Thanks for any suggestions and helps.


On Thu, Feb 25, 2016 at 11:03 AM, cloud force 
wrote:

> Thanks for the information.
>
> I checked the Makefile and build logs of both cases (i.e. built with
> Ubuntu packaging script and built with the standard way), and I saw the
> fipsld was run in both cases:
>
> Makefile for both:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *libcrypto$(SHLIB_EXT): libcrypto.a fips_premain_dso$(EXE_EXT)@if [
> "$(SHLIB_TARGET)" != "" ]; then \if [ "$(FIPSCANLIB)" = "libcrypto"
> ]; then \FIPSLD_LIBCRYPTO=libcrypto.a ; \
> FIPSLD_CC="$(CC)"; CC=$(FIPSDIR)/bin/fipsld; \export CC
> FIPSLD_CC FIPSLD_LIBCRYPTO; \fi; \$(MAKE) -e
> SHLIBDIRS=crypto  CC="$${CC:-$(CC)}" build-shared && \(touch -c
> fips_premain_dso$(EXE_EXT) || :); \echo "CC is $(CC)"; \else
> \echo "There's no support for shared libraries on this platform"
> >&2; \exit 1; \fi*
>
>
> Although it seemed like the FIPSLD_CC wasn't set in both cases, but I did
> see that the fipsld eventually got executed in both cases.
>
>
> I saw the following in both the build logs:
>
>
>
>
>
>
>
>
>
> *if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \(cd ..;
> make libcrypto.so.1.0.0); \fimake[3]: Entering directory
> `/home/Development/precise/amd64/openssl/openssl-1.0.1'[ -z "libcrypto" ]
> || gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN  -O3   -Wformat
> -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2
> -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT  -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -Iinclude \-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso
> \/usr/local/ssl/fips-2.0/lib/fips_premain.c
> /usr/local/ssl/fips-2.0/lib/fipscanister.o \libcrypto.a -ldl -lz*
>
> Also if I removed the fipsld binary from the /usr/local/ssl/fips-2.0/bin/
> directory, I saw the fipsld "File not found" errors in both cases, which
> also proved that the fipsld was ran.
>
> One major differences I could see was, in Ubuntu Makefile it uses *-Wl,
> --version-script=openssl.ld* in the *SHARED_LDFLAGS* and all the symbols
> were included in the openssl.ld file. I also added all the FIPS related
> symbols to this file as well, otherwise they all showed up as "t" instead
> of "T" when running nm on the libcrypto.so
>
>
> How does fipsld set the sig and FIPS_SIGNATURE and what's the right way to
> call it in the build script? e.g. How do I use it to set these signature in
> the command line?
> In addition to the fipsld command, is there any other possible reasons
> which would cause the signature not set correctly?
>
> Thanks and I truly appreciate the helps and suggestions.
>
>
>
> On Wed, Feb 24, 2016 at 6:36 PM, Dr. Stephen Henson 
> wrote:
>
>> On Wed, Feb 24, 2016, cloud force wrote:
>>
>> > Actually it looks like when I ran the tests using the OpenSSL FIPS
>> library
>> > which I built using Ubuntu build script, the content of FIPS_SIGNATURE
>> > seemed to be empty.
>> >
>> > Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near
>> fips.c
>> > line 222) was computed and assigned?
>> >
>>
>> They are set using the fipsld linker script. If you have changed the build
>> process so fipsld is no longer called that will cause the signature test
>> to
>> fail.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Thanks,
> Rich
>
>


-- 
Thanks,
Rich
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to retrieve the revoked certificate list when X509_LOOKUP_hash_dir() method used

[Yan, Bob]

H All,

I used the following methods to load CRL hashed-directory into a SSL_CTX object 
to verify the client certificate against the CRL. The code works fine and it's 
able to verify the client certificate against the loaded CRLs.  

   X509_STORE *x509Store = SSL_CTX_get_cert_store(sslCtx);
   X509_LOOKUP *lookup = X509_STORE_add_lookup(x509Store, 
X509_LOOKUP_hash_dir());
   X509_LOOKUP_add_dir(lookup, crlDirectory, X509_FILETYPE_PEM);

My question is that, is there any method to retrieve the CRL list or print all 
revoked certificate list?

Thanks
Bob

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

[openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature

[Nounou Dadoun]

  I'm trying to troubleshoot some development code which is enabling TLSv1.1 
and 1.2 and failing. Have an odd tls handshake failure, with an error number 
that I can find any documentation about (is there any?) that indicates 
"67702888--bad signature" which is being logged on the server side; and I'm 
trying to see where in the handshake things are falling apart.

Looks like it's negotiating tls1.2 and agreeing on 
TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a 
certificate although I don't see it requesting mutual authentication.

I've attached a very short wireshark capture - does anyone know what that error 
code might be related to or can give me a hint as to what's going awry here?  
Thanks ... N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


This email, including any files attached hereto (the "email"), contains 
privileged and confidential information and is only for the intended 
addressee(s). If this email has been sent to you in error, such sending does 
not constitute waiver of privilege and we request that you kindly delete the 
email and notify the sender. Any unauthorized use or disclosure of this email 
is prohibited. Avigilon and certain other trade names used herein are the 
registered and/or unregistered trademarks of Avigilon Corporation and/or its 
affiliates in Canada and other jurisdictions worldwide.




jkcapture.pcapng
Description: jkcapture.pcapng
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Helps needed regarding the error "fingerprint does not match:fips.c:232:"

[cloud force]

Thanks for the information.

I checked the Makefile and build logs of both cases (i.e. built with Ubuntu
packaging script and built with the standard way), and I saw the fipsld was
run in both cases:

Makefile for both:














*libcrypto$(SHLIB_EXT): libcrypto.a fips_premain_dso$(EXE_EXT)@if [
"$(SHLIB_TARGET)" != "" ]; then \if [ "$(FIPSCANLIB)" = "libcrypto"
]; then \FIPSLD_LIBCRYPTO=libcrypto.a ; \
FIPSLD_CC="$(CC)"; CC=$(FIPSDIR)/bin/fipsld; \export CC
FIPSLD_CC FIPSLD_LIBCRYPTO; \fi; \$(MAKE) -e
SHLIBDIRS=crypto  CC="$${CC:-$(CC)}" build-shared && \(touch -c
fips_premain_dso$(EXE_EXT) || :); \echo "CC is $(CC)"; \else
\echo "There's no support for shared libraries on this platform"
>&2; \exit 1; \fi*


Although it seemed like the FIPSLD_CC wasn't set in both cases, but I did
see that the fipsld eventually got executed in both cases.


I saw the following in both the build logs:









*if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \(cd ..; make
libcrypto.so.1.0.0); \fimake[3]: Entering directory
`/home/Development/precise/amd64/openssl/openssl-1.0.1'[ -z "libcrypto" ]
|| gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN  -O3   -Wformat
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2
-Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT  -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-Iinclude \-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso
\/usr/local/ssl/fips-2.0/lib/fips_premain.c
/usr/local/ssl/fips-2.0/lib/fipscanister.o \libcrypto.a -ldl -lz*

Also if I removed the fipsld binary from the /usr/local/ssl/fips-2.0/bin/
directory, I saw the fipsld "File not found" errors in both cases, which
also proved that the fipsld was ran.

One major differences I could see was, in Ubuntu Makefile it uses *-Wl,
--version-script=openssl.ld* in the *SHARED_LDFLAGS* and all the symbols
were included in the openssl.ld file. I also added all the FIPS related
symbols to this file as well, otherwise they all showed up as "t" instead
of "T" when running nm on the libcrypto.so


How does fipsld set the sig and FIPS_SIGNATURE and what's the right way to
call it in the build script? e.g. How do I use it to set these signature in
the command line?
In addition to the fipsld command, is there any other possible reasons
which would cause the signature not set correctly?

Thanks and I truly appreciate the helps and suggestions.



On Wed, Feb 24, 2016 at 6:36 PM, Dr. Stephen Henson 
wrote:

> On Wed, Feb 24, 2016, cloud force wrote:
>
> > Actually it looks like when I ran the tests using the OpenSSL FIPS
> library
> > which I built using Ubuntu build script, the content of FIPS_SIGNATURE
> > seemed to be empty.
> >
> > Can anyone tell me how was the value of sig and FIPS_SIGNATURE (near
> fips.c
> > line 222) was computed and assigned?
> >
>
> They are set using the fipsld linker script. If you have changed the build
> process so fipsld is no longer called that will cause the signature test to
> fail.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Thanks,
Rich
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] "digest check failure" with AmigaOS3/m68k port of OpenSSL 1.0.x

[Jens Maus]

Hello,

I am the current maintainer of a still active port of OpenSSL to the AmigaOS 
platform which tries to wrap the OpenSSL library API into a full fledged Amiga 
shared library for applications requiring cryptographic functionality (see 
https://github.com/jens-maus/amissl). So yes, the Amiga platform is still alive 
;)

While for some Amiga platforms (e.g. AmigaOS4/PPC) the current OpenSSL 1.0.2f 
kernel of this library seems to behave fine and all our tests are not reporting 
any problem we are still facing some trouble with one of the older Amiga 
platforms (AmigaOS3) which utilizes Motorola m68k processors. While all of the 
openssl test binaries are not outputting any error, we are facing some trouble 
in receiving „digest check failed“ messages, e.g. when executing the following 
‚openssl‘ test command:

openssl s_client -connect pop.gmail.com:995 -tls1_2 -cipher 
ECDHE-RSA-AES128-GCM-SHA256

The problem vanishes, however, immediately when using a SHA384 using cipher:

openssl s_client -connect pop.gmail.com:995 -tls1_2 -cipher 
ECDHE-RSA-AES256-GCM-SHA384

The error output we are receiving when using SHA256 digest ciphers is:

error:1408C095:SSL routines:ssl3_get_finished:digest check failed

Please note, however, that the „sha256t“ openssl test programs doesn’t output 
any error nor does a „openssl dgst -sha256“ command produce any broken SHA256 
digest outputs.

After having tracked down the problem in the OpenSSL source code we have traced 
down the problem to the following CRYPTO_memcmp() failing for some unknown 
reason:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2f/ssl/s3_both.c#L271

So in this case either s->init_msg or s->s3->tmp.peer_finish_md seems to be 
incorrectly calculated. Commenting out the whole CRYPTO_memcmp() check results, 
however, in a succeeding TLS connection where s_client can then properly 
communicate with the server in question.

Our current difficulty in trying to debug if either init_msg or peer_finish_md 
is incorrectly calculated is, that the corresponding code passages are of 
course using random values and thus each connection produces differences we can 
hardly compare to each other.

I would like to therefore ask if there is any possibility or defined way of 
debugging/analyzing TLS connection handshakes with the exact same handshake 
procedure so that successive uses of „openssl s_client“ will always produce the 
same output? Or how do I have to manually calculate the SHA256 digest based on 
the TLS handshake data I am receiving via „openssl s_client -msg“ output? In 
addition, I would like to ask if anyone has another idea how I could debug why 
the SHA256 digest seems to be incorrectly calculated when performing a TLS1.2 
connection?!?

If anyone is interested, here is the corresponding github ticket which we are 
maintaining to track down the problem:
https://github.com/jens-maus/amissl/issues/2

Any help of course very appreciated!

Best Regards,
Jens
-- 
Jens Maus, Dresden/Germany
http://jens-maus.de/

*** Content is authentic only with digital signature  ***



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is the structure of this CMS object correct?

[Dr. Stephen Henson]

On Tue, Feb 23, 2016, Dr. Stephen Henson wrote:

> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
> 
> > I tried again to map the structure of the CMS object to the
> > definitions in RFC 5652 (comments added with a '%'):
> > 
> > 1: SEQUENCE {
> > 2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
> >% ContentType
> > 3:   [0] {  % eContent
> > 4: SEQUENCE {
> > 5:   INTEGER 0 % CMSVersion
> >   % no OriginatorInfo
> > 6:   SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> > 7: SEQUENCE {
> >% SEQUENCE tag should not be present because of implicit tagging?
> 
> Yes, because it is using the key agreement choice type it should be
> tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
> transport.
> 
> > 8:   INTEGER 3
> >  % version 3 only applicable to KeyAgreeRecipientInfo
> > 9:   [0] {
> 
> Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
> "originator" field.
> 
> > 10: SEQUENCE {
> 
> Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
> the fields below certainly aren't. It looks like originatorKey which should be
> tagged [1] IMPLICIT.
> 
> > 11:   SEQUENCE {
> > 12: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> > 13: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> > 14: }
> > 
> 
> So yes it's pretty broken.
> 

Just as a quick followup. If you change the two tags I mentioned above the
result does then parse. However I've no idea if it will actually decrypt: the
key derivation might be broken too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Forthcoming OpenSSL releases

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2g, 1.0.1s.

These releases will be made available on 1st March 2016 between approximately
1300-1700 UTC.  They will fix several security defects with maximum severity
"high".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.1
will end on 31st December 2016.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWzsjbAAoJEAEKUEB8TIy9ukoH/A+KQh0TPuC5CulMeFd4OiGy
7HV9bX/nCe4sKmW5IGYt6GDPFRnhup9WR9Dvz0C/sBjwttsnF+UZOUUfYbDw2liO
YG46kiS95zbeU4yYFQwHr9Sf01o89ogEGrxCIlKQiA4aXSZwn9liI0a51y7izWUC
xdj2GEgQ/fnVnlN/AyToVmoQxlrphXJx9FigLxTuXi1X6nvSNdEYB1VtOuqjanRu
8sR4UDCWYRZNT0L3as0IEU49X7ncwm5a85NR02SkVimevdbJw0mBT1ru4Zjddo88
oO5xpgSKy2a56xC8yQXURkVPvuFqUpfvyojLwOULUnWHCpnDhzn+ygdko2Pii3o=
=XURc
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] glibc detected *** xxx: double free or corruption (!prev): 0x097b8750

[Mike Mohr]

You'll need to rebuild your application and openssl with debugging symbols
and no optimization, then run it inside gdb to produce a more useful stack
trace. Since you don't include any context or source code snippets it isn't
really possible to help. Can you produce a reduced test case with source
code which reproduces the bug?

As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance.

John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
On Feb 24, 2016 11:33 PM, "Vikas TM"  wrote:

> Hi,
>
> While running my application with openSSL 102d and I encountered double
> free error or corruption.
>
> As per few threads suggestion, I have changed getpid() with pthread_self()
> in CRYPTO_thread_id(). Still the result is same.
>
> Please let me know if any fix available to this issue.
>
> *** glibc detected *** xxx: double free or corruption (!prev): 0x097b8750
> ***
>
> === Backtrace: =
>
> /lib/libc.so.6[0x1768b6]
>
> /lib/libc.so.6(cfree+0x90)[0x179e00]
>
> xxx(CRYPTO_free+0x3a)[0x81b89be]
>
> xxx(ssl_cert_free+0x13f)[0x826fa23]
>
> xxx(SSL_free+0x14d)[0x81d7e08]
>
> Thanks & Regards,
> Vikas
>
> --
> 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