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

Re: Help me for ECDHE algorithm

[chetan]

Thanks to you...it's working.
Now i have one last query for you.
I'm generating public and private key files using command line openssl. I
generated 2 .PEM files each for public and private key.
Now i want to generate shared secret from that files using APIs like
EVP_PKEY_derive and others. So,Can i do like this or not?
If yes than how?
thanks once again for help.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Help-me-for-ECDHE-algorithm-tp49168p49452.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

Could openssl foundation give itself rules not to accept money from intelligence agencies?

[Benjamin Schulz]

Hello, 
The openssl foundation writes here: 

https://www.openssl.org/support/acknowledgments.html 

"Please note that we ask permission to identify sponsors and that some sponsors 
we consider eligible for inclusion here have requested to remain anonymous."" 

and here: 

https://www.openssl.org/support/consulting.html[https://www.openssl.org/support/consulting.html]
 

"Does your company use the OpenSSL toolkit and need some help porting it to a 
new platform? Do you need a new feature added? Are you developing new 
cryptographic functionality for your product? 

To every secret service, this must sound like music in their ears. 

They can potentially  anonymously donate, and even hire the programmers to get 
"features" into openssl, similar to the situation with RSA. 

Please note that you as developers might not notice it, when you are hired to 
program a backdoor. It may be as simple as a client approaches you, asking you 
to "implement all Nist standards", and without thinking anything bad, you are 
putting something like Dual_EC into your library, thereby putting in a backdoor 
without noticing it yourself. 

If you want to know how great the interest of intelligence agencies is to 
manipulate encryption hardware, see this translated article from DER SPIEGEL: 

http://cryptome.org/jya/cryptoa2.htm[http://cryptome.org/jya/cryptoa2.htm] 

where it is revealed that the german secret service BND turned out to 
successfully own the majority of the shares of a major cryptographic hardware 
manufacturer and instructed the company how to manipulate their devices that 
BND could listen. 

The interest of the nsa in weakening crypto software is documented here in this 
New York Times article: 

http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0[http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0]
 


So I think the openssl foundation should take some measures that perhaps may 
help to scare intelligence agencies away from openssl in the future. 


Could the openssl foundation add official rules that 
a) it is not accepting money from intelligence agencies or companies that work 
for intelligence agencies and that, if it turned out, a given money comes from 
intelligence agencies or a contractor of them, the openssl foundation will 
return the money, and that this applies even to all earlier donations. 

b) that developers of openssl are not allowed to do contracting work for 
intelligence agencies and companies working for intelligence agencies, and that 
if it turned out a developer had such contracts, he may no longer work for 
openssl, and that this applies also for earlier contracts of the openssl 
developers. 

c) that the names of all companies who hire openssl developers must be 
published in the open on the openssl homepage, and that this applies also for 
the companies who hired openssl developers earlier 

d) that the companies who make donations to openssl will be published in the 
open on the openssl homepage and that this applies also for the companies who 
donated to openssl earlier.

e) and that donnations above a certain value, or a person donating very often 
is named publicly on the openssl website. 


If you incorporate these rules ito the openssl foundation, it may help to scare 
intelligence agencies away from openssl, since these agencies hate nothing more 
than publicity. Is it possible for the openssl foundation to do this? 

And by the way: 
Is there a book or something where one can learn the programming of openssl? I 
know a bit C++ and C and would be interested to look closer at the sourcecode. 
But I see that it is very large. Is there something that makes the entry in 
openssl programming easier? 

Best Wishes, 
Benjamin 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Heart bleed with 0.9.8 and 1.0.1

[cvishnuid]

Now i understood the  concept .. Till now i am assuming that attacker will
send only the heart beat request with out performing any SSL handshake
messages.

I was wrong . Attacker will establish a new connection and send all the
handshake messages and then the  faked heart beat request .









--
View this message in context: 
http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300p49425.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: Heart bleed with 0.9.8 and 1.0.1

[cvishnuid]

In my scenario if the client don't respond for heart beat request then my
client is safer ? 




--
View this message in context: 
http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300p49402.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

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

RE: New and bleeding - Install Win64 problems

[Ricardo Villegas]

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.1g>ml64 -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: Is it possible that calling ssl_accept in multi-threading circumstance will result in app to crash?

[2234822 jeff]

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 :

> 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
>
>

RE: New and bleeding - Install Win64 problems

[Ricardo Villegas]

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: New and bleeding - Install Win64 problems

[Thomas J. Hruska]

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.1g>ml64 -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

[Jeremy Farrell]

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.1g>ml64 -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

[Ricardo Villegas]

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.1g>ml64 -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

[Ricardo Villegas]

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.1g>ml64 -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

[Ricardo Villegas]

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.1g>ml64 -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

New and bleeding - Install Win64 problems

[Aaron Bahmer]

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.1g>ml64 -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: OpenSSL Security Advisory

[Tim Hudson]

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

Re: Who uses heartbeat?

[Roberto Spadim]

2014-04-14 10:02 GMT-03:00 Michael Wojcik :

> > 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: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)

[Matthias Apitz]

some nice pictures how the bug works: http://www.xkcd.com/1354/

HIH

matthias
-- 
Sent from my FreeBSD netbook

Matthias Apitz, , 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: Possible Issue

[Jeremy Farrell]

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: overview of server certificate mechanism with open ssl

[Vladimir Zatsepin]

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"  написал:

> 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: OpenSSL Security Advisory

[Steven Kneizys]

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  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/ 

Making you a success while exceeding your expectations.

CMS Decrypt returns wrong error message on mismatching private key after Bleichenbachers FIX

[Harakiri]

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: Help me for ECDHE algorithm

[Matt Caswell]

On 14 April 2014 05:42, chetan  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

donation from Brennan Vincent

[Steve Marquess]

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

corporate donation from Acano Ltd.

[Steve Marquess]

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

RE: Who uses heartbeat?

[Michael Wojcik]

> 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

Re: Possible Issue

[Michael Tuexen]

On 14 Apr 2014, at 08:33, Me  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: Heart bleed with 0.9.8 and 1.0.1

[Alan Buxey]

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: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Hello!

What does `ldd /path/to/httpd` says?

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 12:17 PM, LOKESH JANGIR wrote:

> 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
>

Possible Issue

[Me]

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: Help me for ECDHE algorithm

[chetan]

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

Re: Heart bleed with 0.9.8 and 1.0.1

[cvishnuid]

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]
> > 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.1
>> Sent from the OpenSSL - User mailing list 
>> archiveat 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 
> here
> .
> 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.

overview of server certificate mechanism with open ssl

[drkmkzs]

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 :)