Re: [openssl-dev] Known apps supporting tls max frag size extn

[Joey Yandle]

> Also, I have lost the url of a website which used to analyze any given server 
> ( eg www.yahoo.com) for its supporting various tls extensions. You provide 
> the server url and it will display all the tls extns supported by that 
> server.  If you know of any such url, could you please help me with that also.
> 

openssl s_client has an argument -tlsextdebug:

$ openssl s_client -connect www.yahoo.com:443 -tlsextdebug
CONNECTED(0003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - 
TLS server extension "EC point formats" (id=11), len=4
 - 03 00 01 02   
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1




signature.asc
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

[Joey Yandle]

May I suggest you have a look at the GOST engine?  It does implement
the algorithm entirely in the engine.  The only things added in the
OpenSSL code are the OIDs (not strictly necessary) and the TLS
ciphersuites (I don't think that can be done dynamically at all, at
least yet).


How are the OIDs not necessary?  What about the NIDs?

I've been working on an engine to add support for SIDH, using GOST as a  
template:


  https://github.com/xoloki/openssl-sidh/

GOST already had NID support in the base openssl.  I had to add at least  
one line to crypto/objects/objects.txt to get my NID:


+# NIDs for SIDH
+1 3 102 100 : SIDH : Supersingular isogeny  
Diffie–Hellman


Is there some way to add the NID dynamically?  If not, how can an  
algorithm be added?  The build system in 1.1.0 at least makes this  
relatively simple.  In 1.0.x it is far more difficult.


cheers,

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

Re: [openssl-dev] About Chinese crypto-algorithms

[Joey Yandle]

This looks like an interesting project.  I'd be willing to take a stab at
it.

I did notice the following while reading the doc:

The sm2 digital signature algorithm requires random number generators
approved by by Chinese Commercial Cryptography Administration Office.

Preliminary googling was not helpful, I may have to email the author for
clarification.

Cheers,

Joey

On Sep 27, 2016 3:32 PM, "Paul Dale"  wrote:

> There are a couple of draft standards available:
>
> SM2 DSA: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
> SM3 Hash: https://tools.ietf.org/html/draft-shen-sm3-hash-01
>
> Neither of these two looks like it would be difficult to implement.
>
> I've not located English versions of the other algorithms but I haven't
> looked too deeply.
>
>
> Pauli
>
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
> -Original Message-
> From: Salz, Rich [mailto:rs...@akamai.com]
> Sent: Wednesday, 28 September 2016 2:26 AM
> To: openssl-dev@openssl.org; robin 
> Subject: Re: [openssl-dev] About Chinese crypto-algorithms
>
> > Is there currently any documentation at all on these Chinese algorithms?
> > I'm certainly curious, and I'm sure others in the OpenSSL community will
> be.
>
> Also, please know that we are already looking at several large projects
> (TLS 1.3, FIPS, etc).  In my personal opinion, I would be surprised if
> anyone on the team had a lot of time to spend on this.  We have already
> turned down Camellia-GCM, for example.
>
> An English specification, test vectors, and a complete implementation as a
> Pull Request are the most likely ways for it to happen.  Even better would
> be to implement it as a separate ENGINE, like Gost is.  Then we only need
> to reserve a few #define's for you.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Joey Yandle]

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT"  wrote:

> This message is to the OpenSSL source code maintainers via
> r...@openssl.org:
>
> I reported this a while back and no one has seen fit to fix it.
>
> On Windows, the RAND_poll() function in the OpenSSL library uses ancient
> Heap32First and Heap32Next function calls to enumerate heap entries from
> all processes, because presumably this is considered to be a good source
> of entropy.
>
> Unfortunately, these specific methods, because of things that have been
> changed in Windows since the original design of the OpenSSL library, are
> now so tremendously inefficient that you are actually getting nearly
> zero entropy, as well as wasting a huge amount of computer time.
>
> We're measuring the time to get to the VERY FIRST check of the MAXDELAY
> operation - i.e., exactly ONE heap block has been read - as over one
> half second, and that's on a fast machine!
>
> The reason is described clearly here:
>
> https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023
>
> In short, on a Windows 7 or newer system OpenSSL is spending a full
> second before the timeout occurs gathering one or maybe a very few heap
> blocks to contribute a few bytes of entropy to the random seed.
>
> What that article says is that the Heap32First and Heap32Next are NO
> LONGER VALID FUNCTIONS on Windows to be used for the purpose of
> gathering entropy!  You're not really walking many entries at all and
> thus you are not getting the entropy you think you are.
>
> Various software packages use your library and expect it to initialize
> its own random seed effectively, which it is NOT doing.  Instead, it's
> spending a full second spinning Windows' wheels behind the scenes and
> quite possibly even disrupting other operations, for ALMOST NO BENEFIT
> in entropy gathering.  I cannot stress this enough.
>
> If you believe this should be worked-around by seeding the library
> directly, or by building an alternate copy of the library oneself,
> please bear this in mind:
>
> Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
> being initialized.
>
> Imagine, for example, that the OpenSSL library is embedded in another,
> higher-level library, and that the product using the higher-level
> library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
> with our own software.  Every startup of our software, which we expect
> to be interactive, takes MUCH longer than it should - a significant
> portion of one second - because of this bug.
>
> Also, if you think that the MAXDELAY parameter should be shortened, that
> is not valid either.  You should understand that even the first check of
> that timeout is delayed by a significant portion of a second!
>
> This needs to be fixed!
> -Noel Carboni
> ProDigital Software
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Joey Yandle via RT]

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT"  wrote:

