OpenSSL Heartbeat Extension Vulnerability
Hi All, Please let me know is this vulnerability will effect the products which are using openssl version less than openssl 1.0.1 Thanks, Gayathri
Re: OpenSSL Heartbeat Extension Vulnerability
from what i know: https://www.openssl.org/news/secadv_20140407.txt OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. 2014-04-14 3:21 GMT-03:00 Gayathri Manoj gayathri.an...@gmail.com: Hi All, Please let me know is this vulnerability will effect the products which are using openssl version less than openssl 1.0.1 Thanks, Gayathri -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
Re: OpenSSL Heartbeat Extension Vulnerability
more news: https://www.openssl.org/news/ 2014-04-14 3:35 GMT-03:00 Roberto Spadim robe...@spadim.com.br: from what i know: https://www.openssl.org/news/secadv_20140407.txt OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. 2014-04-14 3:21 GMT-03:00 Gayathri Manoj gayathri.an...@gmail.com: Hi All, Please let me know is this vulnerability will effect the products which are using openssl version less than openssl 1.0.1 Thanks, Gayathri -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
Re: OpenSSL Heartbeat Extension Vulnerability
Thanks Roberto for the details information. On Mon, Apr 14, 2014 at 12:07 PM, Roberto Spadim robe...@spadim.com.brwrote: more news: https://www.openssl.org/news/ 2014-04-14 3:35 GMT-03:00 Roberto Spadim robe...@spadim.com.br: from what i know: https://www.openssl.org/news/secadv_20140407.txt OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. 2014-04-14 3:21 GMT-03:00 Gayathri Manoj gayathri.an...@gmail.com: Hi All, Please let me know is this vulnerability will effect the products which are using openssl version less than openssl 1.0.1 Thanks, Gayathri -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
Re: OpenSSL Heartbeat Extension Vulnerability
=] you are wellcome 2014-04-14 3:48 GMT-03:00 Gayathri Manoj gayathri.an...@gmail.com: Thanks Roberto for the details information. On Mon, Apr 14, 2014 at 12:07 PM, Roberto Spadim robe...@spadim.com.brwrote: more news: https://www.openssl.org/news/ 2014-04-14 3:35 GMT-03:00 Roberto Spadim robe...@spadim.com.br: from what i know: https://www.openssl.org/news/secadv_20140407.txt OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. 2014-04-14 3:21 GMT-03:00 Gayathri Manoj gayathri.an...@gmail.com: Hi All, Please let me know is this vulnerability will effect the products which are using openssl version less than openssl 1.0.1 Thanks, Gayathri -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
overview of server certificate mechanism with open ssl
Hello I have some generic questions about usage of openssl for https; i'm not into security, and i 'dont know very well openssl, so maybe my questions will appear a little noob, sorry if it does Just for info, i'm developping a client app that have to interact with server. I'm on linux and windows, in c++, using libneon. I have to discuss with a server using a self signed certificate (server and clients will be in a LAN, not over internet). I know how to check in my app whether the certificate is valid or not, as it is self-signed and as i didn't configurate nothing special on client side, it is not (not CA trusted). I plan to let user decide whether they want to trust or not, allowing them to add exception (exactly as browsers do) - My first question is : is it safe to store the server certificate on client side, in order to compare it ? I guess it's not since it could be stolen from client side ? a solution would be to store it as md5 ? Then at each connection, get server certificate, compute md5 and compare ? And if I decided to declare that certificate as safe, I have to put the server certificate as CA certified on client installation, as in link http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl ? But in that way too it could be stolen from client side, am I wrong ? Hope my questions are clear, Thanx in advance for help :)
Re: Heart bleed with 0.9.8 and 1.0.1
Will client respond for heart beat request even if server doesn't support heart beat . ? Which version of ssl this heart beat in introduced ? I am assuming as the client know that the session establish with sever doesn't support heart beat it will not respond am I correct ? On Sunday, April 13, 2014, Jin Jiang [via OpenSSL] ml-node+s6102n49373...@n7.nabble.com wrote: Hi, I think your client is vulnerable, if the attacker can touch your client. Regards, Jin On Fri, Apr 11, 2014 at 5:32 PM, cvishnuid [hidden email]http://user/SendEmail.jtp?type=nodenode=49373i=0 wrote: Hi I am having 0.9.8 open ssl libraries in my server and 1.0.1 in my client. Am I venerable to heart bleed attach? Regards, Vishnu. -- View this message in context: Heart bleed with 0.9.8 and 1.0.1http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300.html Sent from the OpenSSL - User mailing list archivehttp://openssl.6102.n7.nabble.com/OpenSSL-User-f3.htmlat Nabble.com. -- If you reply to this email, your message will be added to the discussion below: http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300p49373.html To unsubscribe from Heart bleed with 0.9.8 and 1.0.1, click herehttp://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=49300code=Y3Zpc2hudWlkQGdtYWlsLmNvbXw0OTMwMHwxODg0NTQ2MTc0 . NAMLhttp://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300p49374.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
Re: Help me for ECDHE algorithm
xxx.c is my program file. So, i'm compile simply like cc xxx.c . I am Gettting errors as below: xxx.c:(.text+0x19): undefined reference to `EVP_PKEY_CTX_new' xxx.c:(.text+0x30): undefined reference to `EVP_PKEY_derive_init' xxx.c:(.text+0x48): undefined reference to `EVP_PKEY_derive_set_peer' xxx.c:(.text+0x68): undefined reference to `EVP_PKEY_derive' xxx.c:(.text+0x88): undefined reference to `EVP_PKEY_derive' collect2: ld returned 1 exit status -- View this message in context: http://openssl.6102.n7.nabble.com/Help-me-for-ECDHE-algorithm-tp49168p49377.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
Possible Issue
possible vulnerable file: openssl-1.0.1g/ssl/d1_clnt.c Line: 155 unsigned char sctpauthkey[64]; fixed sized arrays can be overflowed. To fix the problem, use functions that limit length, or ensure that the size is larger than the maximum possible length. It's avoid us attack like buffer overflow! Best Regards!
Re: seems openssl version 1.0.1g also infected
Hello! What does `ldd /path/to/httpd` says? Cheers, Fedor. On Mon, Apr 14, 2014 at 12:17 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote: Hi Team, I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I found the same openssl vulnerability issue with my ssl certificate. I have installed new openssl bugfixed version 1.0.1g and create csr and key file from this. Also i have installed this on the server. I have restarted apache service and server many times after installation. But still it is showing my website vulnerable. Can you please guide me what am i missing now ? Thanks and Regards, Lokesh Jangir
RE: Heart bleed with 0.9.8 and 1.0.1
hi, Will client respond for heart beat request even if server doesn't support heart beat . ? no. both systems need to have some heartbeat code present. Which version of ssl this heart beat in introduced ? same as all the original advisories have said 1.0.1 - fixed in 1.0.1g but patches to previous versions have been released. ie basics unpatched 1.0.1 openSSL server (pre 1.0.1g) - vulnerable to dodgy client attack unpatched 1.0.1 openSSL client (pre 1.0.1g) - vulnerable to a dodgy server attacking it remember...this attack isnt about honouring proper communication. its about circumventing usual conversation - so even if the Application doesnt use heartbeat, the APIs its using for session establishment do - and thats where the attack vector lives. alan
Re: Possible Issue
On 14 Apr 2014, at 08:33, Me ugobejishv...@gmail.com wrote: possible vulnerable file: openssl-1.0.1g/ssl/d1_clnt.c Line: 155 unsigned char sctpauthkey[64]; fixed sized arrays can be overflowed. To fix the problem, use functions that limit length, or ensure that the size is larger than the maximum possible length. It's avoid us attack like buffer overflow! Hi, as far as I read the code, the variable sctpauthkey is filled via SSL_export_keying_material(s, sctpauthkey, sizeof(sctpauthkey), labelbuffer, sizeof(labelbuffer), NULL, 0, 0); which only fills in sizeof(sctpauthkey) bytes. It is then used in BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY, sizeof(sctpauthkey), sctpauthkey); which is also fine, I think. The constant 64 comes from the second sentence in https://tools.ietf.org/html/rfc6083#section-4.8 Please let me know how an overflow can happen. Best regards Michael Best Regards! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Who uses heartbeat?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Roberto Spadim Sent: Sunday, 13 April, 2014 13:53 The problem isn't new features the problem is how to write tests that should find security problems and tests to find bugs A false dichotomy, as anyone with any significant experience in software development should recognize. Adding features increases the size of the code base and so increases the number of possible bug points; and due to combinatorial explosion, it greatly increases the number of cases to test. As Steve Marquess pointed out, the issue is resources, plain and simple. Yes, in the specific case of Heartbleed, it would have helped to have rejected Robin Seggelmann's Heartbeat patch or review it more thoroughly. But other security issues are far more subtle and difficult to find by testing. In retrospect, the bug in Seggelmann's code is obvious; I looked at the diff for that commit and spotted it in seconds. But this is an area I have experience with and so I'm accustomed to looking for input overruns in untrusted data - it's the sort of thing you have to get used to doing when writing Wireshark dissectors and the like. A similarly serious bug in another area could easily escape me, and the same goes for all code reviewers: we have classes of faults we've been trained to notice, and others we're blind to. Steve's message, and his previous one about the no doubt temporary surge in donations, has prompted me to talk to my management again about an OSF support contract. I think this was raised years ago when we first started including OpenSSL, in a small way, with a couple of products; but paying money when it isn't required is often the sort of thing that falls by the wayside, even when everyone has good intentions. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
corporate donation from Acano Ltd.
While the OpenSSL Software Foundation (OSF) has been moderately successful in obtaining enough funding to at least keep the lights on at OpenSSL for five years now, most of that funding is obtained through commercial work-for-hire contracts with specific deliverables. It is extremely rare to receive any institutional no-strings funding that can be used by the OpenSSL project for any purpose. Acano Ltd. (http://acano.com/) is an existing commercial client of OSF. I am pleased to report that in addition to that ongoing commercial work, Acano has recently given an outright donation to the OpenSSL project to be used without restriction or obligation as the team chooses. As a matter of policy we will generally not be disclosing the dollar amount of donations, but I will say that this donation will provide a greater benefit to OpenSSL than the net after expenses of the commercial contract work we are doing for them. -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
donation from Brennan Vincent
We are still getting a steady stream of donations via PayPal, most in small amounts ($5, $10), a few in the $50-$100-$200 range. As before I apologize for not sending a personal response to most. I would like to mention a donation of US$2,000 from Brennan Vincent, received with the comment Having a secure internet ... is worth a lot more than $2,000 to me. I find it notable that this a personal donation and not from corporate or institutional funds. For a long time now I have contended that charitable contributions, especially from individuals, are not suitable for funding the full scope of necessary OpenSSL development and maintenance activities. I still believe that to be the case, but am reminded by all of these donations that the OpenSSL team members are not the only ones who feel a responsibility for electronic security and privacy around the world. -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
Re: Help me for ECDHE algorithm
On 14 April 2014 05:42, chetan chet...@neominds.in wrote: xxx.c is my program file. So, i'm compile simply like cc xxx.c . I am Gettting errors as below: xxx.c:(.text+0x19): undefined reference to `EVP_PKEY_CTX_new' xxx.c:(.text+0x30): undefined reference to `EVP_PKEY_derive_init' xxx.c:(.text+0x48): undefined reference to `EVP_PKEY_derive_set_peer' xxx.c:(.text+0x68): undefined reference to `EVP_PKEY_derive' xxx.c:(.text+0x88): undefined reference to `EVP_PKEY_derive' collect2: ld returned 1 exit status You are not linking to libcrypto. I don't know anything about the platform you are compiling for, but typically in gcc you would use something like: gcc -o xxx xxx.c -lcrypto Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CMS Decrypt returns wrong error message on mismatching private key after Bleichenbachers FIX
This commit:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=146b52edd122f55e2b2bfeb486dae8dbe96f739e
Introduced an error/new behavior, specifically this file
http://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff;f=crypto/cms/cms_smime.c;h=8c56e3a8520d73802c7ea00f81e81c1d574bc49b;hp=a40307605bde5467e46f7cea4ca59a055e46196e;hb=146b52edd122f55e2b2bfeb486dae8dbe96f739e;hpb=13747c6fdabbba33cb187a133548b73d41ae282d
When you now call
openssl cms -decrypt -inkey mykey.pem -in encrypted_mail.txt -out
openssl_decrypted.txt
where mykey.pem is the wrong private key the following error is returned:
digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:474:
Moreover, the outfile openssl_decrypted.txt is filled with 120 bytes of garbage.
Previous versions - correctly reported
CMS routines:CMS_decrypt_set1_pkey:no matching recipient:cms_smime.c:640:
To inform that the message has been encrypted to another recipient. Moreover,
if decryption failed - not ever was something written to the -out file.
The code and comment makes no sense
+ /* If no cert and not debugging always return success */
+ if (!cert !debug)
+ {
+ ERR_clear_error();
+ return 1;
+ }
Why would you always return a success ?
If you change this line to to remove return 1 then the normal code handling
happens
CMSerr(CMS_F_CMS_DECRYPT_SET1_PKEY, CMS_R_NO_MATCHING_RECIPIENT);
return 0;
Moreover - with the undocumented hidden option (only found via grepping the
sources) - you can fix this with adding the
-debug_decrypt option.
This option will tell you the real reason why decryption failed.
Please consider reverting/ or fixing this debug behavior - otherwise its hard
to understand why automated smime gateways have issues decrypting messages.
Otherwise update the documentation - that under no circumenstances the
CMS_R_NO_MATCHING_RECIPIENT is ever returned - you might as well remove it from
any header file.
Thanks
BTW: The 120 random byte in the outfile - is that the result of the failed
decryption with a symmetric random key ? Regarding MMA - (Bleichenbacher's
attack on PKCS #1 v1.5 RSA padding)
Re: OpenSSL Security Advisory
Ah, of course! I was so focused on not accessing that routine and not being able to just link in the obj files that the obvious solution of using the library properly escaped me! Thanks. After a Visual Studio 2012 build in directory: E:\usr_local\src\openssl-1.0.1f_32 I then was able put that change in and to compile and link very easily: cl -IE:\usr_local\src\openssl-1.0.1f_32\inc32 heartbleed.c /c link heartbleed.obj E:\usr_local\src\openssl-1.0.1f_32\out32dll\libeay32.lib E:\usr_local\src\openssl-1.0.1f_32\out32dll\ssleay32.lib I put those two dll files (ssleay32.dll and libeay32.dll) in my directory with the new exe from the build and it worked just fine. Thanks again to Tim Hudson, and of course to Rob Stradling for sharing the utility, Steve... On Fri, Apr 11, 2014 at 10:58 PM, Tim Hudson t...@cryptsoft.com wrote: On 11/04/2014 10:38 PM, Steven Kneizys wrote: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. The work around is trivial if you wanted to do that. Change to use the SSL_get_ssl_method function. This line: if (ssl3_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Simply becomes: if (SSL_get_ssl_method(v_ssl)-ssl_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Tim. -- Steve Kneizys Senior Business Process Engineer Voice: (610) 256-1396 [For Emergency Service (888)864-3282] Ferrilli Information Group -- Quality Service and Solutions for Higher Education web: http://www.ferrilli.com/ http://www.figsolutions.com/ Making you a success while exceeding your expectations.
Re: overview of server certificate mechanism with open ssl
Hi, A certificate is not secret information itself. It may be distributed over LAN or Internet as free. A certificate doesn't contain a private key. A certificate can not be stolen. Every certificate has a special field inside it - fingerprint. This field contain sha-1 or md5 digest value which must be unique. You could use this fingerprint to decide whether certificate is trusted or not. Good luck! 14.04.2014 13:44 пользователь drkmkzs drkm...@gmail.com написал: Hello I have some generic questions about usage of openssl for https; i'm not into security, and i 'dont know very well openssl, so maybe my questions will appear a little noob, sorry if it does Just for info, i'm developping a client app that have to interact with server. I'm on linux and windows, in c++, using libneon. I have to discuss with a server using a self signed certificate (server and clients will be in a LAN, not over internet). I know how to check in my app whether the certificate is valid or not, as it is self-signed and as i didn't configurate nothing special on client side, it is not (not CA trusted). I plan to let user decide whether they want to trust or not, allowing them to add exception (exactly as browsers do) - My first question is : is it safe to store the server certificate on client side, in order to compare it ? I guess it's not since it could be stolen from client side ? a solution would be to store it as md5 ? Then at each connection, get server certificate, compute md5 and compare ? And if I decided to declare that certificate as safe, I have to put the server certificate as CA certified on client installation, as in link http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl ? But in that way too it could be stolen from client side, am I wrong ? Hope my questions are clear, Thanx in advance for help :)
RE: Possible Issue
From: Me [mailto:ugobejishv...@gmail.com] Sent: Monday, April 14, 2014 7:34 AM possible vulnerable file: openssl-1.0.1g/ssl/d1_clnt.c Line: 155 unsigned char sctpauthkey[64]; fixed sized arrays can be overflowed. True, but only because ALL arrays can be overflowed no matter how they are sized or allocated. To fix the problem What problem? use functions that limit length, or ensure that the size is larger than the maximum possible length. So show us the problem. What code accesses this array without either: - explicitly limiting the length to the length of this array; or - never accessing more than 64 bytes? It's avoid us attack like buffer overflow! To avoid buffer overflow attacks, the code must never overflow buffers. The sizes of the buffers and the ways they are allocated are not directly relevant. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
some nice pictures how the bug works: http://www.xkcd.com/1354/ HIH matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Who uses heartbeat?
2014-04-14 10:02 GMT-03:00 Michael Wojcik michael.woj...@microfocus.com: From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Roberto Spadim Sent: Sunday, 13 April, 2014 13:53 The problem isn't new features the problem is how to write tests that should find security problems and tests to find bugs A false dichotomy, as anyone with any significant experience in software development should recognize. Adding features increases the size of the code base and so increases the number of possible bug points; and due to combinatorial explosion, it greatly increases the number of cases to test. yes, just one point before continue, openssl is very good, i use it a lot, and i love it no problem about a bug here, just correct the code, upgrade the lib and test the system if it's ok yes i know code security systems are complex and many things we can't cover before someone try to execute an anormal code As Steve Marquess pointed out, the issue is resources, plain and simple. Yes, in the specific case of Heartbleed, it would have helped to have rejected Robin Seggelmann's Heartbeat patch or review it more thoroughly. But other security issues are far more subtle and difficult to find by testing. In retrospect, the bug in Seggelmann's code is obvious; I looked at the diff for that commit and spotted it in seconds. But this is an area I have experience with and so I'm accustomed to looking for input overruns in untrusted data - it's the sort of thing you have to get used to doing when writing Wireshark dissectors and the like. A similarly serious bug in another area could easily escape me, and the same goes for all code reviewers: we have classes of faults we've been trained to notice, and others we're blind to. Steve's message, and his previous one about the no doubt temporary surge in donations, has prompted me to talk to my management again about an OSF support contract. I think this was raised years ago when we first started including OpenSSL, in a small way, with a couple of products; but paying money when it isn't required is often the sort of thing that falls by the wayside, even when everyone has good intentions. nice =) i think we are on the right way, openssl is very good, and a bug is ok, like mysql some years ago... a user could login just retrying a wrong password, no problem, they found the bug, and good guys corrected the database, like here, the important part is, know the bug, and correct it, everyone can update the lib and we are ok again :) i really appreciate the openssl guys work, thanks guys -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle
Re: OpenSSL Security Advisory
On 11/04/2014 12:58 AM, Viktor Dukhovni wrote: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 If you are using s_client for testing then you should add the -msg option and see what is being sent. Responding to a correctly formed heartbeat request is not an error - it is an indication that the server remains configured with heartbeat support. For example repeating that command as: (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 -msg And you can see the decoded heartbeat request and response - all with legal length values - 0x12 indicating 18 bytes of payload followed by the required 16 bytes of padding all exactly adding up to match the record size (3+18+16=37 which is the 0x0025 length field). HEARTBEATING ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatRequest 01 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 60 e9 48 9e c1 6e 69 f4 fd 48 60 a9 35 bd 0c c3 ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatResponse 02 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 75 07 79 df 92 dd b2 3c a6 9d 73 12 54 9c 66 57 read R BLOCK A number of users have provided various tools for testing whether or not an exploit is present. None of these tools are officially supported or blessed so are all use-at-your-own-risk. A couple of the tools others have mentioned already on this list are: https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl https://gist.github.com/robstradling/10363389 There are a whole range of checking tools that have varying approaches to how they test. Understanding what each tool does is important to understanding the effectiveness of their results in terms of claiming vulnerable or not vulnerable to the issue. Most people I've interacted with are using a combination of tools. The appropriate response to the issue is to follow the advice in the advisory - either move to a version with the patch for the defect applied or move to a version where the heartbeat code has been removed completely via compilation of the library with -DOPENSSL_NO_HEARTBEATS. If you connect to a site which does not support heartbeat (compiled out) then you will get something like this: HEARTBEATING 140153106511512:error:1413B16D:SSL routines:tls1_heartbeat:peer does not accept heartbearts:t1_lib.c:4049: ??? [length 0005] 15 03 01 00 20 TLS 1.0Alert [length 0002], warning close_notify 01 00 It is also possible to use the message callback function to block the response to heartbeat in application code if your library hasn't been patched. However the right solution is to fix the library via either of the methods mentioned in the advisory at https://www.openssl.org/news/secadv_20140407.txt Tim. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
New and bleeding - Install Win64 problems
Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: New and bleeding - Install Win64 problems
You could instal Visual Studio Express, and since you're [presumably] using Windows NT 6.x (in 64-bit mode), the latest version (2013?) should work fine. With that installed, you now have the 64-bit C compiler (cl.exe) available. Besides, even if you could get it to work without installing Visual Studio, you would end up missing the std. C header files and libc libraries, which are only included with Visual Studio. You could also switch to MinGW or Cygwin and use gcc, but I don't have too much experience with either development environment. Cheers, _RVX -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Aaron Bahmer Sent: Monday, April 14, 2014 6:22 PM To: openssl-users@openssl.org Subject: New and bleeding - Install Win64 problems Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 __ 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: New and bleeding - Install Win64 problems
If you want, I *can* provide you with a precompiled binary of OpenSSL 1.0.1g, unless you MUST have 64-bit native. (I have compiled it using Visual Studio .NET 2002, on Windows 2000. It's a 32-bit DLL.) Cheers, _RVX -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Aaron Bahmer Sent: Monday, April 14, 2014 6:22 PM To: openssl-users@openssl.org Subject: New and bleeding - Install Win64 problems Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 __ 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: New and bleeding - Install Win64 problems
P.P.S. 'ml64.exe' is the 64-bit Microsoft Macro Assembler. It's the only assembly source that needs to be compiled with MASM; the rest are compiled using NASM. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Aaron Bahmer Sent: Monday, April 14, 2014 6:22 PM To: openssl-users@openssl.org Subject: New and bleeding - Install Win64 problems The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: New and bleeding - Install Win64 problems
Or there's always the semi-official Shining Light binary distribution for 32-bit and x64 Windows at http://slproweb.com/products/Win32OpenSSL.html From: Ricardo Villegas [mailto:ric...@rickyv.tk] Sent: Tuesday, April 15, 2014 1:49 AM If you want, I *can* provide you with a precompiled binary of OpenSSL 1.0.1g, unless you MUST have 64-bit native. (I have compiled it using Visual Studio .NET 2002, on Windows 2000. It's a 32-bit DLL.) Cheers, _RVX -Original Message- From: Aaron Bahmer Sent: Monday, April 14, 2014 6:22 PM To: openssl-users@openssl.org Subject: New and bleeding - Install Win64 problems Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: New and bleeding - Install Win64 problems
On 4/14/2014 4:21 PM, Aaron Bahmer wrote: Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 If you want to build it yourself, I *HIGHLY* recommend the NASM route. My build environment is: Visual Studio 2008 (yeah, I need to upgrade, but the latest VS Express should work just fine) Windows SDK Strawberry Perl Portable (infinitely better than ActiveState's garbage) NASM (whatever the latest release is) I've had a lot of success with NASM, whereas MASM has generally been the equivalent of getting a root canal without anesthetic. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: New and bleeding - Install Win64 problems
64-bit MASM is only required for the one source file [uptable.asm] in the /ms directory; the actual OpenSSL source is compiled using NASM. _RVX If you want to build it yourself, I *HIGHLY* recommend the NASM route. My build environment is: Visual Studio 2008 (yeah, I need to upgrade, but the latest VS Express should work just fine) Windows SDK Strawberry Perl Portable (infinitely better than ActiveState's garbage) NASM (whatever the latest release is) I've had a lot of success with NASM, whereas MASM has generally been the equivalent of getting a root canal without anesthetic. __ 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?
In my code, the server thread listen for incoming connection request, when there is a new request, it spawns a new client thread to handle the request. Does it need synchronization between multiple client threads by following the way pointed out here https://www.openssl.org/support/faq.html#PROG1? Is there a possibility that some OpenSSL structures are being shared between the threads, right? 2014-03-26 17:37 GMT+08:00 Bodo Moeller bmoel...@acm.org: jeff jeff.2234...@gmail.com: 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
RE: New and bleeding - Install Win64 problems
I simply provide it for size considerations--just a drop-in replacement where the old openssl library went--and the one dependency on libc (msvcr70.dll) It's a default build (32-bit, multi-threaded DLL) without debugging symbols. It's mainly there for compatibility purposes; even *I* am transitioning away from Windows 2000/XP (NT 5.x). Unlike the build provided by Shining Light, it requires no special configuration in version 4 systems, except maybe the Microsoft Layer for Unicode on Windows 9x/Me. _RVX -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeremy Farrell Sent: Monday, April 14, 2014 8:10 PM To: openssl-users@openssl.org Subject: RE: New and bleeding - Install Win64 problems Or there's always the semi-official Shining Light binary distribution for 32-bit and x64 Windows at http://slproweb.com/products/Win32OpenSSL.html From: Ricardo Villegas [mailto:ric...@rickyv.tk] Sent: Tuesday, April 15, 2014 1:49 AM If you want, I *can* provide you with a precompiled binary of OpenSSL 1.0.1g, unless you MUST have 64-bit native. (I have compiled it using Visual Studio .NET 2002, on Windows 2000. It's a 32-bit DLL.) Cheers, _RVX -Original Message- From: Aaron Bahmer Sent: Monday, April 14, 2014 6:22 PM To: openssl-users@openssl.org Subject: New and bleeding - Install Win64 problems Sorry for the newbie question, but the archives didn't provide me any help. I'm dealing with the heartbleed bug, so updating openssl from 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat. I downloaded the new openssl tarball (albeit with non-matching MD5 signatures) and unpacked it to my server. I then opened the Install.w64 file for guidance. Here's an excerpt where I am working: Compiling procedure --- You will need Perl. You can run under Cygwin or you can download ActiveState Perl from http://www.activestate.com/ActivePerl. You will need Microsoft Platform SDK, available for download at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per April 2005 Platform SDK is equipped with Win64 compilers, as well as assemblers, but it might change in the future. To build for Win64/x64: perl Configure VC-WIN64A ms\do_win64a nmake -f ms\ntdll.mak cd out32dll ..\ms\test So, I downloaded and installed ActivePerl and installed the Windows SDK for Win 7 and .NET 4. I had to play with the Windows PATH environment variable a bit to get things to work. The Configure command seems to work. The ms\do_win64a has a problem on one line: C:\Installers\openssl-1.0.1gml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. ...but I threw caution to the wind and tried to proceed anyhow. The nmake command is where I crash and burn. It seems to get most of the way through, then chokes out with this error message: NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.EXE' : return code '0xc135' ...in researching this, it sounds like I need to run devenv.exe to work within the VS environment and then execute the cl command. However, having only installed the runtime libraries for VS9 and VS10, I don't have a devenv.exe to run. If I change to the 32bit installation from its instruction file, the nmake command still fails with this same error. Could this still be a path problem? Or??? Thanks. == Aaron Bahmer Director, Instructional Technology Eastern Wyoming College http://ewc.wy.edu | (307) 532-8284 1-866-327-8996 (1-866-EAST WYO) x8284 __ 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
Build openssl with STORE
Hi, List! Sorry for my fool questions, I'm a nooby in openssl. How can I build openssl with STORE support? I specified the 'experimental-store' and executed configure. However, DependencyWalker utility doesn't show any STORE_* functions as exported... How can I fix it? Thanks in advance, Shinshillov
