Re: FIPS iOS 7+ / Xcode 5+
After reading the user guide and finding some more information I was able to get a full build but now my problem seems to be that the signatures don't match. I am using the fips-pi app to verify. Here are the steps I have taken to make things work under iOS 7 SDK. 1. I updated the setenv-ios-11.sh file to reflect an iOS 7 environment: export CROSS_TYPE=OS cross_arch="-armv7" CROSS_DEVELOPER=`xcode-select -print-path`" # CROSS_TOP is the top of the development tools tree export CROSS_TOP="$CROSS_DEVELOPER/Platforms/iPhone$CROSS_TYPE.platform/Developer" # CROSS_CHAIN is the location of the actual compiler tools export CROSS_CHAIN="$CROSS_DEVELOPER/Toolchains/XcodeDefault.xctoolchain/usr/bin/" # CROSS_SDK is the SDK version being used - adjust as appropriate for i in 7.1 7.0 6.1 6.0 5.1 5.0 4.3 do do if [ -d "$CROSS_TOP/SDKs/iPhone"$CROSS_TYPE""$i".sdk" ]; then SDKVER=$i break fi done export CROSS_SDK=iPhone"$CROSS_TYPE""$SDKVER".sdk # # fips/sha/Makefile uses HOSTCC for building fips_standalone_sha1 # export HOSTCC=/usr/bin/clang export HOSTCFLAGS="-arch i386" # CROSS_COMPILE is the prefix for the tools - in this case the scripts # which invoke the tools with the correct options for 'fat' binary handling export CROSS_COMPILE=$CROSS_CHAIN # FIPS_SIG is the tool for determining the incore fingerprint export FIPS_SIG=/usr/local/bin/incore_macho export IOS_TARGET=darwin-iphoneos-cross export IOS_INSTALLDIR=/usr/local/ssl/Release-iphoneos cross_type=`echo $CROSS_TYPE | tr '[A-Z]' '[a-z]'` MACHINE=`echo "$cross_arch" | sed -e 's/^-//'` SYSTEM="iphoneos" BUILD="build" export MACHINE export SYSTEM export BUILD export CONFIG_OPTIONS="no-shared --openssldir=$IOS_INSTALLDIR" 2. Followed the instructions to use the setenv-darwin-i386.sh file to build incore_macho and installed it in /usr/local/bin 3. Deleted the FIPS module folder and recreated it / called setenv-reset and setenv-ios-11 as per instructions 4. Ran sed -i "" 's|\"iphoneos-cross\"\,\"llvm-gcc\:-O3|\"iphoneos-cross\"\,\"clang\:-Os|g' Configure to force the use of clang since llvm-gcc no longer exists in iOS 7 SDK 5. ./configure make sudo make install No errors happen 6. move to openssl folder and setenv-reset / setenv-ios-11 again 7. Ran http://wiki.openssl.org/index.php/Compilation_and_Installation instructions OLD_LANG=$LANG unset LANG sed -i "" 's|\"iphoneos-cross\"\,\"llvm-gcc\:-O3|\"iphoneos-cross\"\,\"clang\:-Os|g' Configure sed -i "" 's/CC= cc/CC= clang/g' Makefile.org sed -i "" 's/CFLAG= -O/CFLAG= -Os/g' Makefile.org sed -i "" 's/MAKEDEPPROG=makedepend/MAKEDEPPROG=$(CC) -M/g' Makefile.org export LANG=$OLD_LANG 8. ./config fips -no-shared -no-hw -no-engines --with-fipsdir=/usr/local/ssl/Release-iphoneos make depend (for some reason this fails even though the sed MAKEDEPPROG instruction above was specifically designed to fix issues with clang I believe) making depend in crypto... clang: error: no such file or directory: '-DOPENSSL_THREADS' clang: error: no such file or directory: '-D_REENTRANT' clang: error: no such file or directory: '-DDSO_DLFCN' clang: error: no such file or directory: '-DHAVE_DLFCN_H' clang: error: no such file or directory: '-arch' clang: error: no such file or directory: 'armv7' clang: error: no such file or directory: '-Os' make all sudo make install 9. No errors on make or make install ... I then point the FIPS-pi demo to the correct library / headers and make sure to replace the fips_premain.c file that came bundled with FIPS-pi app with the one I had in my FIPS module install. 10. The app fails to have matching signatures and can't enable FIPS mode. I followed a similar procedure on the iOS 6 SDK last year using llvm-gcc and had no issues. It became necessary for me to upgrade and now I'm having these confusing issues. On Fri, Mar 21, 2014 at 8:28 PM, Jeffrey Walton wrote: > On Fri, Mar 21, 2014 at 8:06 PM, Thomas Leavy wrote: >> Is there any way to accomplish building OpenSSL FIPS under the iOS 7 sdk? >> > See the OpenSSL FIPS User Guide, Appendix E.2. > http://www.openssl.org/docs/fips/UserGuide-2.0.pdf. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE-ECDSA Support
> I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any > case. > ... > Any ideas why I can't do that with openssl? Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for example, OpenSSL downlevel version is 1.0.0, and does not support TLS 1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576. You should be able to connect with -tls1; or build/install OpenSSL yourself and use the one installed at /usr/local/ssl/bin/openssl. > openssl s_client -connect mail.google.com:443 -tls1_2 -cipher You can also use -CAfile option for s_client to avoid the verify error. Use Google's Google Internet Authority G2 at http://pki.google.com/. Jeff On Wed, Mar 26, 2014 at 4:14 PM, Thomas Montroy wrote: > hi All, > > I've been trying to make ECDHE-ECDSA connections with openssl and have been > having trouble. > > > openssl s_client -connect mail.google.com:443 -tls1_2 > This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256 > > According to Google-Chrome, the cipher for my web-based gmail connection > should be: > ECDHE-ECDSA-AES128-GCM-SHA256 > > If I try to make that connection > > openssl s_client -connect mail.google.com:443 -tls1_2 -cipher > ECDHE-ECDSA-AES128-GCM-SHA256 > > I get: > > CONNECTED(0003) > 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert > handshake failure:s3_pkt.c:1440:SSL alert number 40 > 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake > failure:s3_pkt.c:617: > > which looks like no connection. > > I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any > case. > > I downloaded and compiled the latest version of gnutls: > > This gives an ECDHE-ECDSA connection > gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com > > This gives an ECDHE-RSA > gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-RSA mail.google.com > > So I'm able to see both types of certificates for mail.google.com with > gnutls. > > Any ideas why I can't do that with openssl? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ECDHE-ECDSA Support
hi All, I've been trying to make ECDHE-ECDSA connections with openssl and have been having trouble. openssl s_client -connect mail.google.com:443 -tls1_2 This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256 According to Google-Chrome, the cipher for my web-based gmail connection should be: ECDHE-ECDSA-AES128-GCM-SHA256 If I try to make that connection openssl s_client -connect mail.google.com:443 -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 I get: CONNECTED(0003) 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1440:SSL alert number 40 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:617: which looks like no connection. I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case. I downloaded and compiled the latest version of gnutls: This gives an ECDHE-ECDSA connection gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com This gives an ECDHE-RSA gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-RSA mail.google.com So I'm able to see both types of certificates for mail.google.com with gnutls. Any ideas why I can't do that with openssl? Cheers, -Tom
Re: Anyone implementing RFC 7030: Enrollment over Secure Transport (EST)?
If you need access to this SW before we get it published (no ETA yet on when it will be published), contact me and we can talk about getting it to you via a no-cost license arrangement. On 3/26/14 10:10 AM, "John Foley (foleyj)" wrote: >We plan to publish an open source EST stack in the near future. This >will support both client-side and server-side capabilities. The code >will be hosted here: > >https://github.com/cisco/libest > >I've also recently setup an EST test server, which is available here: > >http://ec2-54-204-91-178.compute-1.amazonaws.com/ >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS 140-2 questions
On 03/26/2014 02:45 PM, Jason Schultz wrote: > I’m trying to decipher FIPS 140-2 Certification in regards to OpenSSL > FIPS module 2.0 and have some questions: > > > 1. Can one claim FIPS validated if running on an Operating > Environment not listed on Cert #1747? (I don’t think not having an OE > direct match is necessarily required, as long as I follow the build > guidelines as defined in the Security Policy.) As with so much in FIPS 140-2, it depends. Here the key issue is the meaning of "claim". To oversimplify a messy situation, the USG/DoD formal procurement policies that are the motivation for FIPS 140-2 validation, and the formal FIPS 140-2 scripture, allow for something called "user affirmation". See G.5 in the Implementation Guidance document: http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Sounds good, right? Not so fast. You want a FIPS 140-2 validated module so you can sell your product to the USG/DoD market (FIPS validation is undesirable in any other context). That means you must satisfy your USG/DoD customer that your product is righteous, never mind what the formal policies might say. And in fact I hear from numerous clients that some customers refuse to accept user affirmation. So the best answer to this question is "ask your marketing/sales people what the real requirement is". You can rarely win an argument over interpretation of scripture, and the customer is always right. > 2. Related to #1, what if the build process is followed on an OE > listed on 1747, and the resulting FIPS and OpenSSL modules were moved to > an OE not listed (e.g. Linux 3.0)? Where the build occurs is essentially irrelevant. What matters is where the module is executed (the "Operational Environment"). > 3. If I cannot claim validation from #1, would I have to get my OE > fully certified or can I do a change letter through the OpenSSL group? It depends :-). If your marketing folks tell you that user affirmation suffices, run with it. If not then your next best option is to sponsor addition of your specific platform(s) of interest to the #1747 validation. That's how that validation has currently grown to 80 platforms, more than any other validation. > 4. What are the costs for a change letter? It depends :-). There are more potential factors and potential complications than I care to try and document here, but as a general rule of thumb an "uncomplicated" platform (for the peculiar FIPS 140-2 definition of platform) can usually be added for US$15K. > 5. Is there any way to see any change letters in the works already > for 1747 that just haven’t been added to the cert (e.g. Linux 3.0)? We don't publish lists of platforms in process for a number of reasons, in particular the fact that the final form of the name as it appears in the Security Policy and the CAVP and CMVP web sites is a surprisingly tricky issue. At present we have nine platforms ready (and waiting...) for testing with several more en route. None of them will be "Linux 3.0". -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS 140-2 questions
I’m trying to decipher FIPS 140-2 Certification in regards to OpenSSL FIPS module 2.0 and have some questions: 1. Can one claim FIPS validated if running on an Operating Environment not listed on Cert #1747? (I don’t think not having an OE direct match is necessarily required, as long as I follow the build guidelines as defined in the Security Policy.) 2. Related to #1, what if the build process is followed on an OE listed on 1747, and the resulting FIPS and OpenSSL modules were moved to an OE not listed (e.g. Linux 3.0)? 3. If I cannot claim validation from #1, would I have to get my OE fully certified or can I do a change letter through the OpenSSL group? 4. What are the costs for a change letter? 5. Is there any way to see any change letters in the works already for 1747 that just haven’t been added to the cert (e.g. Linux 3.0)? Thanks in advance.
Re: Are certificates exchanged in for eNULL ciphers?
On Wed, Mar 26, 2014 at 07:33:15AM -0700, Deepti Jindal wrote: > In continuation with post: > http://openssl.6102.n7.nabble.com/SSL-Verify-Question-tp17908.html > which says that with Anonymous ciphers, certificates won't be exchanged and > hence won't be verified. Don't confuse eNULL (no encryption) with aNULL (no authentication). With OpenSSL 1.0.1e the only ciphersuite that is in both categories is: $ openssl version OpenSSL 1.0.1e 11 Feb 2013 $ openssl ciphers -v eNULL+aNULL AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 > However, I do want to ensure sure that no matter what, I am never sending > requests to the server without verification. Will it be possible if my > application is using an eNULL cipher (with Authentication ciphers enabled)? > e.g. "TLS_RSA_WITH_NULL_SHA" If you append ":!aNULL" to your cipherlist", no unauthenticated ciphersuites will be negotiated. Of course you still need to arrange to verify the presented certificates, otherwise, they add no value. (There is of course also PSK, but we'll ignore that for now). > "Certificate exchange will be mandatory in case Authentication ciphers are > used": Is this statement correct? Yes, if by "Authentication ciphers" you mean "!aNULL", i.e. complement of the anonymous ciphers and we ignore PSK authentication. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Are certificates exchanged in for eNULL ciphers?
On Wed, Mar 26, 2014, Deepti Jindal wrote: > Hi, > > In continuation with post: > http://openssl.6102.n7.nabble.com/SSL-Verify-Question-tp17908.html > which says that with Anonymous ciphers, certificates won't be exchanged and > hence won't be verified. > > However, I do want to ensure sure that no matter what, I am never sending > requests to the server without verification. Will it be possible if my > application is using an eNULL cipher (with Authentication ciphers enabled)? > e.g. "TLS_RSA_WITH_NULL_SHA" > > "Certificate exchange will be mandatory in case Authentication ciphers are > used": Is this statement correct? > If you include !aNULL in the cipher string you'll remove any anonymous ciphersuites. You can check which ones are anonymous using: openssl ciphers -v If it says Au=None it is an anonymous ciphersuite, anything else and it isn't. If you do that with eNULL you'll see that currently only AECDH-NULL-SHA is anonumous. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Are certificates exchanged in for eNULL ciphers?
Hi, In continuation with post: http://openssl.6102.n7.nabble.com/SSL-Verify-Question-tp17908.html which says that with Anonymous ciphers, certificates won't be exchanged and hence won't be verified. However, I do want to ensure sure that no matter what, I am never sending requests to the server without verification. Will it be possible if my application is using an eNULL cipher (with Authentication ciphers enabled)? e.g. "TLS_RSA_WITH_NULL_SHA" "Certificate exchange will be mandatory in case Authentication ciphers are used": Is this statement correct? Thanks in Advance for all your help. Regards, Deepti -- View this message in context: http://openssl.6102.n7.nabble.com/Are-certificates-exchanged-in-for-eNULL-ciphers-tp48952.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Anyone implementing RFC 7030: Enrollment over Secure Transport (EST)?
We plan to publish an open source EST stack in the near future. This will support both client-side and server-side capabilities. The code will be hosted here: https://github.com/cisco/libest I've also recently setup an EST test server, which is available here: http://ec2-54-204-91-178.compute-1.amazonaws.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Schnorr Signature? Zero knowledge proof missing?
Hi, I've been looking at the OpenSSL API and cannot seem to find an implementation for the Schnorr Signature. Does it exist? And if it doesn't how do people normally handle it when they need it? And are there any alternative zero knowledge proof algorithms available. Sorry for the hassle, but i've been looking for the past day or two for it in OpenSSL with no luck. Paddy -- View this message in context: http://openssl.6102.n7.nabble.com/Schnorr-Signature-Zero-knowledge-proof-missing-tp48949.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
Le 25/03/2014 23:08, Zack Williams a écrit :
On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea
wrote:
2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history. Could you elaborate on what that
accomplishes?
https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html
The OIDs are used in the CertificatePolicies extension of a subordinate CA
of this root CA.
For a policyId to be acceptable for an end-user certificate, this same
policyId (or the special value anyPolicy) MUST be present in all CAs between
this end-user cert and the root CA. The root CA is special in that it
doesn't need to contain any CertificatePolicies extension.
So these are used to group or link the certificate chain together?
No, it's about authorized uses of certificates.
Certificate policy is defined by the X.509 recommendation as:
"A named set of rules that indicates the applicability of a certificate
to a particular community and/or class of application with common
security requirements. For example, a particular certificate policy
might indicate applicability of a type of certificate to the
authentication of electronic data interchange transactions for the
trading of goods within a given price range."
What identifies a specific CP is a policyId, and it's represented by an
OID. Having a policyId declared or not in a CA allows for its issuing CA
to allow or deny the right of this subCA to deliver certificates that
can be used in accordance to this CP.
Is there guidance for generating and naming this OID? Given an OID in this form:
1.3.6.1.4.1.X.Y.Z
I'm assuming that you would register the top level number (X) with the
IANA (or other appropriate issuing body), but is there guidance to
setting Y and Z, which are 7 and 8 or 9 respectively in the Expert
example?
No guidance necessary, everyone is free to shape its OID space as wanted.
3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?
Because it's not used by the standardized validation algorithm (RFC5280
section 6, X.509 section 10).
I looked through RFC5280 section 6.1.4 (m), and it appears that
setting the pathLen would apply to the Root CA, and would cause
section (l) to fail on CA's created beyond the depth specified. Am I
interpreting the RFC incorrectly?
You overlooked this, in 6.1:
[...]
To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
(b) certificate 1 is issued by the trust anchor;
(c) certificate n is the certificate to be validated (i.e., the
target certificate); and
(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.
[...]
Point (b) is important.
Now look at 6.1.2 (Initialization), point (k):
-
(k) max_path_length: this integer is initialized to n, is
decremented for each non-self-issued certificate in the path,
and may be reduced to the value in the path length constraint
field within the basic constraints extension of a CA
certificate.
-
and you'll understand that any BasicConstraints:pathLenConstraint set in
the Trust Anchor isn't used at all.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Is it possible that calling ssl_accept in multi-threading circumstance will result in app to crash?
jeff : I keep getting some application crash in openssl module, I checked the > dumps and stacks and found that although the stacks vary, the ssl_accept > function is found on all of them, below are some of exmaples. I google the > related information about this, looks like there is some problem when > calling ssl_accept under multi-thread circumstance. My question is, is it > possible that calling ssl_accept in multi-threading circumstance will > result in app to crash? > Yes -- a single SSL object can't be used concurrently by multiple threads; see https://www.openssl.org/support/faq.html#PROG1. Bodo
Is it possible that calling ssl_accept in multi-threading circumstance will result in app to crash?
Dear users, I keep getting some application crash in openssl module, I checked the dumps and stacks and found that although the stacks vary, the ssl_accept function is found on all of them, below are some of exmaples. I google the related information about this, looks like there is some problem when calling ssl_accept under multi-thread circumstance. My question is, is it possible that calling ssl_accept in multi-threading circumstance will result in app to crash? -- OpenSSL version, extracted from the README file OpenSSL 1.0.1 14 Mar 2012 - OS version and platform: Windows Server 2008 R2 Enterprise Edition 6.1 SP 1. 0:014> kb ChildEBP RetAddr Args to Child 01fbdeb0 769dc752 0002 01fbe06c 0001 ntdll!NtWaitForMultipleObjects+0xc 01fbe034 74fe564b 0002 KERNELBASE!WaitForMultipleObjectsEx+0x10b 01fbe0a8 74fe57f5 01fbe194 01fbe194 kernel32!WerpReportFaultInternal+0x1c4 01fbe0bc 74fb780f 01fbe194 01fbe164 76a608dc kernel32!WerpReportFault+0x6d 01fbe0c8 76a608dc 01fbe194 0001 d4795733 kernel32!BasepReportFault+0x19 01fbe164 7743bf2c 01fbe194 774030b4 fffe KERNELBASE!UnhandledExceptionFilter+0x1f1 01fbe16c 774030b4 fffe 7740e728 01fbffd4 ntdll!__RtlUserThreadStart+0x57 01fbe180 773c5246 ntdll!_EH4_CallFilterFunc+0x12 01fbe1a8 773c51b1 774ae1e0 773ef810 ntdll!_except_handler4_common+0x8e 01fbe1c8 77402e71 01fbe2cc 01fbffc4 01fbe31c ntdll!_except_handler4+0x20 01fbe1ec 77402e43 01fbe2cc 01fbffc4 01fbe31c ntdll!ExecuteHandler2+0x26 01fbe2b4 77402cbb 01fbe2cc 01fbe31c 01fbe2cc ntdll!ExecuteHandler+0x24 01fbe2b4 004f105b 01fbe2cc 01fbe31c 01fbe2cc ntdll!KiUserExceptionDispatcher+0xf 01fbe784 004f12c3 02f51ad8 00572538 libeay32!asn1_item_combine_free+0x1b 01fbe798 004f11c0 0008 00572498 02f51ad8 libeay32!ASN1_template_free+0x93 01fbe7bc 004f12c3 01fbe80c 005725a8 libeay32!asn1_item_combine_free+0x180 01fbe7d0 004f11c0 02f51ad8 0057256c 01fbe80c libeay32!ASN1_template_free+0x93 01fbe7f4 004f12e1 007b 02b53338 libeay32!asn1_item_combine_free+0x180 01fbe804 004ed97f 02f51ad8 005725a8 003d6628 libeay32!ASN1_item_free+0x11 01fbe810 003d6628 02f51ad8 02b53338 003d7121 libeay32!X509_free+0xf 01fbe81c 003d7121 02b53338 0001 003d713e ssleay32!SSL_SESSION_free+0x88 01fbe828 003d713e 02b8d328 004d4ec3 02b53338 ssleay32!timeout_doall_arg+0x51 01fbe830 004d4ec3 02b53338 01fbe888 0100 ssleay32!timeout_LHASH_DOALL_ARG+0xe 01fbe848 004d4f4c 00fbeea0 003d7130 libeay32!doall_util_fn+0x33 01fbe860 003d719a 00fbeea0 003d7130 01fbe888 libeay32!lh_doall_arg+0x1c 01fbe890 003d3a65 01681048 53069705 ssleay32!SSL_CTX_flush_sessions+0x5a 01fbe8b8 003b93a0 02d719f8 0002 77230b8a ssleay32!ssl_update_cache+0xe5 01fbe8e4 003d557d 0003 0002 00407c29 ssleay32!ssl3_accept+0x950 01fbe8f0 00407c29 02d719f8 a298a10e 02ae8830 ssleay32!SSL_accept+0x1d ... 0:015> kb ChildEBP RetAddr Args to Child 02ceddf8 76cec752 0002 02cedfb4 0001 ntdll!NtWaitForMultipleObjects+0xc 02cedf7c 7690564b 0002 KERNELBASE!WaitForMultipleObjectsEx+0x10b 02cedff0 769057f5 02cee0dc 02cee0dc kernel32!WerpReportFaultInternal+0x1c4 02cee004 768d780f 02cee0dc 02cee0ac 76d708dc kernel32!WerpReportFault+0x6d 02cee010 76d708dc 02cee0dc 0001 c33b8f5c kernel32!BasepReportFault+0x19 02cee0ac 7775bf2c 02cee0dc 777230b4 fffe KERNELBASE!UnhandledExceptionFilter+0x1f1 02cee0b4 777230b4 fffe 7772e728 02ceffd4 ntdll!__RtlUserThreadStart+0x57 02cee0c8 776e5246 ntdll!_EH4_CallFilterFunc+0x12 02cee0f0 776e51b1 777ce1e0 7770f810 ntdll!_except_handler4_common+0x8e 02cee110 77722e71 02cee214 02ceffc4 02cee264 ntdll!_except_handler4+0x20 02cee134 77722e43 02cee214 02ceffc4 02cee264 ntdll!ExecuteHandler2+0x26 02cee1fc 77722cbb 02cee214 02cee264 02cee214 ntdll!ExecuteHandler+0x24 02cee1fc 77731c10 02cee214 02cee264 02cee214 ntdll!KiUserExceptionDispatcher+0xf 02cee6d8 7773521c 00f1 1668b140 0e00 ntdll!RtlpHeapFreeListCompare+0x12 02cee6f8 77731c77 00f1 077f 77731bfe ntdll!RtlpHeapFindListLookupEntry+0x74 02cee720 77735cc1 00f1 0e00 0258a000 ntdll!RtlpFindEntry+0x49 02cee748 776ff85b 00f1 0400 0e00 ntdll!RtlpInsertFreeBlock+0x17d 02cee79c 7773b1db 00f1 0258a000 0e00 ntdll!RtlpDeCommitFreeBlock+0x9d 02cee824 77732664 0258a000 0258a008 ntdll!RtlpFreeHeap+0x219 02cee848 74b74c39 00f1 0258a008 ntdll!RtlFreeHeap+0x206 02cee894 004825bd 0258a008 013c9460 004bd045 msvcr80!free+0xcd 02cee8a0 004bd045 0258a008 0258a008 libeay32!CRYPTO_free+0x1d 02cee8b8 00379377 013c9460 02811908 74d60b8a libeay32!BUF_MEM_free+0x25 02cee8e4 0039557d 0003 0002 00407c29 ssleay32!ssl3_accept+0x927 02cee8f0 00407c29 02811908 b5ab33b8 024d80c0 ssleay32!SSL_accept+0x1d ... ntdl