> This message is to the OpenSSL source code maintainers via
> r...@openssl.org:
>
> I reported this a while back and no one has seen fit to fix it.
>
> On Windows, the RAND_poll() function in the OpenSSL library uses ancient
> Heap32First and Heap32Next function calls to enumerate heap entries from
> all processes, because presumably this is considered to be a good source
> of entropy.
>
> Unfortunately, these specific methods, because of things that have been
> changed in Windows since the original design of the OpenSSL library, are
> now so tremendously inefficient that you are actually getting nearly
> zero entropy, as well as wasting a huge amount of computer time.
>
> We're measuring the time to get to the VERY FIRST check of the MAXDELAY
> operation - i.e., exactly ONE heap block has been read - as over one
> half second, and that's on a fast machine!
>
> The reason is described clearly here:
>
> https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023
>
> In short, on a Windows 7 or newer system OpenSSL is spending a full
> second before the timeout occurs gathering one or maybe a very few heap
> blocks to contribute a few bytes of entropy to the random seed.
>
> What that article says is that the Heap32First and Heap32Next are NO
> LONGER VALID FUNCTIONS on Windows to be used for the purpose of
> gathering entropy!  You're not really walking many entries at all and
> thus you are not getting the entropy you think you are.
>
> Various software packages use your library and expect it to initialize
> its own random seed effectively, which it is NOT doing.  Instead, it's
> spending a full second spinning Windows' wheels behind the scenes and
> quite possibly even disrupting other operations, for ALMOST NO BENEFIT
> in entropy gathering.  I cannot stress this enough.
>
> If you believe this should be worked-around by seeding the library
> directly, or by building an alternate copy of the library oneself,
> please bear this in mind:
>
> Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
> being initialized.
>
> Imagine, for example, that the OpenSSL library is embedded in another,
> higher-level library, and that the product using the higher-level
> library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
> with our own software.  Every startup of our software, which we expect
> to be interactive, takes MUCH longer than it should - a significant
> portion of one second - because of this bug.
>
> Also, if you think that the MAXDELAY parameter should be shortened, that
> is not valid either.  You should understand that even the first check of
> that timeout is delayed by a significant portion of a second!
>
> This needs to be fixed!
> -Noel Carboni
> ProDigital Software
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr

[Joey Yandle via RT]

Looking over your logs, you appear to be configuring with no-asm, then
calling do_ms.  Does it work when you configure with asm and call do_nasm?

