Re: OpenSSL version 1.0.1g fails to link on Win32

On 4/9/2014 8:03 PM, Jeremy Farrell wrote: Googling "check_winnt" suggests openssl/e_os.h. findstr /sic:"check_winnt" * Is, IMO, easier and more informative than using Google. Results in: apps\apps.c:if (check_winnt()) crypto\bio\bss_log.c: if (check_winnt()) crypto\cryptlib.c:

Re: OpenSSL Security Advisory

> > -Original Message- > > From: Matthias Apitz [mailto:g...@unixarea.de] > > Sent: Thursday, April 10, 2014 6:41 AM > > To: Apitz,Matthias > > Subject: Fwd: RE: OpenSSL Security Advisory > > > > - Forwarded message from "Salz, Rich" - > > > > Date: Wed, 9 Apr 2014 15:43:28 -0400

Re: OpenSSL version 1.0.1g fails to link on Win32

Thanks, Thomas; I had found the calls in the crypto/ source files, but I didn't search at the right level to find the #defines. After updating e_os.h, I am now able to compile & link the original source code for 1.0.1g. Sorry for the false alarm. On 04/10/2014 03:52, "Thomas J. Hruska" wrot

Re: OpenSSL 1.0.1g Upgarade Issue

On 4/10/2014 6:23 AM, Dedhia, Pratik wrote: Hi Team, I’m trying to upgrade OpenSSL to 1.0.1g version from 1.0.1f version to resolve security issue but getting error while restarting Apache server. Below are the steps of OpenSSL upgradation: 1.Extracted the tarball downloaded from OpenSSL site

Re: OpenSSL version 1.0.1g fails to link on Win32

Hi Geoffrey, It's defined in e_os.h because it's been deprecated in Win8. Microsoft wants you to use GetVersionEx() or VerifyVersionInfo(). Part of their plot to convince us old-timers that the world is no longer flat and that COM is actually a reasonable way to write code... Next thing they will

Re: Help me for ECDHE algorithm

Thanks for giving time to me. I was given a task that i have to implement ECDHE algorithm means i can use openssl. So, can you please tell me what i have to do after generatic public and private key files. How to generate shared secret and what next after that. Thanks again -- View this messag

Error for EVP_PKEY_CTX_new()

#include #include main() { EVP_PKEY_CTX *ctx; unsigned char *skey; size_t skeylen; EVP_PKEY *pkey, *peerkey; /* NB: assumes pkey, peerkey have been already set up */ ctx = EVP_PKEY_CTX_new(pkey,NULL); if (!ctx) /* Error occurred */ if (EVP_PKEY_derive_init(ctx) <= 0) /

Re: Help me for ECDHE algorithm

On 10 April 2014 07:29, chetan wrote: > Thanks for giving time to me. I was given a task that i have to implement > ECDHE algorithm means i can use openssl. > So, can you please tell me what i have to do after generatic public and > private key files. How to generate shared secret and what next a

Re: Error for EVP_PKEY_CTX_new()

On 10 April 2014 07:54, chetan wrote: > I write a code like this. but when i compile it show's error "Undefined > EVP_PKEY_derive". > what is the reason for that? What version of openssl are you using? EVP_PKEY_derive is only in OpenSSL 1.0.0 and later versions. Matt ___

Re: [Bulk] Re: OpenSSL version 1.0.1g fails to link on Win32