The do_ms target doesn't get much attention these days.
On Jun 12, 2016 5:56 AM, "Simon Richter via RT"  wrote:

> Hi,
>
> the 1.0.2 branch fails to compile in the VC-WIN32 configuration:
>
> mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr
>
> Full log available at
>
>
> http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull
>
>Simon
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr

[Joey Yandle]

Looking over your logs, you appear to be configuring with no-asm, then
calling do_ms.  Does it work when you configure with asm and call do_nasm?

The do_ms target doesn't get much attention these days.
On Jun 12, 2016 5:56 AM, "Simon Richter via RT"  wrote:

> Hi,
>
> the 1.0.2 branch fails to compile in the VC-WIN32 configuration:
>
> mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr
>
> Full log available at
>
>
> http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull
>
>Simon
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks

[Joey Yandle]

Works for me with mingw 32-bit:

ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
Test constant time utilites
../util/shlib_wrap.sh ./constant_time_test
Testing constant time operations...
ok (ran 1908 tests)
test_verify_extra
../util/shlib_wrap.sh ./verify_extra_test
PASS
test_clienthello
../util/shlib_wrap.sh ./clienthellotest
test_sslv2conftest
../util/shlib_wrap.sh ./sslv2conftest
SSLv2 CONF Test number 0
SSLv2 CONF Test number 1
SSLv2 CONF test: PASSED
make[1]: Leaving directory `/c/src/openssl-1.0.2h/test'
OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a
OpenSSL 1.0.2h-fips  3 May 2016
built on: reproducible build, date unspecified
platform: mingw
options:  bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) 
blowfish(idx)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_MT -DDSO_WIN32 
-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 
-Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL
_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM

 -DGHASH_ASM
OPENSSLDIR: "/usr/local/ssl"


On 6/1/2016 3:18 PM, Sergio NNX wrote:

How did you configure/build? What versions of mingw/msys did you use?


./configure mingw --prefix=/mingw
make depend
make all
make test

MSYS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 unknown; targ=MINGW32
GCC 6.1.0 32-bit

Memory leaks didn't occur with previous OpenSSL versions using the same
environment.
I'm trying OpenSSL from master now but facing issues with Perl at the
moment. Grrr.

Can you try building it using MinGW/MSYS 32-bit?

Thanks for looking at it.

Cheers.

Ser.




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

Re: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks

[Joey Yandle]

I tried to reproduce this last night, on the following platforms:

linux x86_64 fips
windows win64a fips
windows mingw64 fips

make test succeeded with no errors on the first two platforms.  For 
windows/mingw64, though, I did get a different error:


test SSL protocol
test ssl3 is forbidden in FIPS mode
180668:error:2D07808C:FIPS routines:FIPS_module_mode_set:unsupported 
platform:fips.c:322:

ssl2 disabled: skipping test
test tls1
181056:error:2D07808C:FIPS routines:FIPS_module_mode_set:unsupported 
platform:fips.c:322:

make[1]: *** [test_ssl] Error 1
make[1]: Leaving directory `/c/src/openssl-1.0.2h/test'
make: *** [tests] Error 2

However, if I do make -k test, then I finish without the memory leaks 
you saw:


ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
Test constant time utilites
../util/shlib_wrap.sh ./constant_time_test
Testing constant time operations...
ok (ran 1908 tests)
test_verify_extra
../util/shlib_wrap.sh ./verify_extra_test
PASS
test_clienthello
../util/shlib_wrap.sh ./clienthellotest
test_sslv2conftest
../util/shlib_wrap.sh ./sslv2conftest
SSLv2 CONF Test number 0
SSLv2 CONF Test number 1
SSLv2 CONF test: PASSED

How did you configure/build?  What versions of mingw/msys did you use?

cheers,

Joey

On 05/31/2016 08:37 PM, Sergio NNX wrote:

Ciao.

Just built OpenSSL 1.0.2h from source and when running the tests I can
see some memory leaks.
The same did not happen when building previous versions on the same
environment and same command line options.

Thanks in advance.

Find below the last bit of a long long long test output:

...
...
...
ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
Test constant time utilites
../util/shlib_wrap.sh ./constant_time_test
Testing constant time operations...
ok (ran 1908 tests)
test_verify_extra
../util/shlib_wrap.sh ./verify_extra_test
PASS
test_clienthello
../util/shlib_wrap.sh ./clienthellotest
[04:21:51]   221 file=buf_str.c, line=92, thread=1772, number=16,
address=00867FC8
[04:21:51]   426 file=eng_lib.c, line=168, thread=1772, number=4,
address=00869648
[04:21:51]   455 file=stack.c, line=162, thread=1772, number=20,
address=0086ADE8
[04:21:51]   418 file=lhash.c, line=122, thread=1772, number=64,
address=00869588
[04:21:51]   222 file=buf_str.c, line=92, thread=1772, number=7,
address=00BBFDC8
[04:21:51]   419 file=eng_lib.c, line=168, thread=1772, number=4,
address=008695D0
[04:21:51]   411 file=lhash.c, line=122, thread=1772, number=64,
address=008694C8
[04:21:51]   428 file=stack.c, line=162, thread=1772, number=20,
address=0086ACC8
[04:21:51]   412 file=eng_lib.c, line=168, thread=1772, number=4,
address=00869510
[04:21:51]   266 file=stack.c, line=162, thread=1772, number=20,
address=0086AC68
[04:21:51]72 file=eng_lib.c, line=69, thread=1772, number=112,
address=00BBFD50
[04:21:51]   251 file=stack.c, line=162, thread=1772, number=20,
address=0086AC08
[04:21:51]   236 file=stack.c, line=162, thread=1772, number=20,
address=0086ABA8
[04:21:51]   233 file=lhash.c, line=122, thread=1772, number=64,
address=0086AB48
[04:21:51]   234 file=eng_lib.c, line=168, thread=1772, number=4,
address=00BB27F0
[04:21:51]   255 file=lhash.c, line=122, thread=1772, number=64,
address=0086C0A8
[04:21:51]   256 file=eng_lib.c, line=168, thread=1772, number=4,
address=0086C0F0
[04:21:51]   429 file=stack.c, line=164, thread=1772, number=32,
address=00871E98
[04:21:51]   456 file=stack.c, line=164, thread=1772, number=16,
address=0086E860
[04:21:51]   261 file=eng_table.c, line=150, thread=1772, number=16,
address=00868520
[04:21:51]   417 file=lhash.c, line=120, thread=1772, number=96,
address=00869520
[04:21:51]   421 file=stack.c, line=162, thread=1772, number=20,
address=0086ACA8
[04:21:51]   260 file=lhash.c, line=191, thread=1772, number=12,
address=008684F0
[04:21:51]   224 file=buf_str.c, line=92, thread=1772, number=18,
address=0086A8C0
[04:21:51]   223 file=ameth_lib.c, line=289, thread=1772, number=108,
address=0086A848
[04:21:51]   259 file=stack.c, line=164, thread=1772, number=16,
address=008684C0
[04:21:51]   262 file=stack.c, line=162, thread=1772, number=20,
address=0086AC48
[04:21:51]   431 file=lhash.c, line=120, thread=1772, number=96,
address=00871D78
[04:21:51]   253 file=lhash.c, line=191, thread=1772, number=12,
address=00868418
[04:21:51]   247 file=stack.c, line=162, thread=1772, number=20,
address=0086ABE8
[04:21:51]   133 file=eng_lib.c, line=69, thread=1772, number=112,
address=008693E8
[04:21:51]   252 file=stack.c, line=164, thread=1772, number=16,
address=008683E8
[04:21:51]   410 file=lhash.c, line=120, thread=1772, number=96,
address=00869460
[04:21:51]   220 file=ameth_lib.c, line=289, thread=1772, number=108,
address=0086A7D0
[04:21:51]   219 file=eng_lib.c, line=69, thread=1772, number=112,
address=0086A758
[04:21:51]   425 file=lhash.c, line=122, thread=1772, number=64,