"Thomas J. Hruska" wrote: Is, IMO, easier and more informative than using Google. Results in: apps\apps.c:if (check_winnt()) crypto\bio\bss_log.c: if (check_winnt()) crypto\cryptlib.c:if (check_winnt() && OPENSSL_isservice() > 0) crypto\rand\rand_win.c: if (check_winnt() &&

FIPS 2.0: Heart Bleed

Just to verify, heart bleed doesn't look like it effects the fipscanister. I can just recompile openssl 1.0.1c with the no heart beat option and my current canister and still retain FIPS certification.

Re: OpenSSL Security Advisory

On 09/04/14 20:43, Salz, Rich wrote: Can you please post a "good" and a "bad" server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the

Encryption Error (Symmetric)

Hi Support, I have implemented a demo project at enables encrypting a plaintext based on 2 input param values. Version: 1.01f Cipher Mode: EVP_aes_256_cbc Salt[]={1,2,3,4,5,6,7,8} Digest = md5 (functions encapsulated in DLL) *Encrypt(Param1, Param2, PlainText)* >> Param1 +HardCoded+Param2 = *Pass

Re: FIPS 2.0: Heart Bleed

Yes, you are correct. -ag -- sent via 100% recycled electrons from my mobile command center. > On Apr 10, 2014, at 5:54 AM, Jason Todd wrote: > > Just to verify, heart bleed doesn't look like it effects the fipscanister. I > can just recompile openssl 1.0.1c with the no heart beat option and

Re: Encryption Error (Symmetric)

On 10 April 2014 13:08, Buddhika E. wrote: > Could anybody provide me some solution? > > Many Thanks, > Buddhika > > PS: I attached a code sample > > I haven't gone all through your code, but spotted this: if(!EVP_DecryptUpdate(&ctx, out, &buflen, cipher, strlen(cipher))) { You can't use strle

affected Openssl versioning for heartbleed clarity

Say all . if #Heartbleed &src=hash> exploits #OpenSSL &src=hash> 1.0.1 & 1.0.2-beta releases then if I

Re: OpenSSL 1.0.1g Upgarade Issue

On Thu, 10 Apr 2014 11:35:40 +0200 Jakob Bohm wrote: > On 4/10/2014 6:23 AM, Dedhia, Pratik wrote: > > Hi Team, > > > > I’m trying to upgrade OpenSSL to 1.0.1g version from 1.0.1f version > > to resolve security issue but getting error while restarting Apache > > server. > > > > Below are the ste

Re: OpenSSL Security Advisory

On Thu, Apr 10, 2014 at 10:57:35AM +0200, Matthias Apitz wrote: > I have instrumented an openssl 1.0.1f as posted by Victor: > > guru@hein:~/openssl-1.0.1f> diff ssl/t1_lib.c.unpatched > ssl/t1_lib.c > 2671c2671 > < s2n(payload, p); > --- > > s2n(0x4000, p); > > but I still see HEART

Re: FIPS 2.0: Heart Bleed

One other quick question. Is it possible to use the fipscanister from 1.0.1c with 1.0.1g and maintain compliance? Assuming that even compiles On Thu, Apr 10, 2014 at 9:32 AM, ag@gmail wrote: > Yes, you are correct. > > -ag > > -- > sent via 100% recycled electrons from my mobile command center.

Re: FIPS 2.0: Heart Bleed

On 04/10/2014 11:36 AM, Jason Todd wrote: > One other quick question. Is it possible to use the fipscanister from > 1.0.1c with 1.0.1g and maintain compliance? Assuming that even compiles fipscanister is not "from" 1.0.1 anything; it is from the OpenSSL FIPS Object Module 2.0, i.e. one of the open

openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seamed to be fine. But after a while an error popped up in sendmail log: Apr 10 10:13:45 mail sendmail[17568]: STARTTLS=client, error: connect failed=-1, reason=tlsv1 alert decode error, SSL_error=1, errno=0, retry=-1 Apr 10 10:13:45 m

Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

On Thu, Apr 10, 2014 at 06:39:21PM +0200, Dominik Mahrer (Teddy) wrote: [ The subject is a bit dramatic, Sendmail did not break, rather you're experiencing interop issues with one site. ] > Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seamed to be > fine. But after a while an err

RE: OpenSSL version 1.0.1g fails to link on Win32

Perhaps, if you already have the source tree available in an environment where you can run findstr on it, and know about findstr. Google does a much quicker and easier job on this problem for everyone else, and is arguably more informative since it gives the check-in comments as well as at least

Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

Thanks Viktor OK, I googled about IronPort-Systems (one can never learn enough). The output requested: > openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 CONNECTED(0003) depth=0 C = US, ST = California, L = San Bruno, O = "IronPort Systems, Inc.", CN = IronPort Applianc

Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

On Thu, Apr 10, 2014 at 09:58:47PM +0200, Dominik Mahrer (Teddy) wrote: > > openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA > Server public key is 1024 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NON

Looking more at the Heatbleed

We are looking more deeply into Heartbleed to determine the risk to our proprietary, non-open application. 1. Background summary: Our proprietary client/server protocol is protected by TLS with OpenSSL 1.0.1c and 1.0.1e. We do not respond to http or any other standard protocols. The se

Re: Looking more at the Heatbleed

On Thu, Apr 10, 2014 at 05:02:17PM -0400, mclellan, dave wrote: > We are looking more deeply into Heartbleed to determine the risk > to our proprietary, non-open application. Based on the below, it is vulnerable, and needs to be linked against a patched OpenSSL library, or one built with -DOPENSS

Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

On Thu, Apr 10, 2014 at 08:24:33PM +, Viktor Dukhovni wrote: > > > openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 > > Protocol : SSLv3 > > Cipher: DHE-RSA-AES256-SHA > > As expected, this works because SSLv3 sends no extensions. When I test with Postfix and

Re: OpenSSL version 1.0.1g fails to link on Win32

On 04/10/2014 05:31, Mike Bonnain wrote: > > Hi Geoffrey, > > It's defined in e_os.h because it's been deprecated in Win8. > Microsoft wants you to use GetVersionEx() or VerifyVersionInfo(). > Part of their plot to convince us old-timers that the world is no > longer flat and that COM is actua

Re: OpenSSL version 1.0.1g fails to link on Win32

Actually, I tried Google, and it split check_winnt into check winnt because I didn't put the quotes around it, and hence found lots of unrelated pages. I had only extracted crypto/ and ssl/ from the source tarball, so my "search" from Windows Explorer didn't find it. My own fault in both cases

Re: Looking more at the Heatbleed

1. OpenSSL allows heartbeats during handshake. 2. Handshake request can come from any peer and is responded to (client or server is immaterial). You don't prevent it, so a peer can send heartbeat request and your openssl endpoint shall respond. From what you describe, your application is vulnera

Re: Looking more at the Heatbleed

On 10 Apr 2014, at 2:02 PM, mclellan, dave wrote: > We are looking more deeply into Heartbleed to determine the risk to our > proprietary, non-open application. > 1. Background summary: Our proprietary client/server protocol is > protected by TLS with OpenSSL 1.0.1c and 1.0.1e. We do not

Re: Looking more at the Heatbleed

On Thu, Apr 10, 2014 at 06:16:33PM -0700, Wim Lewis wrote: > But if you're using TLS at all, then presumably this is because > the TCPIP network over which TLS is running is potentially insecure > in some way (e.g., it's the open internet); an attacker with the > ability to send packets on that la

Re: Looking more at the Heatbleed

hi guys, what about openssh, does it have some problem with this vulnerability? 2014-04-10 22:35 GMT-03:00 Viktor Dukhovni : > On Thu, Apr 10, 2014 at 06:16:33PM -0700, Wim Lewis wrote: > > > But if you're using TLS at all, then presumably this is because > > the TCPIP network over which TLS is

Re: Looking more at the Heatbleed

No. OpenSSH is not affected. See http://undeadly.org/cgi?action=article&sid=20140408063423 -ag -- sent via 100% recycled electrons from my mobile command center. > On Apr 10, 2014, at 6:39 PM, Roberto Spadim wrote: > > hi guys, what about openssh, does it have some problem with this > vulner

Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

"It seams that there is another difference between the two openssl versions then only the heartbleed bugfix." err, yes. The g release is a new minor release. I'd ALWAYS advise reading the changelog before deploying. .. You'd then have seen the new features (this is why vendors such as redhat a