Re: [openssl-dev] [openssl.org #2485] Heap walking in RAND_poll causes deadlock in process on Windows Server 2008 R2 (x64) that uses libCurl, OpenSSL and ADO

[Joey Yandle]

Thanks @mattcaswell for the review.

Can I get another team member to look at pr-1079?


On 5/16/2016 12:04 PM, Matt Caswell via RT wrote:

Closing this ticket in favour of:
https://github.com/openssl/openssl/pull/1079


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

Re: [openssl-dev] How to contribute patches has changed

[Joey Yandle]

If it's a feature, wait until after 1.1 and then rebase.  If it's a bug or doc 
fix or similar, please update now and ping.



It's the windows RNG fix/cleanup.  Just updated and now no conflicts on PR.

  https://github.com/openssl/openssl/pull/512

Thanks!

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

Re: [openssl-dev] How to contribute patches has changed

[Joey Yandle]

The summary could be phrase as “just open a GitHub PR, no need to deal
with RT”


I haven't been keeping my PR #512 up to date since the 1.1 code freeze, 
is now a good time to start again?


cheers,

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

Re: [openssl-dev] Packager material in our source...

[Joey Yandle]

Though I don't use RedHat or it's derivatives, it's packaging file is at 
least mercifully self-contained.  Also, spec files can be used to 
generate packaging files for other formats.


I'd advocate for leaving it in... just not very forcefully.

On 5/11/2016 12:09 AM, Richard Levitte wrote:

Hi,

I've been wondering, why do we have an openssl.spec in the OpenSSL
source?  Why would we have packager material in there at all, and if
we should have such things, why only for RPMs, why not Debian, why not
stuff to build Windows .msis, why not stuff to build PCSI files (for
VMS)?

This is to say, I'm going to make a move to remove openssl.spec from
our source, and thought a fair warning was waranted.

Cheers,
Richard


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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

> In the makefile created by Perl, the linker binary name is assigned to a 
> variable named LINK. This variable $(LINK) is called to execute the linker 
> call.
> This causes a serious collision with the MS Visual Studio build system which 
> also relies on a variable named LINK:

Are you invoking msbuild.exe to build openssl?  The supported build 
instructions use nmake.exe directly on the generated makefiles.

What is your build invocation?

cheers,

Joey


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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle]

In the makefile created by Perl, the linker binary name is assigned to a 
variable named LINK. This variable $(LINK) is called to execute the linker call.
This causes a serious collision with the MS Visual Studio build system which 
also relies on a variable named LINK:


Are you invoking msbuild.exe to build openssl?  The supported build 
instructions use nmake.exe directly on the generated makefiles.


What is your build invocation?

cheers,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle]

Anyone interested in looking at this and porting it to master?


https://github.com/openssl/openssl/pull/620

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

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

https://github.com/openssl/openssl/pull/620


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

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle]

Anyone interested in looking at this and porting it to master?


Looks pretty easy, I'll do it.

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

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

Looks pretty easy, I'll do it.


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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

I verified the problem on both 1.0.2f and master:

set LINK=/DEBUG
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\nt.make

 link /nologo /subsystem:console /opt:ref /debug 
/out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'


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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle]

I verified the problem on both 1.0.2f and master:

set LINK=/DEBUG
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\nt.make

link /nologo /subsystem:console /opt:ref /debug 
/out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp

LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'


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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle]

And verify attached diff and report back.


The diff works perfectly on master, but exposed a new bug (bare 
snprintf).  The following patch fixes it.  I can make a PR (or add it to 
my existing PR #512) if you'd like.


diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,

 if (BIO_do_accept(acpt) <= 0)
 goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));


 client = BIO_new_connect(addr_str);
 BIO_set_conn_ip_family(client, family);

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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

> And verify attached diff and report back.

The diff works perfectly on master, but exposed a new bug (bare 
snprintf).  The following patch fixes it.  I can make a PR (or add it to 
my existing PR #512) if you'd like.

diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,
  if (BIO_do_accept(acpt) <= 0)
  goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));

  client = BIO_new_connect(addr_str);
  BIO_set_conn_ip_family(client, family);


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

Re: [openssl-dev] Configure --prefix and --openssldir

[Joey Yandle]

--prefix unset, --openssldir set to "bar" (relative path)
 => INSTALLTOP=bar , OPENSSLDIR=bar/bar



This one was sufficiently opaque that I stopped using --openssldir and 
started just using --prefix.  For a multi-level relative path, this 
gives very strange results...

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

Re: [openssl-dev] Building Open

[Joey Yandle]

I believe that I've found some issues while to build OpenSSL v1.0.2b for
64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015.


It appears that you skipped a step that was listed in INSTALL.W64, 
specifically


  perl Configure VC-WIN64A

1.0.2* builds normally for me on amd64 if that step is not skipped.

You are correct that 64-bit binaries are improperly labeled with '32'. 
I do plan on fixing that at some point, though in the meantime it makes 
my life easier (my scripts can always assume the same library name).


cheers,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Improving OpenSSL default RNG

[Joey Yandle]

- the non-CryptGenRandom() code on Windows is just crazy. Do we even support
   Windows versions before XP?


Some of that code really needs to go away, specifically the heap walk 
code.  It is extremely unsafe, and crashes ~66% of the time when running 
under the Visual Studio debugger.  There's nothing OpenSSL can do about 
the crashes, because they occur deep in ntdll code.


It used to be possible to avoid calling RAND_poll on windows, via 
RAND_screen etc (at least that's what Mr Google thinks).  But 
RAND_screen now *calls* RAND_poll.  And ssleay_get_rand_bytes has a 
weird static local variable that guarantees calling RAND_poll at least 
once even if you preseed the RNG via RAND_add.


I removed the heap walk and all the other insane kernel loading code 
from my local tree, and just do the CryptGenRandom and the mixins at the 
end (pid, etc).  I'd strongly suggest doing something similar in the 
future.


cheers,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl Poodle Vulnerability Clarification

[Joey Yandle]

The config script takes no-ssl2 and no-ssl3 args:

./config no-ssl2 no-ssl3 ...


On 06/24/2015 11:57 AM, Kannan Narayanasamy -X (kannanar - HCL 
TECHNOLOGIES LIMITED at Cisco) wrote:

Hi Kurt,

Thanks for the details. Syslog process is based on Java and disabling SSLv3 is 
not possible with that. We have tried to compile openssl with SSLv3 disabled 
but it didn't help. Can you share the steps if you have to disable via openssl 
compilation.

Thanks,
Kannan Narayanasamy.


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Kurt 
Roeckx
Sent: Friday, June 12, 2015 3:37 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Openssl Poodle Vulnerability Clarification

On Thu, Jun 11, 2015 at 09:43:24PM +, Kannan Narayanasamy -X (kannanar - 
HCL TECHNOLOGIES LIMITED at Cisco) wrote:

Hi All,

To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our 
application we have using openSSL through Apache. We have disabled using the 
below lines.

SSLProtocol all -SSLv2 -SSLv3

We are using 443 as SSL port. The command openssl s_client -connect 
IPAddress:443 -ssl3 shows the handshake failure message for 443 port. But for 
the ports  and  is connecting using SSLv3. The scanner as well report the 
high severity risk for those ports. In our application we are using those ports for 
syslog related tasks. If we change the port some other, then the scanner shows the 
new port in the list.

How to disable the SSLv3 connection for those ports as well since may customers 
are waiting for the fix. Your suggestion is much appreciated.


There are 2 solutions:
- Change the configuration of syslog to disable SSLv3.  Not sure
   it can actually be configured.
- Build your openssl with SSLv3 disabled.


Kurt

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


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

Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

[Joey Yandle]

I was kind of surprised to learn this... The SSL library on Windows
does not export SSL_CTX_set_options or SSL_set_options.


That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \

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

Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

[Joey Yandle via RT]

 I was kind of surprised to learn this... The SSL library on Windows
 does not export SSL_CTX_set_options or SSL_set_options.

That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \


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

Re: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7

[Joey Yandle]

tmp32\aesni-sha256-x86_64.asm:113: error: symbol
`__imp_RtlVirtualUnwind' undefined


Can you confirm that attached patch addresses the problem?


Yes, that fixes it.  However, the build then fails during linking:

lib /nologo /out:out32\libeay32.lib @C:\Users\dragon\AppData\Local\Temp\
nm60AD.tmp
tmp32\x86_64cpuid.obj : fatal error LNK1112: module machine type 'x64' 
conflicts

 with target machine type 'X86'

I was able to build 64-bit no-asm binaries, so I'm not sure what's 
causing the problem here.



On side note
the error is indication that your nasm is out-of-date and you are
missing out some optimizations.


I'm using the nasm-2.07 windows installer from sourceforge:

http://sourceforge.net/projects/nasm/

Is there something more recent?

thanks,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

[Joey Yandle via RT]

 Tardy is referenced in the openssl Makefile tar rule, which is there
 the dependency manifests.

 Surely you build your packages from the release tar balls? That means
 that this rule is never used.


Many package managers (including debian's, depending on the mode in 
which it is run) will unpack a tarball, run 'make dist' on it, and then 
build the resulting tarball.  In those cases, tardy is properly a build 
dependency.


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

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

[Joey Yandle]

Tardy is referenced in the openssl Makefile tar rule, which is there
the dependency manifests.

Surely you build your packages from the release tar balls? That means
that this rule is never used.



Many package managers (including debian's, depending on the mode in 
which it is run) will unpack a tarball, run 'make dist' on it, and then 
build the resulting tarball.  In those cases, tardy is properly a build 
dependency.


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

[openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7

[Joey Yandle]

Hello,

I'm trying to build openssl-1.0.2 for windows.  I successfully built 
win32 binaries, but I can't seem to build win64a.  I get reasonably far 
into the build, but then it fails doing AES nasm calls.  Previous nasm 
calls succeed.


perl Configure VC-WIN64A --prefix=Output\Win64\Release

ms\do_win64a

nmake -f ms\nt.mak

...

nasm -f win64 -DNEAR -Ox -g -o tmp32\aesni-sha256-x86_64.obj 
tmp32\aesni-sha256-x86_64.asm
tmp32\aesni-sha256-x86_64.asm:113: error: symbol 
`__imp_RtlVirtualUnwind' undefined
tmp32\aesni-sha256-x86_64.asm:130: error: symbol 
`L$SEH_begin_aesni_cbc_sha256_enc_xop' undefined
tmp32\aesni-sha256-x86_64.asm:131: error: symbol 
`L$SEH_end_aesni_cbc_sha256_enc_xop' undefined
tmp32\aesni-sha256-x86_64.asm:132: error: symbol 
`L$SEH_info_aesni_cbc_sha256_enc_xop' undefined
tmp32\aesni-sha256-x86_64.asm:134: error: symbol 
`L$SEH_begin_aesni_cbc_sha256_enc_avx' undefined
tmp32\aesni-sha256-x86_64.asm:135: error: symbol 
`L$SEH_end_aesni_cbc_sha256_enc_avx' undefined
tmp32\aesni-sha256-x86_64.asm:136: error: symbol 
`L$SEH_info_aesni_cbc_sha256_enc_avx' undefined
NMAKE : fatal error U1077: 'C:\Program Files (x86)\NASM\nasm.EXE' : 
return code '0x1'


Any ideas?

thanks,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7

[Joey Yandle]

I'm trying to build openssl-1.0.2 for windows.  I successfully built
win32 binaries, but I can't seem to build win64a.  I get reasonably far
into the build, but then it fails doing AES nasm calls.  Previous nasm
calls succeed.



FWIW, I was able to work around this by disabling asm entirely:

perl Configure VC-WIN64A no-asm --prefix=Output\Win64\Release

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