[openssl-dev] OpenSSL_1_0_2-stable Windows build

[John Foley]

Is anyone seeing the following error when building 1.0.2 stable on Windows:

  Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest 
out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1
cl /Fotmp32dll\dtlstest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 
-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m 
-IC:\Users\testuser\workspace\CiscoSSL\ciscossl-platform-tests-win32\fips/include
 -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. 
-DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 
-DOPENSSL_NO_BASE_EC -DOPENSSL_NO_BASE_ECDSA -DOPENSSL_NO_BASE_ECDH 
-DOPENSSL_NO_GOST -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c 
.\ssl\dtlstest.c
dtlstest.c
link /nologo /subsystem:console /opt:ref /debug 
/out:out32dll\dtlstest.exe @C:\Users\testuser\AppData\Local\Temp\nm6DBA.tmp
   Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair 
referenced in function _test_dtls_unprocessed
dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects 
referenced in function _test_dtls_unprocessed
dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection 
referenced in function _test_dtls_unprocessed
dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter 
referenced in function _test_dtls_unprocessed
dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject 
referenced in function _test_dtls_unprocessed
out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.


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

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[John Foley]

One of the challenges with this will be symbol collision (in a Linux 
environment).  I would think that doing this as a static engine would 
not be possible.  The reason is your new engine that's using the 2.0.11 
canister would contain symbols that exist in OpenSSL. But maybe the 
fipssyms.h trickery could be used to get past this.


Doing this as a dynamic engine may be a challenge as well.  Your dynamic 
engine, implemented as a .so, would have symbol overlap as well.  But 
these would be resolved by the loader.  Depending on whether 
libcrypto.so or your .so was loaded first by the loader, the wrong 
implementation for a symbol could be used.



On 02/22/2016 11:01 AM, Wall, Stephen wrote:

I wonder if I could get the thoughts of some of you developers on how difficult 
it would be to build an engine for OpenSSL 1.1.0 that makes use of the current 
(2.0.11?) fipscanister.o.  Also, opinions on if this would be a legitimate way 
to get FIPS in 1.1.0.

Thanks,
spw



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

[openssl-dev] 1.0.1r release not committed to git repo

[John Foley]

I just cloned the OpenSSL git repo at 
git://git.openssl.org/openssl.git.  Looking at the OpenSSL_1_0_1-stable 
branch, the fix for CVE-2015-3197 still isn't in the repo.  The most 
recent commit is:


foleyj@hobknob:~/gitsync/ossl/openssl$ git log
commit 126ac21c80967ec00f802d356462c1b83fa0f54c
Author: Richard Levitte 
Date:   Tue Jan 19 20:35:41 2016 +0100

Fix BSD -rpath parameter

For BSD systems, Configure adds a shared_ldflags including a reference
to the Makefile variable LIBRPATH, but since it must be passed down to
Makefile.shared, care must be taken so the value of LIBRPATH doesn't
get expanded too early, or it ends up giving an empty string.

Reviewed-by: Viktor Dukhovni 
(cherry picked from commit c64879d3f3cc4c7f1c436a9fe3bd109847a23629)

Did someone forgot to push the commit after generating the 1.0.1r 
release today?



||




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

Re: [openssl-dev] 1.0.1r release not committed to git repo

[John Foley]

Thank you.


On 01/28/2016 12:20 PM, Matt Caswell wrote:


On 28/01/16 16:40, John Foley wrote:

I just cloned the OpenSSL git repo at
git://git.openssl.org/openssl.git.  Looking at the OpenSSL_1_0_1-stable
branch, the fix for CVE-2015-3197 still isn't in the repo.  The most
recent commit is:

foleyj@hobknob:~/gitsync/ossl/openssl$ git log
commit 126ac21c80967ec00f802d356462c1b83fa0f54c
Author: Richard Levitte <levi...@openssl.org>
Date:   Tue Jan 19 20:35:41 2016 +0100

 Fix BSD -rpath parameter

 For BSD systems, Configure adds a shared_ldflags including a reference

 to the Makefile variable LIBRPATH, but since it must be passed down to
 Makefile.shared, care must be taken so the value of LIBRPATH doesn't
 get expanded too early, or it ends up giving an empty string.

 Reviewed-by: Viktor Dukhovni <vik...@openssl.org>

 (cherry picked from commit c64879d3f3cc4c7f1c436a9fe3bd109847a23629)

Did someone forgot to push the commit after generating the 1.0.1r
release today?

Oops. I failed to notice that the push had failed. Resolved now. Thanks.

Matt

___
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] Verification of ABI compatibility

[John Foley]

If anyone is interested, I've added a new build to the Jenkins workflow 
to verify ABI compatibility on the 1.0.2-stable branch. This job will 
run nightly and look for ABI differences between the current build and 
the build from the previous night.  If a commit goes into the branch 
that changes ABI, this job should alert the openssl-commits alias.


This results of this job can be viewed here:

https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 Release Timetable

[John Foley]

Is the "Async support" you have listed the same code that Intel
developed for Cave Creek?  Or is the Intel contribution planned for a
follow-on release?


On 09/16/2015 10:54 AM, Matt Caswell wrote:
>
>
> On 16/09/15 15:38, Alessandro Ghedini wrote:
> > On Wed, Sep 16, 2015 at 11:16:18AM +0100, Matt Caswell wrote:
> >> The OpenSSL Project team would like to announce the publication
> >> of our current plans for the OpenSSL 1.1.0 release timetable.
> >> This has been included in our release strategy available here:
> >>
> >> https://www.openssl.org/policies/releasestrat.html
>
> > Do you have any idea on what features are gonna be present in
> > 1.1.0? I seem to remember someone mentioning that ChaCha20-Poly1305
> > support was being worked on by Andy Polyakov and is planned for the
> > 1.1.0 release, is this still the case?
>
> > Same goes for Curve25519/Curve448.
>
>
> The best place to look for all the 1.1.0 changes that have taken place
> so far is the CHANGES file. This is available online here:
>
> https://www.openssl.org/news/changelog.html
>
> That only lists changes that have been committed so far. Off the top
> of my head other big changes that are coming include:
> - State machine rewrite
> - Async support
> - IPv6
>
> I've not heard anything from Andy in a while on his stuff so I'm not
> sure what the current state of play is with ChaCha/Poly. There's
> probably a ton of other stuff that I've forgotten and my colleagues
> will remind me about.
>
> Matt
>
> ___ > 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] [openssl.org #4036] Invalid use of memcpy() causing decrypt failure

[John Foley via RT]

We're seeing intermittent failures in the AES key wrap test cases in
test/evp_test in the 1.0.2d release.  We believe the problem is due to
using memcpy() with overlapping src/dst memory regions.  The following
thread provides some insight into this memcpy() issue:

https://bugzilla.redhat.com/show_bug.cgi?id=638477

The documentation for memcpy() states to use memmove() when the memory
regions overlap.  The attached patch resolves the problem.  Please
consider accepting this patch in the 1.0.2 stable and master branches.

Thank you.

diff --git a/crypto/modes/wrap128.c b/crypto/modes/wrap128.c
index 9755cac..979b640 100644
--- a/crypto/modes/wrap128.c
+++ b/crypto/modes/wrap128.c
@@ -76,7 +76,7 @@ size_t CRYPTO_128_wrap(void *key, const unsigned char *iv,
 return 0;
 A = B;
 t = 1;
-memcpy(out + 8, in, inlen);
+memmove(out + 8, in, inlen);
 if (!iv)
 iv = default_iv;
 
@@ -113,7 +113,7 @@ size_t CRYPTO_128_unwrap(void *key, const unsigned char *iv,
 A = B;
 t = 6 * (inlen >> 3);
 memcpy(A, in, 8);
-memcpy(out, in + 8, inlen);
+memmove(out, in + 8, inlen);
 for (j = 0; j < 6; j++) {
 R = out + inlen - 8;
 for (i = 0; i < inlen; i += 8, t--, R -= 8) {
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] State machine rewrite

[John Foley (foleyj)]

Here's another trivial example if that URL still isn't working for you:
johnsantic.com/comp/<http://johnsantic.com/comp/>state.html


On Sep 11, 2015, at 5:46 PM, Daniel Kahn Gillmor 
<d...@fifthhorseman.net<mailto:d...@fifthhorseman.net>> wrote:

On Fri 2015-09-11 11:07:27 -0400, John Foley wrote:

It's great to see improvements in the state machine along with
consolidated handlers for TLS/DTLS.

Agreed.  Thanks for the work on this, Matt!

Having said that, have you considered using a state transition table
instead of long switch statements to enforce the state transition
rules?  This would improve the maintainability of the code.  Here's a
trivial example:

http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/

I'm getting a 404 from this.  do you have another link?

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

Re: [openssl-dev] State machine rewrite

[John Foley]

+1

It's great to see improvements in the state machine along with
consolidated handlers for TLS/DTLS.  Having said that, have you
considered using a state transition table instead of long switch
statements to enforce the state transition rules?  This would improve
the maintainability of the code.  Here's a trivial example:

http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/



On 09/11/2015 10:34 AM, Matt Caswell wrote:
> I've just opened a github pull request to show recent work I have been
> doing on rewriting the OpenSSL state machine (for version 1.1.0). See:
> https://github.com/openssl/openssl/pull/394
>
> My objectives for the rewrite were:
>
> - Remove duplication of state code between client and server
> - Remove duplication of state code between TLS and DTLS
> - Simplify transitions and bring the logic together in a single location
> so that it is easier to validate
> - Remove duplication of code between each of the message handling functions
> - Receive a message first and then work out whether that is a valid
> transition - not the other way around (the other way causes lots of
> issues where we are expecting one type of message next but actually get
> something else)
> - Separate message flow state from handshake state (in order to better
> understand each)
>   - message flow state = when to flush buffers; handling restarts in the
> event of NBIO events; handling the common flow of steps for reading a
> message and the common flow of steps for writing a message etc
>   - handshake state = what handshake message are we working on now
> - Control complexity: only the state machine can change state: keep all
> the state changes local to the state machine component
>
> The message flow state machine is divided into a reading sub-state
> machine and a writing sub-state machine. See the source comments in
> ssl/statem/statem.c for a more detailed description of the various
> states and transitions possible. Also see ssl/statem/README for
> additional info.
>
> One issue is that the patch as it is currently removes support for
> DTLSv1_listen. I have another patch to add that back in (in a completely
> different way) - but it needs a bit more work yet.
>
> I am interested in hearing any feedback you may have on the code
> (ideally as comments in the pull request). I would also be keen to hear
> of any problems you might encounter whilst using this code. You can
> check it out from my github repo:
> https://github.com/mattcaswell/openssl
>
> See the state-machine-rewrite branch.
>
> Thanks
>
> Matt
>
>
> ___
> 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] Continuous Integration for OpenSSL

[John Foley]

If you click on one of the individual builds (left side), then click on
the Console Output link, it'll show the full build log.  You can find
the commands issued for the build in this log.


On 08/25/2015 05:49 AM, Ben Laurie wrote:


 On Mon, 24 Aug 2015 at 19:35 Matt Caswell m...@openssl.org
 mailto:m...@openssl.org wrote:

 On 24/08/2015 10:08, Ben Laurie wrote:
 
 
  On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com
  mailto:rs...@akamai.com mailto:rs...@akamai.com wrote:
 
 
   On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com
  mailto:rs...@akamai.com mailto:rs...@akamai.com wrote:
   Thanks!  We have several cross-compile builds running on
 Cisco's
  build farm.  The more the merrier.  I am sure ARM would be
 appreciated.
 
   Are these linked from the website somewhere?
 
  No.  John Foley @Cisco posted bout them, I think, and Matt has a
  login and is careful about failures.
 
 
  Seems to me they should be on the website. BTW I tracked it down:
 
  http://openssl-sanity.cisco.com:8080/
 
  However, doesn't appear to be up. :-(

 It's up; link is wrong:

 https://openssl-sanity.cisco.com:8443/


 Ah, thanks. So, should we link to this (and any other CI sites) from
 the website?

 Also, next stupid question, if I look there, I see for example:

 https://openssl-sanity.cisco.com:8443/job/1_0_1_mips/

 How do I find out how that's being built?
  



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

[openssl-dev] ECDSA side-channel attack mitigation

[John Foley]

Is OpenSSL planning to implement side-channel resistance against the
following attack:

https://eprint.iacr.org/2014/161.pdf


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

Re: [openssl-dev] Continuous Integration for OpenSSL

[John Foley]

The URL is https://openssl-sanity.cisco.com:8443/


On 08/24/2015 05:08 AM, Ben Laurie wrote:


 On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com wrote:


 On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com wrote:
 Thanks!  We have several cross-compile builds running on Cisco's
 build farm.  The more the merrier.  I am sure ARM would be
 appreciated.

 Are these linked from the website somewhere?

 No.  John Foley @Cisco posted bout them, I think, and Matt has a
 login and is careful about failures.


 Seems to me they should be on the website. BTW I tracked it down:

 http://openssl-sanity.cisco.com:8080/

 However, doesn't appear to be up. :-(

 I believe it also (at least when working) sends email on failures -
 would be nice if those went to a list...



 ___
 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] Build failure on SLES11

[John Foley]

It could be the gcc version is too old.  Trying to recall, gcc needs to
be something like 4.4 or newer to support the Intel carry-less multiply
instruction.



On 06/11/2015 09:37 AM, Dimitrios Apostolou wrote:
 Hello list,

 I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
 It fails unless I configure with no-asm. Here is the relevant output:

 gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
 -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
 -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall
 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
 -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
 -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
 ghash-x86_64.s: Assembler messages:
 ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
 $17,%xmm2,%xmm0,%xmm1'
 ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
 $0,%xmm2,%xmm0,%xmm0'
 [ ... many identical errors omitted ]


 I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
 failing. Here is relevant output that might be of help:

 $ uname -a
 Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28
 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
 $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
 GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
 Binutils; SUSE Linux Enterprise 11) 2.19


 Thanks in advance,
 Dimitris

 ___
 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] FreeBSD build broken?

[John Foley]

Is anyone having problems building 1.0.2-stable on FreeBSD?  It appears
the following commit may have broken the build:

https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc

Here's the error we're seeing:

[jenkins@freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake depend
making depend in crypto...
gmake[1]: Entering directory
'/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
../util/domd: makedepend: not found
mv: Makefile.new: No such file or directory
Makefile:136: recipe for target 'local_depend' failed
gmake[1]: *** [local_depend] Error 127
gmake[1]: Leaving directory
'/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
Makefile:466: recipe for target 'depend' failed
gmake: *** [depend] Error 1

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

Re: [openssl-dev] Question about valgrind error in DH in 1.0.2

[John Foley]

Upon further investigation, it looks like the problem is in your sample
code.  You need to invoke CRYPTO_cleanup_all_ex_data() before
terminating your program.


On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote:
 Hi.  I have an application that generates Diffie-Hellman key pairs based
 on some precomputed primes.

 In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives
 valgrind errors (while still working).

 The error only occurs on x86_64, and it does not occur on 1024 bit DH.

 I've attached the source code of the small application.  All it does is
 generate a DH key pair using fixed primes.  I'm not really sure where
 the primes come from, but this is used for H.235 (video conferencing
 call setup), and I think the primes are standardized.

 Output here:

 Using the native openssl on the box (1.0.1e):
 $ gcc -o dh-1.0.1 dh.c -lcrypto
 $ valgrind ./dh-1.0.1
 ==4730== Memcheck, a memory error detector
 ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
 ==4730== Command: ./dh-1.0.1
 ==4730== 
 ==4730== 
 ==4730== HEAP SUMMARY:
 ==4730== in use at exit: 416 bytes in 6 blocks
 ==4730==   total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated
 ==4730== 
 ==4730== LEAK SUMMARY:
 ==4730==definitely lost: 0 bytes in 0 blocks
 ==4730==indirectly lost: 0 bytes in 0 blocks
 ==4730==  possibly lost: 0 bytes in 0 blocks
 ==4730==still reachable: 416 bytes in 6 blocks
 ==4730== suppressed: 0 bytes in 0 blocks
 ==4730== Rerun with --leak-check=full to see details of leaked memory
 ==4730== 
 ==4730== For counts of detected and suppressed errors, rerun with: -v
 ==4730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

 I've also built myself a 1.0.2 build, using './config -DPURIFY shared'
 (purify to remove other valgrind warnings that would come when reading
 uninitialized data).

 $ gcc -o dh-1.0.2 -L~/src/thirdparty/openssl -isystem
 ~/src/thirdparty/openssl/include dh.c -lcrypto
 $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 
 ==14854== Memcheck, a memory error detector
 ==14854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==14854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
 ==14854== Command: ./dh-1.0.2
 ==14854== 
 ==14854== Invalid read of size 2
 ==14854== at 0x4F09198: bn_get_bits5 (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854== by 0x4F32B47: generate_key (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2)
 ==14854==  Address 0x581d77f is 255 bytes inside a block of size 256 alloc'd
 ==14854==at 0x4C29BFD: malloc (in 
 /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 ==14854== by 0x4E9DF62: CRYPTO_malloc (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854== by 0x4EFCAA7: bn_expand_internal (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854== by 0x4EFCFA4: bn_expand2 (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854==by 0x4EFD39F: BN_bin2bn (in 
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854==by 0x4F010FA: BN_rand (in 
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854== by 0x4F32B0E: generate_key (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2)
 ==14854== 
 ==14854== 
 ==14854== HEAP SUMMARY:
 ==14854== in use at exit: 416 bytes in 6 blocks
 ==14854==   total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated
 ==14854== 
 ==14854== LEAK SUMMARY:
 ==14854==definitely lost: 0 bytes in 0 blocks
 ==14854==indirectly lost: 0 bytes in 0 blocks
 ==14854==  possibly lost: 0 bytes in 0 blocks
 ==14854==still reachable: 416 bytes in 6 blocks
 ==14854== suppressed: 0 bytes in 0 blocks
 ==14854== Rerun with --leak-check=full to see details of leaked memory
 ==14854== 
 ==14854== For counts of detected and suppressed errors, rerun with: -v
 ==14854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

 Then, same openssl version but with 1024 bit DH:
 $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 1024
 ==14730== Memcheck, a memory error detector
 ==14730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==14730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
 ==14730== Command: ./dh-1.0.2 1024
 ==14730== 
 ==14730== 
 ==14730== HEAP SUMMARY:
 ==14730== in use at exit: 416 bytes in 6 blocks
 ==14730==   total heap usage: 112 allocs, 106 frees, 14,472 bytes allocated
 ==14730== 
 ==14730== LEAK SUMMARY:
 ==14730==definitely lost: 0 bytes in 0 blocks
 ==14730==indirectly lost: 0 bytes in 0 blocks
 ==14730==  possibly lost: 0 bytes in 0 blocks
 ==14730==still reachable: 416 bytes 

Re: [openssl-dev] Question about valgrind error in DH in 1.0.2

[John Foley]

If you add the --show-reachable option to valgrind, you can see where
the leaks originate.  They appear to be in the ex_data code (see
below).  As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f
as well as 1.0.2a.

==18173== HEAP SUMMARY:
==18173== in use at exit: 416 bytes in 6 blocks
==18173==   total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated
==18173==
==18173== 24 bytes in 1 blocks are still reachable in loss record 1 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x40AFCB: def_get_class (ex_data.c:321)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== 24 bytes in 1 blocks are still reachable in loss record 2 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x425063: lh_insert (lhash.c:191)
==18173==by 0x40AFF9: def_get_class (ex_data.c:333)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== 32 bytes in 1 blocks are still reachable in loss record 3 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x42434B: sk_new_null (stack.c:162)
==18173==by 0x40AFE1: def_get_class (ex_data.c:325)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== 32 bytes in 1 blocks are still reachable in loss record 4 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x424367: sk_new_null (stack.c:164)
==18173==by 0x40AFE1: def_get_class (ex_data.c:325)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== 128 bytes in 1 blocks are still reachable in loss record 5 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x424C5D: lh_new (lhash.c:122)
==18173==by 0x40B054: def_get_class (ex_data.c:279)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== 176 bytes in 1 blocks are still reachable in loss record 6 of 6
==18173==at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18173==by 0x4092E7: CRYPTO_malloc (mem.c:342)
==18173==by 0x424C3D: lh_new (lhash.c:120)
==18173==by 0x40B054: def_get_class (ex_data.c:279)
==18173==by 0x40B21A: int_new_ex_data (ex_data.c:421)
==18173==by 0x404D11: DH_new (dh_lib.c:169)
==18173==by 0x401B66: main (dhh.c:63)
==18173==
==18173== LEAK SUMMARY:
==18173==definitely lost: 0 bytes in 0 blocks
==18173==indirectly lost: 0 bytes in 0 blocks
==18173==  possibly lost: 0 bytes in 0 blocks
==18173==still reachable: 416 bytes in 6 blocks
==18173== suppressed: 0 bytes in 0 blocks


On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote:
 Hi.  I have an application that generates Diffie-Hellman key pairs based
 on some precomputed primes.

 In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives
 valgrind errors (while still working).

 The error only occurs on x86_64, and it does not occur on 1024 bit DH.

 I've attached the source code of the small application.  All it does is
 generate a DH key pair using fixed primes.  I'm not really sure where
 the primes come from, but this is used for H.235 (video conferencing
 call setup), and I think the primes are standardized.

 Output here:

 Using the native openssl on the box (1.0.1e):
 $ gcc -o dh-1.0.1 dh.c -lcrypto
 $ valgrind ./dh-1.0.1
 ==4730== Memcheck, a memory error detector
 ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
 ==4730== Command: ./dh-1.0.1
 ==4730== 
 ==4730== 
 ==4730== HEAP SUMMARY:
 ==4730== in use at exit: 416 bytes in 6 blocks
 ==4730==   total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated
 ==4730== 
 ==4730== LEAK SUMMARY:
 ==4730==definitely lost: 0 bytes in 0 blocks
 ==4730==indirectly lost: 0 bytes in 0 blocks
 ==4730==  possibly lost: 0 bytes in 0 blocks
 ==4730==still reachable: 416 bytes in 6 blocks
 ==4730== suppressed: 0 bytes in 0 blocks
 ==4730== Rerun with --leak-check=full to see details of leaked memory
 ==4730== 
 

Re: [openssl-dev] Question about valgrind error in DH in 1.0.2

[John Foley]

Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
error.  But this isn't a valid fix since bn_get_bits5 no longer returns
the correct data.  My assembly skills are near nil.  Maybe someone else
can propose a valid fix. 

Having said this, this does show the problem appears to be due to the
movzwl reading past the end of the buffer by a byte.  Given the data
allocated on the heap is likely surrounded by guard bytes, this is
likely a benign read outside the buffer.  But it should still be fixed.



On 05/13/2015 10:46 AM, John Foley wrote:
 Sorry for misinterpreting your question, my mistake.  I was able to
 replicate the error. It looks like the invalid read is in code that's
 compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the
 X86_64 target.  Looking at the diff of x86_64-mont5.pl between 1.0.1 and
 1.0.2, there are quite a few changes.  My guess is this was introduced
 in ec9cc70f72454b8d4a84247c86159613cee83b81.




 On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote:
 John Foley fol...@cisco.com writes:

 If you add the --show-reachable option to valgrind, you can see where
 the leaks originate.  They appear to be in the ex_data code (see
 below).  As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f
 as well as 1.0.2a.
 Ah, I forgot to mention.  I'm not concerned about the leak, but the
 invalid read that's in 1.0.2 only.

 This one:

 ==14854== Invalid read of size 2
 ==14854== at 0x4F09198: bn_get_bits5 (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854== by 0x4F32B47: generate_key (in
 /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0)
 ==14854==by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2)

 ___
 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] Seg fault during make test

[John Foley]

Is anyone seeing a segmentation fault during the test_verify phase of
make test on 32-bit systems?  I haven't done a full triage yet.  But it
appears to have been introduced by
5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.  The problem no longer occurs
when backing out this commit.  This could be a faulty commit since the
sizeof invocations in this commit would return different values for
32/64 bit systems.



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

Re: [openssl-dev] Seg fault during make test

[John Foley]

I think you're wrong about sizeof and pointers.  It'll return 4 or 8
depending if it's a 32 or 64 bit system.  Try the following code:

#include stdio.h

typedef struct _s1 {
int x;
int y;
int z;
} S1;

typedef struct _s2 {
double d1;
double d2;
double d3;
double d4;
int x1;
int x2;
} S2;

int main (int argc, char *argv[]) {
S1 *first;
S2 *second;

printf(%d %d\n, sizeof(first), sizeof(second));
}


You're right about the memset, good catch.  So it appears there are two
issues with this commit.



On 05/04/2015 09:35 AM, Stephan Mühlstrasser wrote:
 Am 04.05.15 um 14:51 schrieb John Foley:
 Is anyone seeing a segmentation fault during the test_verify phase of
 make test on 32-bit systems?  I haven't done a full triage yet.  But it
 appears to have been introduced by
 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.  The problem no longer occurs
 when backing out this commit.  This could be a faulty commit since the
 sizeof invocations in this commit would return different values for
 32/64 bit systems.

 The sizeof invocations do not return the pointer sizes, but the size
 of the structures pointed to.

 The problem is that there's apparently a copypaste error:

 https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa


 172 memset(param, 0, sizeof *paramid);
 173 memset(paramid, 0, sizeof *paramid);

 The first memset should be fixed to use *param instead of *paramid:

 memset(param, 0, sizeof *param);

 Regards
 Stephan
 ___
 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] Seg fault during make test

[John Foley]

My bad, I overlooked the dereference operator.  Thanks for correcting me.


On 05/04/2015 10:36 AM, Stephan Mühlstrasser wrote:
 Am 04.05.15 um 16:19 schrieb John Foley:
 I think you're wrong about sizeof and pointers.  It'll return 4 or 8
 depending if it's a 32 or 64 bit system.  Try the following code:

 #include stdio.h

 typedef struct _s1 {
  int x;
  int y;
  int z;
 } S1;

 typedef struct _s2 {
  double d1;
  double d2;
  double d3;
  double d4;
  int x1;
  int x2;
 } S2;

 int main (int argc, char *argv[]) {
  S1 *first;
  S2 *second;

  printf(%d %d\n, sizeof(first), sizeof(second));
 }

 Yes, but that is different from what is relevant in the commit
 53ba0a9e91ad203de2943edaf1090ab17ec435fa.

 You're right that in your test program you will get always different
 output on 32-bit and 64-bit systems because the pointer size is
 different.

 But the code in the OpenSSL uses sizeof(*pointer) and not
 sizeof(pointer). sizeof(*pointer) gets the size of the structure
 to which pointer points.

 So try the following in your test program

 printf(%d %d\n, sizeof(*first), sizeof(*second));

 This might return different output on 32-bit and 64-bit systems, but
 it might also return the same output, depending on the size of the
 basic types and the padding in the structures.

 You're right about the memset, good catch.  So it appears there are two
 issues with this commit.



 On 05/04/2015 09:35 AM, Stephan Mühlstrasser wrote:
 Am 04.05.15 um 14:51 schrieb John Foley:
 Is anyone seeing a segmentation fault during the test_verify phase of
 make test on 32-bit systems?  I haven't done a full triage yet. 
 But it
 appears to have been introduced by
 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.  The problem no longer
 occurs
 when backing out this commit.  This could be a faulty commit since the
 sizeof invocations in this commit would return different values for
 32/64 bit systems.

 The sizeof invocations do not return the pointer sizes, but the size
 of the structures pointed to.

 The problem is that there's apparently a copypaste error:

 https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa



 172 memset(param, 0, sizeof *paramid);
 173 memset(paramid, 0, sizeof *paramid);

 The first memset should be fixed to use *param instead of *paramid:

 memset(param, 0, sizeof *param);

 Regards
 Stephan
 ___
 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
 .


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

[openssl-dev] [openssl.org #3826] Contribution/Patch

[John Foley via RT]

This may be considered a bug.  When doing a FIPS build of OpenSSL
1.0.2a, some ciphers leverage the FIPS flavor of the cipher even when
FIPS mode is disabled.  This impacts performance since the FIPS ciphers
incur additional overhead.  The attached patch changes this behavior to
only invoke the FIPS flavor of a cipher when FIPS mode is enabled. 



From 21abfef3f82621f89073a19e797ae105537cd68c Mon Sep 17 00:00:00 2001
From: jfigus fol...@cisco.com
Date: Wed, 15 Apr 2015 14:09:56 -0400
Subject: [PATCH] CSCut84778 - Disable use of FIPS digest and FIPS_cipher()
 when FIPS mode is disable.  Some unit tests binaries don't use fipsld, in
 which case the POST doesn't run and FIPS is not allowed.

---
 crypto/evp/digest.c  | 35 ---
 crypto/evp/evp_enc.c | 10 +++---
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/crypto/evp/digest.c b/crypto/evp/digest.c
index f2643f3..f83eade 100644
--- a/crypto/evp/digest.c
+++ b/crypto/evp/digest.c
@@ -251,10 +251,11 @@ int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
 int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
 {
 #ifdef OPENSSL_FIPS
-return FIPS_digestupdate(ctx, data, count);
-#else
-return ctx-update(ctx, data, count);
+if (FIPS_mode()) {
+return FIPS_digestupdate(ctx, data, count);
+} else
 #endif
+return ctx-update(ctx, data, count);
 }
 
 /* The caller can assume that this removes any secret data from the context */
@@ -270,20 +271,24 @@ int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md, unsigned int *size)
 int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md, unsigned int *size)
 {
 #ifdef OPENSSL_FIPS
-return FIPS_digestfinal(ctx, md, size);
-#else
-int ret;
+if (FIPS_mode()) {
+	return FIPS_digestfinal(ctx, md, size);
+} else {
+#endif
+	int ret;
 
-OPENSSL_assert(ctx-digest-md_size = EVP_MAX_MD_SIZE);
-ret = ctx-digest-final(ctx, md);
-if (size != NULL)
-*size = ctx-digest-md_size;
-if (ctx-digest-cleanup) {
-ctx-digest-cleanup(ctx);
-EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_CLEANED);
+	OPENSSL_assert(ctx-digest-md_size = EVP_MAX_MD_SIZE);
+	ret = ctx-digest-final(ctx, md);
+	if (size != NULL)
+	*size = ctx-digest-md_size;
+	if (ctx-digest-cleanup) {
+	ctx-digest-cleanup(ctx);
+	EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_CLEANED);
+	}
+	memset(ctx-md_data, 0, ctx-digest-ctx_size);
+	return ret;
+#ifdef OPENSSL_FIPS
 }
-memset(ctx-md_data, 0, ctx-digest-ctx_size);
-return ret;
 #endif
 }
 
diff --git a/crypto/evp/evp_enc.c b/crypto/evp/evp_enc.c
index 65f0e02..270cfcf 100644
--- a/crypto/evp/evp_enc.c
+++ b/crypto/evp/evp_enc.c
@@ -69,11 +69,15 @@
 #endif
 #include evp_locl.h
 
+static int M_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, unsigned int inl)
+{
 #ifdef OPENSSL_FIPS
-# define M_do_cipher(ctx, out, in, inl) FIPS_cipher(ctx, out, in, inl)
-#else
-# define M_do_cipher(ctx, out, in, inl) ctx-cipher-do_cipher(ctx, out, in, inl)
+if (FIPS_mode()) { 
+return FIPS_cipher(ctx, out, in, inl); 
+} else 
 #endif
+return ctx-cipher-do_cipher(ctx, out, in, inl); 
+}
 
 const char EVP_version[] = EVP OPENSSL_VERSION_PTEXT;
 
-- 
2.1.2.dirty

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

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[John Foley]

Someone that understands EAP better than myself should probably provide 
input.  But my limited understand of EAP-FAST is it contributes to the 
master secret calculation used for the TLS session.  See section RFC 
4851 Section 5.1. My understanding is this logic applies to both new and 
resumed sessions.  Hence, tls_session_secret_cb() is always in play for 
EAP-FAST.



On 03/26/2015 02:13 PM, Emilia Käsper wrote:



On Tue, Mar 24, 2015 at 2:01 PM, John Foley fol...@cisco.com 
mailto:fol...@cisco.com wrote:


Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle
a failure in the session secret callback, the legacy logic would
likely result in a bad record mac error because the master
secrets on the client/server do not match.


But only in case we are actually resuming - no? Does the client always 
have a PAC available - I would guess not? Seems the legacy logic is 
such that it happens to work, but I'd like to clear it up.


  It would be good to trigger an internal error to aid with
troubleshooting.  Maybe something like:

SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
goto err;

It's debatable whether the alert needs to be sent to the server. 
Since this is an internal error, it should be safe to send the

alert.  Therefore, maybe you would actually want to do something like:

SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
al = SSL_AD_INTERNAL_ERROR;
goto f_err;




On 03/23/2015 09:17 PM, Emilia Käsper wrote:



On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj)
fol...@cisco.com mailto:fol...@cisco.com wrote:

We've found a way to recreate the scenario using
s_client/s_server.  We're using the -no_ticket option on the
server. Therefore, the ServerHello doesn't contain the
session ticket extension.  It also doesn't send the
NewSessionTicket message.

To summarize the problem, when the client side is using
SSL_set_session_secret_cb() and including a valid ticket in
the ClintHello, then the logic in ssl3_get_server_hello()
assumes the server is doing session resumption.  This puts
the client-side state machine into the
SSL3_ST_CR_FINISHED_A.  However, since the server side is
configured to not do resumption via the -no_ticket option,
the server continues with a normal handshake by sending the
Certificate message.  The client aborts the handshake when it
receives the Certificate message while in the
SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this
appears to be the addition of setting s-hit in the following
code:

if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
SSL_CIPHER *pref_cipher = NULL;
s-session-master_key_length = sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg)) {
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p + j);
s-hit = 1;
}
}

Why does the client-side now assume the server is doing
session resumption simply because the session secret callback
facility is being used?


Because a developer (me) introduced a bug. With OpenSSL client
behaviour, peeking ahead is only required for EAP-FAST. I got rid
of the peeking while tightening up the ChangeCipherSpec handling
and in the process, got it wrong for EAP-FAST. Anyway, apologies,
I see the problem and am working on a patch.

While we're at it, you may be able to help me with the following
question: how should the client handle callback failure? The old
code (pre my refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
/* check if we want to resume the session based on external pre-shared 
secret */
if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
{
SSL_CIPHER *pref_cipher=NULL;
s-session-master_key_length=sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[John Foley]

Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle a 
failure in the session secret callback, the legacy logic would likely 
result in a bad record mac error because the master secrets on the 
client/server do not match.  It would be good to trigger an internal 
error to aid with troubleshooting.  Maybe something like:


SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
goto err;

It's debatable whether the alert needs to be sent to the server. Since 
this is an internal error, it should be safe to send the alert.  
Therefore, maybe you would actually want to do something like:


SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
al = SSL_AD_INTERNAL_ERROR;
goto f_err;



On 03/23/2015 09:17 PM, Emilia Käsper wrote:



On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com 
mailto:fol...@cisco.com wrote:


We've found a way to recreate the scenario using
s_client/s_server.  We're using the -no_ticket option on the
server.  Therefore, the ServerHello doesn't contain the session
ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using
SSL_set_session_secret_cb() and including a valid ticket in the
ClintHello, then the logic in ssl3_get_server_hello() assumes the
server is doing session resumption.  This puts the client-side
state machine into the SSL3_ST_CR_FINISHED_A.  However, since the
server side is configured to not do resumption via the -no_ticket
option, the server continues with a normal handshake by sending
the Certificate message.  The client aborts the handshake when it
receives the Certificate message while in the
SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this
appears to be the addition of setting s-hit in the following code:

if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
SSL_CIPHER *pref_cipher = NULL;
s-session-master_key_length =
sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg)) {
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p + j);
s-hit = 1;
}
}

Why does the client-side now assume the server is doing session
resumption simply because the session secret callback facility is
being used?


Because a developer (me) introduced a bug. With OpenSSL client 
behaviour, peeking ahead is only required for EAP-FAST. I got rid of 
the peeking while tightening up the ChangeCipherSpec handling and in 
the process, got it wrong for EAP-FAST. Anyway, apologies, I see the 
problem and am working on a patch.


While we're at it, you may be able to help me with the following 
question: how should the client handle callback failure? The old code 
(pre my refactoring which introduced the bug) did this


#ifndef OPENSSL_NO_TLSEXT
/* check if we want to resume the session based on external pre-shared 
secret */
if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
{
SSL_CIPHER *pref_cipher=NULL;
s-session-master_key_length=sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia


From: openssl-dev [openssl-dev-boun...@openssl.org
mailto:openssl-dev-boun...@openssl.org] on behalf of Dr. Stephen
Henson [st...@openssl.org mailto:st...@openssl.org]
Sent: Thursday, March 19, 2015 11:49 AM
To: openssl-dev@openssl.org mailto:openssl-dev@openssl.org
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external
pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:


 If I do not send a sessionID in the clientHello but do send a valid
 sessionTicket extension, the server goes straight to
changeCipherSpec and
 the client generates an UnexpectedMessage alert.


Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[John Foley]

binBBeWr6TKqL.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[John Foley (foleyj)]

We've found a way to recreate the scenario using s_client/s_server.  We're 
using the -no_ticket option on the server.  Therefore, the ServerHello doesn't 
contain the session ticket extension.  It also doesn't send the 
NewSessionTicket message.  

To summarize the problem, when the client side is using 
SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, 
then the logic in ssl3_get_server_hello() assumes the server is doing session 
resumption.  This puts the client-side state machine into the 
SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do 
resumption via the -no_ticket option, the server continues with a normal 
handshake by sending the Certificate message.  The client aborts the handshake 
when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A 
state.


As Erik identified earlier in the thread, the cause of this appears to be the 
addition of setting s-hit in the following code:

if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
SSL_CIPHER *pref_cipher = NULL;
s-session-master_key_length = sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg)) {
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p + j);
s-hit = 1;
}
}

Why does the client-side now assume the server is doing session resumption 
simply because the session secret callback facility is being used?

From: openssl-dev [openssl-dev-boun...@openssl.org] on behalf of Dr. Stephen 
Henson [st...@openssl.org]
Sent: Thursday, March 19, 2015 11:49 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared 
secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:


 If I do not send a sessionID in the clientHello but do send a valid
 sessionTicket extension, the server goes straight to changeCipherSpec and
 the client generates an UnexpectedMessage alert.


Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
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] Usage of assembler code on ARM architectures

[John Foley]

My mistake, it looks like my memory was wrong on two accounts.  First,
it was AES, not SHA, where I observed the no-asm was faster.  Second, it
was on the PowerPC cross-compiled target, not ARM.  The results from
openssl speed aes-128-cbc are:

type 16 bytes 64 bytes256 bytes   1024 bytes   8192
bytes
w/o no-asm   31010.47k32988.82k33549.41k33693.05k   
33825.67k
no-asm   42431.46k46485.14k47479.20k47874.86k   
47829.36k

This is using a Freescale 8548.


On 03/12/2015 03:37 PM, Andy Polyakov wrote:
 I can't speak directly to your question on the iphone-cross target, but
 can warn you that your mileage will vary when using the ARM assembly
 modules.  We observed that some algorithms actually run slower when
 using the ARM assembly modules.  It's been a couple of years and I don't
 recall the details, but want to say some of the hash algorithms were
 actually faster when using no-asm.
 Well, I can imagine compiler succeeding to generate code better than
 sha1-armv4-large, but I can't imagine compiler beating sha256 or sha512.
 Was it really some of algorithm*s* or just one? Anyway, why
 sha1-amrv4-large? Two reasons: a) inner loops are not unrolled; b)
 over-reliance on merged rotate-n-arithmetic. Over-reliance means that
 it uses more such instructions than actually necessary, which can
 negatively affect performance. I realized this after having hard time
 getting sha256/512 to work well on Cortex-A53 (see sha512-armv8.pl, it's
 64-bit module, but principle of merged rotate-n-arithmetic is same). It
 should also be noted that now there are additional code paths in
 sha1-armv4-large, namely NEON and ARMv8.

 The results are likely to vary
 depending on the actual chipset used.
 Right, ARM universe is very diverse. Assembly modules, i.e. all, not
 only ARM, are maintained to provide near-optimal performance across
 range of platforms, but sometimes optimizations conflict. In either case
 prerequisite is access to wide range of platforms and feedback. In order
 words, bring it up.

 You'll probably want to test the
 performance on the target hardware using the openssl speed command. 
 You can do this on a jailbroken iOS device via SSH.
 For the record. I do development on non-jailbroken unit, so that it's
 not hard requirement.

 ___
 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] [openssl.org #3752] Patch to fix thread ID support from FIPS module

[John Foley via RT]

The following patch allows CRYPTO_thread_id() to be invoked from the
FIPS module.  Without this patch the thread ID can not be retrieved
properly, leading to thread synchronization issues in the FIPS module. 
Currently there's no way to exploit this problem since
CRYPTO_thread_id() isn't used within the FIPS module.  However,
including this patch may prevent some headaches if the FIPS module
should use CRYPTO_thread_id() in the future.


diff --git a/crypto/o_init.c b/crypto/o_init.c
index b7b969b..8ce85b9 100644
--- a/crypto/o_init.c
+++ b/crypto/o_init.c
@@ -73,6 +73,7 @@ void OPENSSL_init(void)
 done = 1;
 #ifdef OPENSSL_FIPS
 FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock);
+FIPS_crypto_set_id_callback(CRYPTO_thread_id);
 FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata);
 FIPS_set_malloc_callbacks(CRYPTO_malloc, CRYPTO_free);
 RAND_init_fips();



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

Re: [openssl-dev] [openssl.org #3744] Enhancement Request

[John Foley]

In addition to client authentication, another approach would be to use
TLS-SRP to protect against MITM.  Without the SRP credentials, the
attacker would not be able to establish the two TLS connections required
for MITM.

On 03/11/2015 09:35 AM, Short, Todd via RT wrote:
 This is more of a request to change the TLS protocol, than an enhancement to 
 OpenSSL.

 DHE and ECDHE ciphers provide PFS to protect against compromised public 
 key-pairs.

 However, if a MITM has the same certificate, signed by a trusted certificate 
 authority, then most bets are off.

 Client-authentication can provide additional protection against MITM attacks, 
 and allow servers to identify if a MITM is interfering with a valid user.
 --
 -Todd Short
 // tsh...@akamai.commailto:tsh...@akamai.com
 // “One if by land, two if by sea, three if by the Internet.

 On Mar 11, 2015, at 8:28 AM, Shawn Fernandes via RT 
 r...@openssl.orgmailto:r...@openssl.org wrote:

 Hi,
 At the moment, we have SSL handshake making use of a single certificate, 
 using a single key-pair present in the certificate.
 In the event the MITM has the same certificate(SSL - offloader) then the data 
 can be encrypted/decrypted.
 Would like to know if we can have the enhancement of using random key pair, 
 generated form each certificate, so that each SSL handshake would make use of 
 a random key-pair, and thereby give a different key value to each encryption 
 -decryption, and therby be able to determine if the MITM with a same 
 certificate has decrypted  encrypted data.
 With Regards,
 Shawn

 ___
 openssl-dev mailing list
 To unsubscribe: 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddevd=AwICAgc=96ZbZZcaMF4w0F4jpN6LZgr=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRikm=ds4i2k1LUtsCfZgPMHS2VdrUvh5w6_xSLfNdm1vpRPos=kEns4AYdLMO2_ASqWmVdf9jEzb8yMzvELxKIbzr6Mqce=


 ___
 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] Intermittent s_server issues with ECDHE cipher suites

[John Foley]

There appears to be a problem when using s_server with ECDHE cipher
suites in OpenSSL_1_0_1-stable.  Due to an uninitialized variable,
SSL_CTX_set_tmp_ecdh() is not always invoked within s_server.  The
following patch resolves the issue.  This bug appears to have been
introduced by 059907771b89549cbd07a81df1a5bdf51e062066.



diff --git a/apps/s_server.c b/apps/s_server.c
index caba5b3..2a44223 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -998,7 +998,7 @@ int MAIN(int argc, char *argv[])
 int off = 0;
 int no_tmp_rsa = 0, no_dhe = 0, nocert = 0;
 #ifndef OPENSSL_NO_ECDH
-int no_ecdhe;
+int no_ecdhe = 0;
 #endif
 int state = 0;
 const SSL_METHOD *meth = NULL;

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

Re: [openssl-dev] Seeking feedback on some #ifdef changes

[John Foley]

Sorry for responding late to this thread, but has anyone considered
consolidating the following three definitions:

OPENSSL_NO_EC
OPENSSL_NO_ECDH
OPENSSL_NO_EDDSA

Is there a valid case where all three of these wouldn't be used
together?  Would the code even compile if only one (or two) of these
were defined?


On 01/23/2015 02:11 PM, Salz, Rich wrote:

 Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef
 options and we are considering removing nearly a third of them. 
 Please reply soon if the following plan would cause problems. This
 will happen only in master, for post-1.0.2.

 We will remove the following options.  You could argue that the
 OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not
 compile without SHA and SHA1 defined, and we have no interest in
 spending the time to fix it. So for consistency, we will remove all of
 them.

 GENUINE_DSA (and the broken DSS0 since SHA0 will be removed)

 OPENSSL_NO_BIO

 OPENSSL_NO_BUFFER

 OPENSSL_NO_BUF_FREELISTS

 OPENSSL_NO_CHAIN_VERIFY

 OPENSSL_NO_DESCBCM (also removing the code; no EVP support)

 OPENSSL_NO_EVP

 OPENSSL_NO_FIPS_ERR

 OPENSSL_NO_HASH_COMP

 OPENSSL_NO_LHASH

 OPENSSL_NO_LOCKING

 OPENSSL_NO_MULTIBYTE (also removing the code)

 OPENSSL_NO_OBJECT

 OPENSSL_NO_RFC3779

 OPENSSL_NO_SHA

 OPENSSL_NO_SHA0 (also removing the code for SHA0)

 OPENSSL_NO_SHA1

 OPENSSL_NO_SHA224

 OPENSSL_NO_SHA256

 OPENSSL_NO_SHA384

 OPENSSL_NO_SHA512

 OPENSSL_NO_SPEED

 OPENSSL_NO_SSL_INTERN (first attempt at making things opaque)

 OPENSSL_NO_STACK

 OPENSSL_NO_STORE

 OPENSSL_NO_TLS

 OPENSSL_NO_TLS1

 OPENSSL_NO_TLS1_2_CLIENT

 OPENSSL_NO_TLSEXT

 OPENSSL_NO_X509

 OPENSSL_NO_X509_VERIFY

  

  

 -- 

 Principal Security Engineer, Akamai Technologies

 IM: rs...@jabber.me mailto:rs...@jabber.me Twitter: RichSalz

  



 ___
 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] Unused value in s3_srvr.c

[John Foley]

In the 1.0.2 stable branch, the following code in s3_srvr.c sets the
return value twice (line# 380).  Should the return value be
SSL_TLSEXT_ERR_ALERT_FATAL, or -1?


if (ret != SSL_ERROR_NONE) {
ssl3_send_alert(s, SSL3_AL_FATAL, al);
/*
 * This is not really an error but the only means to for
 * a client to detect whether srp is supported.
*/
if (al != TLS1_AD_UNKNOWN_PSK_IDENTITY)
SSLerr(SSL_F_SSL3_ACCEPT, SSL_R_CLIENTHELLO_TLSEXT);
ret = SSL_TLSEXT_ERR_ALERT_FATAL;
ret = -1;
goto end;
}
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2 regression with Cisco DTLS_BAD_VER

[John Foley]

Which Cisco product are you using, the ASA?  What version of software do
you have on the product?  While I can't speak for all Cisco products, I
can confirm that many Cisco products are using OpenSSL 1.0.1, which
implies support for DTLS 1.0. If you care to share more details, I can
try to engage the product team to better understand this.



On 02/16/2015 05:28 AM, David Woodhouse wrote:
 Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
 from dtls1_buffer_message() which was needed to distinguish between DTLS
 1.x and Cisco's pre-standard version of DTLS.

 $DEITY knows why Cisco haven't moved to the standard version of DTLS by
 now. The RFC was published in 2006, and since you can tell the
 difference on the wire it's *trivial* to have the server accept both and
 upgrade the clients piecemeal. The ocserv server manages this.

 But it isn't our place to marvel at Cisco's incompetence (like the fact
 that their DTLS implementation is still dropping out-of-order received
 packets, 6½ years after I fixed RT#1752). Our place is to try to be
 compatible with it. And this commit broke that, causing the OpenConnect
 VPN client to abort:

 Connected vpntest0 as 192.168.1.13, using SSL
 d1_both.c(1112): OpenSSL internal error, assertion failed: 
 s-d1-w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned 
 int)s-init_num
 Aborted (core dumped)

 ---
 The patch below fixes it. Tested in 1.0.2, but I haven't tested with
 HEAD yet because I need to work out how to set up the DTLS session to be
 resumed — none of this compiles any more...

 ../dtls.c: In function 'start_dtls_handshake':
 ../dtls.c:141:24: error: dereferencing pointer to incomplete type
vpninfo-dtls_session-ssl_version = 0x0100; /* DTLS1_BAD_VER */
 ^
 ../dtls.c:145:23: error: dereferencing pointer to incomplete type
   vpninfo-dtls_session-master_key_length = sizeof(vpninfo-dtls_secret);
^
 ../dtls.c:146:30: error: dereferencing pointer to incomplete type
   memcpy(vpninfo-dtls_session-master_key, vpninfo-dtls_secret,
   ^
 ../dtls.c:149:23: error: dereferencing pointer to incomplete type
   vpninfo-dtls_session-session_id_length = sizeof(vpninfo-dtls_session_id);
^
 ../dtls.c:150:30: error: dereferencing pointer to incomplete type
   memcpy(vpninfo-dtls_session-session_id, vpninfo-dtls_session_id,
   ^
 ../dtls.c:170:23: error: dereferencing pointer to incomplete type
   vpninfo-dtls_session-cipher = dtls_cipher;
^
 ../dtls.c:171:23: error: dereferencing pointer to incomplete type
   vpninfo-dtls_session-cipher_id = dtls_cipher-id;
^
 ../dtls.c:171:48: error: dereferencing pointer to incomplete type
   vpninfo-dtls_session-cipher_id = dtls_cipher-id;

 diff --git a/ssl/d1_both.c b/ssl/d1_both.c
 index 2553c3d..1116416 100644
 --- a/ssl/d1_both.c
 +++ b/ssl/d1_both.c
 @@ -1108,8 +1108,9 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
  memcpy(frag-fragment, s-init_buf-data, s-init_num);
  
  if (is_ccs) {
 + /* For DTLS_BAD_VER the header length is non-standard */
  OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
 -   DTLS1_CCS_HEADER_LENGTH == (unsigned int)s-init_num);
 +   
 ((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned 
 int)s-init_num);
  } else {
  OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
 DTLS1_HM_HEADER_LENGTH == (unsigned int)s-init_num);




 ___
 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] ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

[John Foley]

Is anyone seeing the following error when building master on Windows?

ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

NMAKE : fatal error U1077: 'C:\Program Files (x86)\Windows 
Kits\8.1\bin\x86\rc.EXE' : return code '0x1'
Stop.



The full build log is located here: 
http://openssl-sanity.cisco.com:8080/job/master_windows/42/console

The contents of version32.rc, which is a generated file, are located
here:
http://openssl-sanity.cisco.com:8080/job/master_windows/ws/ms/version32.rc/*view*/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

[John Foley]

Is anyone seeing the following error when building master on Windows?

ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

NMAKE : fatal error U1077: 'C:\Program Files (x86)\Windows 
Kits\8.1\bin\x86\rc.EXE' : return code '0x1'
Stop.



The full build log is located here: 
http://openssl-sanity.cisco.com:8080/job/master_windows/42/console

The contents of version32.rc, which is a generated file, are located
here:
http://openssl-sanity.cisco.com:8080/job/master_windows/ws/ms/version32.rc/*view*/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

[John Foley (foleyj)]

Yes, it's working now.  Thanks.

Are you interested in receiving the build failure notification directly from 
our Jenkins server?  Or would you rather I continue to forward the failures to 
Openssl-dev?


 On Feb 4, 2015, at 6:40 PM, Matt Caswell m...@openssl.org wrote:
 
 
 
 On 04/02/15 21:34, John Foley wrote:
 Is anyone seeing the following error when building master on Windows?
 
 ms\version32.rc(47) : fatal error RC1004: unexpected end of file found
 
 NMAKE : fatal error U1077: 'C:\Program Files (x86)\Windows 
 Kits\8.1\bin\x86\rc.EXE' : return code '0x1'
 Stop.
 
 I think Steve just fixed this.
 
 Matt
 
 ___
 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] Build failed in Jenkins: master_windows #32

[John Foley]

It looks like libeay.num and ssleay.num need updated too...

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 libeay  
1ms\libeay32.def 
WARNING: mkdef.pl doesn't know the following algorithms:
APPLINK
RMD160
Warning: RSA_padding_chk_PKCS1_OAEP_mgf1 does not have a number assigned
Warning: int does not have a number assigned
Warning: long does not have a number assigned
Warning: void does not have a number assigned

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 ssleay  
1ms\ssleay32.def 
WARNING: mkdef.pl doesn't know the following algorithms:
RMD160
APPLINK
Warning: SSL_COMP_free_compr_methods does not have a number assigned
Warning: SSL_COMP_set0_compr_methods does not have a number assigned




On 02/02/2015 10:34 PM, Kurt Cancemi wrote:
 I can confirm the patch works.

 Though it throws some unrelated warnings:
 /WARNING: mkdef.pl http://mkdef.pl doesn't know the following
 algorithms:
 RMD160
 APPLINK/

 ---
 Kurt Cancemi
 https://www.x64architecture.com

 On Mon, Feb 2, 2015 at 10:27 PM, Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com wrote:

 Yuk.  Perhaps if you could read it :)

 Edit util/mkdef.pl http://mkdef.pl and remove des_old.h from
 like 283 or so.


 ___
 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

[openssl-dev] Fwd: Build failed in Jenkins: master_windows #32

[John Foley (foleyj)]

It appears the Windows build is broken on master with the recent commit to the 
DES code.  Please see the error message at the bottom of this message...


Begin forwarded message:

From: openssl.san...@gmail.commailto:openssl.san...@gmail.com
Date: February 2, 2015 at 7:12:24 PM EST
To: fol...@cisco.commailto:fol...@cisco.com
Subject: Build failed in Jenkins: master_windows #32
Reply-To: openssl.san...@gmail.commailto:openssl.san...@gmail.com

See http://173.39.238.160:8080/job/master_windows/32/changes

Changes:

[rsalz] Remove old DES API

--
Started by upstream project master_basic build number 100
originally caused by:
Started by an SCM change
Building remotely on windows-slave in workspace 
http://173.39.238.160:8080/job/master_windows/ws/
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url https://github.com/openssl/openssl.git # timeout=10
Cleaning workspace
git rev-parse --verify HEAD # timeout=10
Resetting working tree
git reset --hard # timeout=10
git clean -fdx # timeout=10
Fetching upstream changes from https://github.com/openssl/openssl.git
git --version # timeout=10
git -c core.askpass=true fetch --tags --progress 
https://github.com/openssl/openssl.git +refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 24956ca00f014a917fb181a8abc39b349f3f316f 
(refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f 24956ca00f014a917fb181a8abc39b349f3f316f
git rev-list fd22ab9edf497ad7d98897377ee798953845d022 # timeout=10
[master_windows] $ cmd /c call 
C:\Users\ADMINI~1\AppData\Local\Temp\1\hudson5369467623327537492.bat

http://173.39.238.160:8080/job/master_windows/ws/call c:\program files 
(x86)\microsoft visual studio 12.0\vc\bin\vcvars32.bat

http://173.39.238.160:8080/job/master_windows/ws/set 
PROCESSOR_ARCHITECTURE=x86

http://173.39.238.160:8080/job/master_windows/ws/perl Configure VC-WIN32
Configuring for VC-WIN32
   no-deprecated   [default]  OPENSSL_NO_DEPRECATED (skip dir)
   no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
   no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
   no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
   no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
   no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
   no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
   no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
   no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
   no-shared   [default]
   no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
   no-store[experimental] OPENSSL_NO_STORE (skip dir)
   no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
   no-zlib [default]
   no-zlib-dynamic [default]
IsMK1MF=1
CC=cl
CFLAG =-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo 
-DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
EX_LIBS   =
CPUID_OBJ =x86cpuid.o
BN_ASM=bn-586.o co-586.o x86-mont.o x86-gf2m.o
EC_ASM=
DES_ENC   =des-586.o crypt586.o
AES_ENC   =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC=bf-586.o
CAST_ENC  =cast-586.o
RC4_ENC   =rc4-586.o
RC5_ENC   =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC  =cmll-x86.o
MODES_OBJ =ghash-x86.o
ENGINES_OBJ   =e_padlock-x86.o
PROCESSOR =
RANLIB=true
ARFLAGS   =
PERL  =perl
THIRTY_TWO_BIT mode
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined

Configured for VC-WIN32.

http://173.39.238.160:8080/job/master_windows/ws/ms\do_nasm.bat

http://173.39.238.160:8080/job/master_windows/ws/perl util\mkfiles.pl  
1MINFO

http://173.39.238.160:8080/job/master_windows/ws/perl util\mk1mf.pl nasm 
VC-WIN32  1ms\nt.mak

http://173.39.238.160:8080/job/master_windows/ws/perl util\mk1mf.pl dll nasm 
VC-WIN32  1ms\ntdll.mak

http://173.39.238.160:8080/job/master_windows/ws/perl util\mk1mf.pl nasm 
BC-NT  1ms\bcb.mak

http://173.39.238.160:8080/job/master_windows/ws/perl util\mkdef.pl 32 
libeay  1ms\libeay32.def
unable to open crypto/des/des_old.h:No such file or directory

http://173.39.238.160:8080/job/master_windows/ws/perl util\mkdef.pl 32 
ssleay  1ms\ssleay32.def
unable to open crypto/des/des_old.h:No such file or directory
Build step 'Execute Windows batch command' marked build as failure
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows build broken?

[John Foley]

Thanks for fixing this.  Windows is now building on 1_0_1-stable. 
Having said that, you inspired me to add another job on my jenkins
server to to a sanity build on master for Windows.  I'm seeing the
following error when trying to build on master using the identical build
process.  Should I dig deeper, or is this a known issue?

c:\nightly\workspace\master_windowsms\do_nasm.bat

c:\nightly\workspace\master_windowsperl util\mkfiles.pl  1MINFO 

c:\nightly\workspace\master_windowsperl util\mk1mf.pl nasm VC-WIN32  
1ms\nt.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mk1mf.pl dll nasm VC-WIN32  
1ms\ntdll.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mk1mf.pl nasm BC-NT  1ms\bcb.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 libeay  
1ms\libeay32.def 
No such class my at util\mkdef.pl line 143, near my my
Execution of util\mkdef.pl aborted due to compilation errors.

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 ssleay  
1ms\ssleay32.def 
No such class my at util\mkdef.pl line 143, near my my
Execution of util\mkdef.pl aborted due to compilation errors.
Build step 'Execute Windows batch command' marked build as failure
Sending e-mails to: fol...@cisco.com
Finished: FAILURE




On 01/27/2015 05:05 PM, Salz, Rich wrote:
 I'm sure this would resolve the issue.  The problem exists in 1.0.1, but not
 1.0.2.  Here's the entry in the 1.0.1 libeay.num:
 Fixed.  It was a mistake to remove engine_rsax, and I just reverted that.  
 Should show up in the snapshots within an hour
 ___
 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] Windows build broken?

[John Foley]

Thanks for fixing this.  Windows is now building on 1_0_1-stable. 
Having said that, you inspired me to add another job on my jenkins
server to to a sanity build on master for Windows.  I'm seeing the
following error when trying to build on master using the identical build
process.  Should I dig deeper, or is this a known issue?

c:\nightly\workspace\master_windowsms\do_nasm.bat

c:\nightly\workspace\master_windowsperl util\mkfiles.pl  1MINFO 

c:\nightly\workspace\master_windowsperl util\mk1mf.pl nasm VC-WIN32  
1ms\nt.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mk1mf.pl dll nasm VC-WIN32  
1ms\ntdll.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mk1mf.pl nasm BC-NT  1ms\bcb.mak 
no rule for crypto\sha\shatest at util\mk1mf.pl line 1253.

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 libeay  
1ms\libeay32.def 
No such class my at util\mkdef.pl line 143, near my my
Execution of util\mkdef.pl aborted due to compilation errors.

c:\nightly\workspace\master_windowsperl util\mkdef.pl 32 ssleay  
1ms\ssleay32.def 
No such class my at util\mkdef.pl line 143, near my my
Execution of util\mkdef.pl aborted due to compilation errors.
Build step 'Execute Windows batch command' marked build as failure
Sending e-mails to: fol...@cisco.com
Finished: FAILURE




On 01/27/2015 05:05 PM, Salz, Rich wrote:
 I'm sure this would resolve the issue.  The problem exists in 1.0.1, but not
 1.0.2.  Here's the entry in the 1.0.1 libeay.num:
 Fixed.  It was a mistake to remove engine_rsax, and I just reverted that.  
 Should show up in the snapshots within an hour
 ___
 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] Windows build broken?

[John Foley]

It looks like the Windows export symbols may need updating now that the
rsax engine has been removed (yesterday).  Here's the error from the log...

link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll 
/def:ms/LIBEAY32.def @C:\Users\ADMINI~1\AppData\Local\Temp\1\nm3A91.tmp
LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_rsax
out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\link.EXE' : return code '0x460'
Stop.

The full log is located here:

http://173.39.238.160:8080/job/1_0_1_windows/16/console


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

Re: [openssl-dev] Windows build broken?

[John Foley]

I'm sure this would resolve the issue.  The problem exists in 1.0.1, but
not 1.0.2.  Here's the entry in the 1.0.1 libeay.num:

ENGINE_load_rsax 4652 EXIST::FUNCTION:ENGINE

And here's the entry in the 1.0.2 flavor of libeay.num:

ENGINE_load_rsax 4652 NOEXIST::FUNCTION:

You just need to to make util/libeay.num in the 1.0.1-stable branch. 
FYI, I have not checked master.



On 01/27/2015 12:54 PM, Salz, Rich wrote:
 It looks like the Windows export symbols may need updating now that the
 rsax engine has been removed (yesterday).  Here's the error from the log...
 If you remove the reference to it from util/libeay.num does that fix the 
 build?

 --  
 Principal Security Engineer, Akamai Technologies
 IM: rs...@jabber.me Twitter: RichSalz

 ___
 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] Windows build broken?

[John Foley]

Thanks for the update.  I was curious why it was removed from 1.0.1.  It
seemed to be beyond the scope of a bug fix.  Given 1.0.2 has now been
released, should eng_rsax been removed there too?



On 01/27/2015 01:06 PM, Salz, Rich wrote:
 Oh, I thought it was in master!

 In 1.0.1 it was a mistake to remove eng_rsax.  And a commit to fix that will 
 be submitted shortl.


 --  
 Principal Security Engineer, Akamai Technologies
 IM: rs...@jabber.me Twitter: RichSalz


 ___
 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] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds

[John Foley via RT]

Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
or is this a tool chain issue?  

Assembling: tmp32\sha1-586.asm
tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands
tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\ml.EXE' : return code '0x1'
Stop.

I'm using VS 2013.  This problem does not occur on 1.0.1.  Using the following 
steps works on 1.0.1-stable:

perl Configure VC-WIN32
ms\do_ms.bat
nmake -f ms\nt.mak


Here's the log from the broken 1.0.2 build:

http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console

Here's the log from the working 1.0.1 build:

http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console


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

Re: [openssl-dev] 1.0.2-stable broken Windows build?

[John Foley]

Given the 1.0.2 release is forthcoming in the near future, it would be
good if someone could look at this issue.  It looks like there were a
lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA
extensions, which aren't available until Skylake. 

Is there a new tool chain requirement for building 1.0.2 on Windows? 
Has the build procedure changed?  Or is this simply a bug in sha1-586.pl?



On 01/08/2015 03:41 PM, John Foley wrote:
 Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
 or is this a tool chain issue?  I'm using VS 2013.  Using the following
 steps works on 1.0.1-stable:

 perl Configure VC-WIN32
 ms\do_ms.bat
 nmake -f ms\nt.mak


 Here's the log from the broken 1.0.2 build:

 http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console

 Here's the log from the working 1.0.1 build:

 http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console

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

Re: [openssl-dev] 1.0.2-stable broken Windows build?

[John Foley]

Thanks for responding.  Which tool chain are you using?  I'm using VS
2013 with the ml compiler.  Given this assembly is generated by a perl
script, maybe it's a perl issue.  Which perl interpreter are you using?


On 01/13/2015 09:24 AM, Matt Caswell wrote:

 On 13/01/15 14:05, John Foley wrote:
 Given the 1.0.2 release is forthcoming in the near future, it would be
 good if someone could look at this issue.  It looks like there were a
 lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA
 extensions, which aren't available until Skylake. 

 Is there a new tool chain requirement for building 1.0.2 on Windows? 
 Has the build procedure changed?  Or is this simply a bug in sha1-586.pl?
 Hm...I have built 1.0.2 on Windows myself today without this
 problem. The tool chain and build procedure are unchanged. Strange.

 Matt

 ___
 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] 1.0.2-stable broken Windows build?

[John Foley]

Thanks for setting me straight.  1.0.2 works for me when using nasm.


On 01/13/2015 10:00 AM, Andy Polyakov wrote:
 Thanks for responding.  Which tool chain are you using?  I'm using VS
 2013 with the ml compiler.  Given this assembly is generated by a perl
 script, maybe it's a perl issue.  Which perl interpreter are you using?
 Quoting INSTALL.W32:

 Netwide Assembler, a.k.a. NASM, available from
 http://nasm.sourceforge.net/ is required if you intend to utilize
 assembler modules. Note that NASM is now the only supported assembler.

 You can drop nasm.exe to any place on %PATH% to get it working.

 This means that we formally don't accept problem reports for ml. One can
 argue that we ought to, because ml might be not as bad as it used to.
 But if we change this, it would probably be more appropriate to do in
 post-1.0.2 context. But it doesn't harm to ask for more details. I tried
 to emit code for ml and lines in question, i.e. 1432 and 1576, appear
 totally innocent, as there are similar instructions next to them. How do
 these lines look like for you? I mean could you just copy-n-paste say 5
 lines fragments around those line numbers?

 Given the 1.0.2 release is forthcoming in the near future, it would be
 good if someone could look at this issue.  It looks like there were a
 lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA
 extensions,
 SHA-extension-specific code doesn't require explicit support from
 assembler, or in other words, it can be assembled with assembler that is
 not aware of SHA extensions. This is because those instructions are
 encoded manually with DB/.byte directive.

 which aren't available until Skylake.
 For reference, first processor that will have SHA extensions is
 Goldmont, Silvermont's successor, i.e. one from Atom family.

 ___
 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] 1.0.2-stable broken Windows build?

[John Foley]

Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
or is this a tool chain issue?  I'm using VS 2013.  Using the following
steps works on 1.0.1-stable:

perl Configure VC-WIN32
ms\do_ms.bat
nmake -f ms\nt.mak


Here's the log from the broken 1.0.2 build:

http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console

Here's the log from the working 1.0.1 build:

http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Make errors broken in s3_clnt.c

[John Foley]

It appears there's another error num breakage in ssl/s3_clnt.c at line
1544.  Please see the details at the bottom of the following log:

http://173.39.238.160:8080/job/1_0_1_make_errors/1/console

Please see my comment under commit
37580f43b5a39f5f4e920d17273fab9713d3a744 in github with the suggested
resolution.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley]

The first chunk in the s3_lib.c patch doesn't apply.  But the second
chunk does (shown below).  When applying this to 1.0.1 stable, it
appears to resolve the problem.

@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
 #ifndef OPENSSL_NO_SRP
-   mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
-   emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+   if (s-srp_ctx.srp_Mask  SSL_kSRP)
+   {
+   mask_k |= SSL_kSRP;
+   emask_k |= SSL_kSRP;
+   mask_a |= SSL_aSRP;
+   emask_a |= SSL_aSRP;
+   }
 #endif
   
 #ifdef KSSL_DEBUG

On 08/12/2014 01:43 PM, Kurt Roeckx via RT wrote:
 On Tue, Aug 12, 2014 at 01:26:30AM +0200, John Foley via RT wrote:
 The commit into 1.0.1 didn't include the changes to s3_lib.c.  SRP is still 
 broken on this branch.  Are there any plans to fix this?
 Can you confirm that that commit from master fixes things for you?

 On Aug 11, 2014, at 6:41 PM, Kurt Roeckx via RT r...@openssl.org wrote:

 On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
 The fix discussed in this thread appears to be incomplete:

 http://marc.info/?l=openssl-usersm=140752401023837w=2

 This fix works for SRP cipher suites that uses RSA for DSA, which
 includes 6 of the 9 supported SRP cipher suites.  But the three SRP
 cipher suites that don't rely on a server-side certificate are still
 broken.  This problem can be recreated using these commands:
 I believe this is already in master in commit
 9e72d496d4f9880ec98f0ed9168246e35c1c3059


 Kurt



 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


 .

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley via RT]

Thank you.


On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
 On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
 On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
 The first chunk in the s3_lib.c patch doesn't apply.  But the second
 chunk does (shown below).  When applying this to 1.0.1 stable, it
 appears to resolve the problem.

 @@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
 STACK_OF(SSL_CIPHER) *clnt,
 emask_k = cert-export_mask_k;
 emask_a = cert-export_mask_a;
  #ifndef OPENSSL_NO_SRP
 -   mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
 -   emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
 +   if (s-srp_ctx.srp_Mask  SSL_kSRP)
 +   {
 +   mask_k |= SSL_kSRP;
 +   emask_k |= SSL_kSRP;
 +   mask_a |= SSL_aSRP;
 +   emask_a |= SSL_aSRP;
 +   }
  #endif

  #ifdef KSSL_DEBUG
 I assumed you were talking about the 1.0.1i release and not the
 current git.   When the mentioned commit got merged into the 1.0.1
 branch the above part was somehow lost.  It should get added to
 the 1.0.1 branch soon.
 So this got fixed in commit
 03ebf85f7757c5da9f9d4fecb8ea1a1af18df46d, closing the ticket.


 Kurt


 .



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley]

Thank you.


On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
 On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
 On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
 The first chunk in the s3_lib.c patch doesn't apply.  But the second
 chunk does (shown below).  When applying this to 1.0.1 stable, it
 appears to resolve the problem.

 @@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
 STACK_OF(SSL_CIPHER) *clnt,
 emask_k = cert-export_mask_k;
 emask_a = cert-export_mask_a;
  #ifndef OPENSSL_NO_SRP
 -   mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
 -   emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
 +   if (s-srp_ctx.srp_Mask  SSL_kSRP)
 +   {
 +   mask_k |= SSL_kSRP;
 +   emask_k |= SSL_kSRP;
 +   mask_a |= SSL_aSRP;
 +   emask_a |= SSL_aSRP;
 +   }
  #endif

  #ifdef KSSL_DEBUG
 I assumed you were talking about the 1.0.1i release and not the
 current git.   When the mentioned commit got merged into the 1.0.1
 branch the above part was somehow lost.  It should get added to
 the 1.0.1 branch soon.
 So this got fixed in commit
 03ebf85f7757c5da9f9d4fecb8ea1a1af18df46d, closing the ticket.


 Kurt


 .

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley via RT]

The first chunk in the s3_lib.c patch doesn't apply.  But the second
chunk does (shown below).  When applying this to 1.0.1 stable, it
appears to resolve the problem.

@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
 #ifndef OPENSSL_NO_SRP
-   mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
-   emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+   if (s-srp_ctx.srp_Mask  SSL_kSRP)
+   {
+   mask_k |= SSL_kSRP;
+   emask_k |= SSL_kSRP;
+   mask_a |= SSL_aSRP;
+   emask_a |= SSL_aSRP;
+   }
 #endif
   
 #ifdef KSSL_DEBUG

On 08/12/2014 01:43 PM, Kurt Roeckx via RT wrote:
 On Tue, Aug 12, 2014 at 01:26:30AM +0200, John Foley via RT wrote:
 The commit into 1.0.1 didn't include the changes to s3_lib.c.  SRP is still 
 broken on this branch.  Are there any plans to fix this?
 Can you confirm that that commit from master fixes things for you?

 On Aug 11, 2014, at 6:41 PM, Kurt Roeckx via RT r...@openssl.org wrote:

 On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
 The fix discussed in this thread appears to be incomplete:

 http://marc.info/?l=openssl-usersm=140752401023837w=2

 This fix works for SRP cipher suites that uses RSA for DSA, which
 includes 6 of the 9 supported SRP cipher suites.  But the three SRP
 cipher suites that don't rely on a server-side certificate are still
 broken.  This problem can be recreated using these commands:
 I believe this is already in master in commit
 9e72d496d4f9880ec98f0ed9168246e35c1c3059


 Kurt



 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


 .



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley via RT]

The fix discussed in this thread appears to be incomplete:

http://marc.info/?l=openssl-usersm=140752401023837w=2

This fix works for SRP cipher suites that uses RSA for DSA, which
includes 6 of the 9 supported SRP cipher suites.  But the three SRP
cipher suites that don't rely on a server-side certificate are still
broken.  This problem can be recreated using these commands:

openssl s_server -srpvfile passwd.srpv -nocert -cipher
'ALL:!eNULL:!SSLv2:!EXPORT:SRP'
openssl s_client -cipher SRP -srpuser estuser

The error observed on the server-side is:

3075913352:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared
cipher:s3_srvr.c:1359:

The attached patch resolves the problem.

*** ssl_lib.c.orig	2014-08-11 14:57:47.617720888 -0400
--- ssl_lib.c	2014-08-11 14:58:09.449746325 -0400
*** void ssl_set_cert_masks(CERT *c, const S
*** 2138,2143 
--- 2138,2150 
  	mask_a|=SSL_aNULL;
  	emask_a|=SSL_aNULL;
  
+ #ifndef OPENSSL_NO_SRP
+ 	if (cipher-algorithm_auth  SSL_aSRP) {
+ 	mask_a |= SSL_aSRP;
+ 	emask_a |= SSL_aSRP;
+ 	}
+ #endif
+ 
  #ifndef OPENSSL_NO_KRB5
  	mask_k|=SSL_kKRB5;
  	mask_a|=SSL_aKRB5;

Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot

[John Foley via RT]

The commit into 1.0.1 didn't include the changes to s3_lib.c.  SRP is still 
broken on this branch.  Are there any plans to fix this?

 On Aug 11, 2014, at 6:41 PM, Kurt Roeckx via RT r...@openssl.org wrote:
 
 On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
 The fix discussed in this thread appears to be incomplete:
 
 http://marc.info/?l=openssl-usersm=140752401023837w=2
 
 This fix works for SRP cipher suites that uses RSA for DSA, which
 includes 6 of the 9 supported SRP cipher suites.  But the three SRP
 cipher suites that don't rely on a server-side certificate are still
 broken.  This problem can be recreated using these commands:
 
 I believe this is already in master in commit
 9e72d496d4f9880ec98f0ed9168246e35c1c3059
 
 
 Kurt
 
 


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3405] 1.0.2 trunk doesn't build on 64-bit linux

[John Foley via RT]

The following error occurs using the 20140613 snapshot on the 1.0.2
trunk.  The host is a 64-bit CentOS system.  This problem does
not occur on 32-bit CentOS.   


gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
sha1-x86_64.s: Assembler messages:
sha1-x86_64.s:1393: Error: no such instruction: `sha1nexte %xmm9,%xmm1'
make[2]: *** [sha1-x86_64.o] Error 1
make[2]: Leaving directory
`/nobackup/foleyj/102/openssl-1.0.2-stable-SNAP-20140612/crypto/sha'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory
`/nobackup/foleyj/102/openssl-1.0.2-stable-SNAP-20140612/crypto'
make: *** [build_crypto] Error 1

Here's the gcc version...

[foleyj@buildserver1 openssl-1.0.2-stable-SNAP-20140612]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


/proc/cpuinfo shows...

processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 45
model name: Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz
stepping: 7
cpu MHz: 1200.000
cache size: 20480 KB
physical id: 0
siblings: 16
core id: 0
cpu cores: 8
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht t
m pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64
 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1
sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm i
da arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips: 4199.54
clflush size: 64
cache_alignment: 64
address sizes: 46 bits physical, 48 bits virtual
power management:


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

1.0.2 build breakage

[John Foley]

The following error occurs using the 20140612 snapshot on the 1.0.2
trunk.  The host is a 64-bit CentOS system.  Is this a known issue? 


gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
sha1-x86_64.s: Assembler messages:
sha1-x86_64.s:1393: Error: no such instruction: `sha1nexte %xmm9,%xmm1'
make[2]: *** [sha1-x86_64.o] Error 1
make[2]: Leaving directory
`/nobackup/foleyj/102/openssl-1.0.2-stable-SNAP-20140612/crypto/sha'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory
`/nobackup/foleyj/102/openssl-1.0.2-stable-SNAP-20140612/crypto'
make: *** [build_crypto] Error 1

Here's the gcc version...

[foleyj@buildserver1 openssl-1.0.2-stable-SNAP-20140612]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


/proc/cpuinfo shows...

processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 45
model name: Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz
stepping: 7
cpu MHz: 1200.000
cache size: 20480 KB
physical id: 0
siblings: 16
core id: 0
cpu cores: 8
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht t
m pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64
 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1
sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm i
da arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips: 4199.54
clflush size: 64
cache_alignment: 64
address sizes: 46 bits physical, 48 bits virtual
power management:


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl] OpenSSL source code branch OpenSSL_1_0_2-stable updated. OpenSSL_1_0_2-beta1-172-ge3beef1

[John Foley]

Can we imply from this commit that the 1.0.2 release is imminent?  If
not, can anyone provide a rough estimate on when 1.0.2 will be released
(1 month, 3 months, 6 months from now)?


On 06/10/2014 10:17 AM, Dr. Stephen Henson wrote:
 This is an automated email from the git hooks/post-receive script. It was
 generated because a ref change was pushed to the repository containing
 the project OpenSSL source code.

 The branch, OpenSSL_1_0_2-stable has been updated
via  e3beef1e1bdd70031d009dc61ab88b74a4c884c8 (commit)
via  cea5a1d5f255a6a186cd7944c4a312612da965f3 (commit)
   from  f472ada00681d0de7c68d13ecbd404d822afa8b1 (commit)

 Those revisions listed above that are new to this repository have
 not appeared on any other notification email; so we list those
 revisions in full, below.

 - Log -
 commit e3beef1e1bdd70031d009dc61ab88b74a4c884c8
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Fri Jun 6 18:56:24 2014 +0100

 Remove experimental DANE code.
 
 Remove experimental DANE/dnssec code: not ready for use in an
 official release yet.

 commit cea5a1d5f255a6a186cd7944c4a312612da965f3
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Tue Jun 10 14:47:29 2014 +0100

 Fix null pointer errors.
 
 PR#3394
 (cherry picked from commit 7a9d59c148b773f59a41f8697eeecf369a0974c2)

 ---

 Summary of changes:
  Configure |3 +-
  crypto/ocsp/ocsp_ht.c |3 +
  ssl/Makefile  |   23 +
  ssl/d1_both.c |2 +
  ssl/dnssec.c  |  182 --
  ssl/ssl_cert.c|  264 
 -
  ssl/ssl_lib.c |   38 ---
  ssl/ssl_locl.h|   11 ---
  util/mk1mf.pl |1 -
  9 files changed, 8 insertions(+), 519 deletions(-)
  delete mode 100644 ssl/dnssec.c

 diff --git a/Configure b/Configure
 index ca45eb2..885e341 100755
 --- a/Configure
 +++ b/Configure
 @@ -724,7 +724,6 @@ if (exists $ENV{FIPSDIR})
  # All of the following is disabled by default (RC5 was enabled before 0.9.8):
  
  my %disabled = ( # what = comment [or special keyword 
 experimental]
 -  dane   = experimental,
ec_nistp_64_gcc_128 = default,
gmp= default,
jpake  = experimental,
 @@ -744,7 +743,7 @@ my @experimental = ();
  
  # This is what $depflags will look like with the above defaults
  # (we need this to see if we should advise the user to run make depend):
 -my $default_depflags =  -DOPENSSL_NO_DANE -DOPENSSL_NO_EC_NISTP_64_GCC_128 
 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 
 -DOPENSSL_NO_MULTIBLOCK -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 
 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE;
 +my $default_depflags =  -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP 
 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 
 -DOPENSSL_NO_MULTIBLOCK -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 
 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE;
  
  # Explicit no-... options will be collected in %disabled along with the 
 defaults.
  # To remove something from %disabled, use enable-foo (unless it's 
 experimental).
 diff --git a/crypto/ocsp/ocsp_ht.c b/crypto/ocsp/ocsp_ht.c
 index a053047..bac35f8 100644
 --- a/crypto/ocsp/ocsp_ht.c
 +++ b/crypto/ocsp/ocsp_ht.c
 @@ -571,6 +571,9 @@ OCSP_RESPONSE *OCSP_sendreq_bio(BIO *b, const char *path, 
 OCSP_REQUEST *req)
  
   ctx = OCSP_sendreq_new(b, path, req, -1);
  
 + if (!ctx)
 + return NULL;
 +
   do
   {
   rv = OCSP_sendreq_nbio(resp, ctx);
 diff --git a/ssl/Makefile b/ssl/Makefile
 index b1d20b0..be14603 100644
 --- a/ssl/Makefile
 +++ b/ssl/Makefile
 @@ -30,7 +30,7 @@ LIBSRC= \
   ssl_lib.c ssl_err2.c ssl_cert.c ssl_sess.c \
   ssl_ciph.c ssl_stat.c ssl_rsa.c \
   ssl_asn1.c ssl_txt.c ssl_algs.c ssl_conf.c \
 - bio_ssl.c ssl_err.c kssl.c t1_reneg.c tls_srp.c t1_trce.c dnssec.c
 + bio_ssl.c ssl_err.c kssl.c t1_reneg.c tls_srp.c t1_trce.c
  LIBOBJ= \
   s2_meth.o  s2_srvr.o  s2_clnt.o  s2_lib.o  s2_enc.o s2_pkt.o \
   s3_meth.o  s3_srvr.o  s3_clnt.o  s3_lib.o  s3_enc.o s3_pkt.o s3_both.o 
 s3_cbc.o \
 @@ -41,7 +41,7 @@ LIBOBJ= \
   ssl_lib.o ssl_err2.o ssl_cert.o ssl_sess.o \
   ssl_ciph.o ssl_stat.o ssl_rsa.o \
   ssl_asn1.o ssl_txt.o ssl_algs.o ssl_conf.o \
 - bio_ssl.o ssl_err.o kssl.o t1_reneg.o tls_srp.o t1_trce.o dnssec.o
 + bio_ssl.o ssl_err.o kssl.o t1_reneg.o tls_srp.o t1_trce.o
  
  SRC= $(LIBSRC)
  
 @@ -288,25 +288,6 @@ d1_srvr.o: ../include/openssl/ssl3.h 
 ../include/openssl/stack.h
  d1_srvr.o: ../include/openssl/symhacks.h ../include/openssl/tls1.h
  d1_srvr.o: ../include/openssl/x509.h ../include/openssl/x509_vfy.h 

Re: [openssl] OpenSSL source code branch OpenSSL_1_0_2-stable updated. OpenSSL_1_0_2-beta1-172-ge3beef1

[John Foley]

Thanks for the guidance, much appreciated.


On 06/10/2014 10:31 AM, Dr. Stephen Henson wrote:
 On Tue, Jun 10, 2014, John Foley wrote:

 Can we imply from this commit that the 1.0.2 release is imminent?  If
 not, can anyone provide a rough estimate on when 1.0.2 will be released
 (1 month, 3 months, 6 months from now)?

 A 1.0.2-beta2 release will happen shortly (the next day or so). So please test
 the latest snapshots and report any problems and preferably fixes.

 The actual 1.0.2 release timing will depend on any critical issues reported in
 beta2.

 I'd hope for a 1.0.2 release less than a month from now though.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[John Foley]

Here's more information for those who are interested...

https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80



On 05/06/2014 07:08 PM, Viktor Dukhovni wrote:
 On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote:

 The defect information is available at
 https://tools.cisco.com/bugsearch/bug/CSCuo25329.  This defect is
 viewable to the public.  You'll have to register for an account to view
 the data. 
 After registering, the bug details are:

 Heartbleed patched email servers, fail TLS connections to ESAs 8.0 +
 CSCuo25329
 Description
 Symptom:
 Machines installed with OpenSSL 1.0.1g patch fail to connect with Cisco
 Email Security Appliance

 Conditions:
 Cisco AsyncOS 8.0 for Email or later.

 Status: Fixed

 Known Affected Releases:
 8.0.1
 8.5.5
 8.5.0

 Severity: 1 Catastrophic

 So what we learn is that perhaps this problem is present in only
 the latest general availability release and two limited availability
 releases.  If so, we can hope that customers running this release
 have support contracts, and the issue will not be with us for very
 long.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[John Foley]

The defect information is available at
https://tools.cisco.com/bugsearch/bug/CSCuo25329.  This defect is
viewable to the public.  You'll have to register for an account to view
the data. 

Viktor already provided a link to the following details as well:

http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-0/release_notes/ESA_8-0-1_HP2_Release_Notes.pdf




On 05/06/2014 01:10 PM, Kurt Roeckx wrote:
 On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote:
 I'm trying to get that information from the IronPort team.  In the mean
 time, this bug report appears to have some details:

 https://tools.cisco.com/bugsearch/bug/CSCuo25329
 It would really be nice that we can get some more information
 about this, specially if there is a way to work around it.


 Kurt



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[John Foley]

How prevalent is RC4 today?  While web browsers still advertise RC4
cipher suites, how often do you see RC4 cipher suites advertised by the
client and no AES or 3DES suites advertised?  Does Akamai have any data
on this?  Maybe RC4 should now be disabled by default.


On 05/02/2014 09:49 AM, Salz, Rich wrote:
 Steve, have you considered trimming the DEFAULT cipher list?
 It's currently...
 #define SSL_DEFAULT_CIPHER_LIST  ALL:!aNULL:!eNULL:!SSLv2
 I wonder how many of these ciphers are actually ever negotiated in 
 real-world use.
 I'm forwarding a bit of internal discussion; hope it's useful.  This is from 
 one of our chief info-sec people:
 My weak opinion is that cipher brokenness is most important (so put 3DES and 
 RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed 
 by  hash strength, followed by PFS presence, followed by SHA and AES bit 
 length.  I think that would give us:

 ECDHE-ECDSA-AES256-GCM-SHA384
 ECDHE-ECDSA-AES256-GCM-SHA256
 ECDHE-ECDSA-AES128-GCM-SHA256
 ECDHE-RSA-AES256-GCM-SHA384
 ECDHE-RSA-AES128-GCM-SHA256
 AES256-GCM-SHA384
 AES128-GCM-SHA256
 ECDHE-ECDSA-AES256-SHA384
 ECDHE-ECDSA-AES256-SHA256
 ECDHE-ECDSA-AES128-SHA256
 ECDHE-RSA-AES256-SHA384
 ECDHE-RSA-AES128-SHA256
 AES256-SHA256
 AES128-SHA256
 AES128-SHA
 RC4-SHA
 DES-CBC3-SHA

 --  
 Principal Security Engineer
 Akamai Technologies, Cambridge, MA
 IM: rs...@jabber.me; Twitter: RichSalz

 :��IϮ��r�m(���Z+�7�zZ)���1���x��h���W^��^��%��

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[John Foley]

This is a known problem in the Ironport TLS stack.  Ironport has
released a hot patch to address this problem.


On 05/01/2014 06:29 AM, Marcus Meissner via RT wrote:
 Hi,

 SUSE has received a bugreport from a user, that the padding extension
 change breaks IronPort SMTP appliances.

 There might a RT on this already, not sure.

 https://bugzilla.novell.com/show_bug.cgi?id=875639
 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html

 Quoting from our openSUSE bugreport:

 Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some
 services, e.g. Cisco Ironport SMTP appliances.

 1.0.1g not only fixes the Heartbleed bug but also adds another change by
 adding:
 #define TLSEXT_TYPE_padding 21

 This in turn breaks SSL connections to e.g. Ironports, probably others:
 SSL23_GET_SERVER_HELLO:tlsv1 alert decode error

 Workaround: Force protocol to SSLv3 or recompile without the define above.

 For details, please refer to:
 postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html


 Reproducible: Always

 Steps to Reproduce:
 1. openssl s_client -connect some.ironport.com:25 -starttls smtp

 Note: Send me an email for a hostname of an Ironport SMTP appliance to test
 with. I don't want to disclose it here.
 Actual Results:  
 CONNECTED(0003)
 139718758192784:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
 decode error:s23_clnt.c:762:
 ---
 no peer certificate available
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 129 bytes and written 552 bytes
 ---
 New, (NONE), Cipher is (NONE)
 Secure Renegotiation IS NOT supported
 Compression: NONE
 Expansion: NONE
 ---


 Expected Results:  
 CONNECTED(0003)
 ---
 Certificate chain
 [...cut...]
 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 [...cut..-]
 250 STARTTLS

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
 .


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[John Foley]

I'm trying to get that information from the IronPort team.  In the mean
time, this bug report appears to have some details:

https://tools.cisco.com/bugsearch/bug/CSCuo25329


On 05/01/2014 12:26 PM, Viktor Dukhovni wrote:
 On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote:

 This is a known problem in the Ironport TLS stack.  Ironport has
 released a hot patch to address this problem.
 Any links to the fix?

 I'd like to post a link to the fix to the Postfix and Exim users
 lists, so that if anyone runs into the problem with a peer system,
 they can point the peer postmaster in the right direction.

 What versions of the product have the problem, and any idea what
 fraction of the install base is running those versions?  Is there
 likely any significant portion of the install base that can't or
 won't upgrade (best guess)?


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3059] TLS 1.2 CertificateRequests allows MD5

[John Foley]

Rather than dropping it from the list, another option would be to
re-prioritize the list.  Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions.  This would facilitate
backwards compatibility, while improving the security posture when
communicating with peers that support SHA-2 algorithms.

Some may argue that SHA1 should be near the end of the list as well. 



On 06/02/2013 02:11 PM, Kurt Roeckx via RT wrote:
 Hi,

 It seems that tls12_get_req_sig_algs() sends that MD5 is a
 supported signature algorithm, except in that case of FIPS.

 Would it make sense to drop MD5 from that list?


 Kurt

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


attachment: foleyj.vcf

Re: [openssl.org #3059] TLS 1.2 CertificateRequests allows MD5

[John Foley via RT]

Rather than dropping it from the list, another option would be to
re-prioritize the list.  Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions.  This would facilitate
backwards compatibility, while improving the security posture when
communicating with peers that support SHA-2 algorithms.

Some may argue that SHA1 should be near the end of the list as well. 



On 06/02/2013 02:11 PM, Kurt Roeckx via RT wrote:
 Hi,

 It seems that tls12_get_req_sig_algs() sends that MD5 is a
 supported signature algorithm, except in that case of FIPS.

 Would it make sense to drop MD5 from that list?


 Kurt

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org



inline: foleyj.vcf

[openssl.org #2859] Possible bug in AES GCM mode

[John Foley via RT]

This problem occurs in the FIPS 2.0 and 2.0.1 Object Modules.   The 
conditions for the test are:

Platform:  Linux 32-bit
AAD length:  greater than 16 bytes and not evenly divisible by 16 (e.g. 
20 bytes of AAD)
Cipher text length: 0

Under these conditions, the remaining AAD bytes beyond the last 16 byte 
block are never hashed.  This results in a TAG mismatch when finalizing 
the decrypt operation.  The problem can be easily reproduced by running 
the following command using the attached test vector file:

test/fips_gcmtest -decrypt gcm_decrypt_vect.req vector.rsp

The test case in this vector should result in a matching tag.

The attached patch is a potential fix.  The solution is to process the 
remainder AAD when CRYPTO_gcm128_finish() is invoked.  Please confirm 
that this is a bug and comment on the patch.  Specifically, will this 
patch work on all platforms?  Thank you.

Also, the OpenSSL test vectors for AES GCM mode only used AAD lengths 
that were divisible by 16, which explains why this problem was not 
identified during FIPS validation.

Index: crypto/modes/gcm128.c
===
--- crypto/modes/gcm128.c	(revision 713)
+++ crypto/modes/gcm128.c	(working copy)
@@ -1396,6 +1396,15 @@
 #ifdef GCM_FUNCREF_4BIT
 	void (*gcm_gmult_p)(u64 Xi[2],const u128 Htable[16])	= ctx-gmult;
 #endif
+	/*
+	 * Check if there is any residual AAD that needs to
+	 * be hashed.  This may occur if the amount of AAD
+	 * is not evenly divisible by 16 bytes 
+	 */
+	if (ctx-ares) {
+		GCM_MUL(ctx,Xi);
+		ctx-ares = 0;
+	}
 
 	if (ctx-mres)
 		GCM_MUL(ctx,Xi);
# CAVS 12.2
# GCM Decrypt with keysize 192 test information
# Generated on Mon Jul 30 13:55:03 2012

[Keylen = 192]
[IVlen = 96]
[PTlen = 0]
[AADlen = 160]
[Taglen = 128]

Count = 1
Key = cb9c9ba95ba34917db831e2f8438b5c9e702a1dfe2aa5451
IV = 1e19de9f8ec80fd940d07e4f
CT = 
AAD = 01d783d290c62d6c46d6adda205057e327029586
Tag = cade2680b5bb72d7a9ef8dc2388353f1

inline: foleyj.vcf

Re: [openssl.org #2859] Possible bug in AES GCM mode

[John Foley]

Thanks for confirming and providing the work-around.

Do you see any problems with the proposed patch, which could still be 
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?




On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:

[fol...@cisco.com - Fri Aug 03 10:51:37 2012]:

Under these conditions, the remaining AAD bytes beyond the last 16 byte
block are never hashed.  This results in a TAG mismatch when finalizing
the decrypt operation.  The problem can be easily reproduced by running
the following command using the attached test vector file:


I can confirm the results. There is an alternative which doesn't involve
any changes to the validated algorithm code though.

If you make a call to EVP_Cipher with non-NULL input and output buffers
and the length set to zero this case should then be handled correctly. I
made a small modification to fips_gcmtest.c to confirm this.

Steve.
attachment: foleyj.vcf

Re: [openssl.org #2859] Possible bug in AES GCM mode

[John Foley via RT]

Thanks for confirming and providing the work-around.

Do you see any problems with the proposed patch, which could still be 
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?



On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:
 [fol...@cisco.com - Fri Aug 03 10:51:37 2012]:

 Under these conditions, the remaining AAD bytes beyond the last 16 byte
 block are never hashed.  This results in a TAG mismatch when finalizing
 the decrypt operation.  The problem can be easily reproduced by running
 the following command using the attached test vector file:

 I can confirm the results. There is an alternative which doesn't involve
 any changes to the validated algorithm code though.

 If you make a call to EVP_Cipher with non-NULL input and output buffers
 and the length set to zero this case should then be handled correctly. I
 made a small modification to fips_gcmtest.c to confirm this.

 Steve.

inline: foleyj.vcf

EVP_aes_128_ccm() not in c_allc.c

[John Foley]

Looking at the 7/24 snapshot, is there a reason the AES CCM modes are 
omitted from OpenSSL_add_all_ciphers()?  Or is this simply an oversight?


Thank you.
attachment: foleyj.vcf

Re: FIPS Object Module 2.0 - Compliance with 186-3

[John Foley]

OK, thanks for clarifying this.


On 07/12/2012 02:53 PM, Steve Marquess wrote:

On 07/09/2012 03:55 PM, John Foley wrote:

According to the NIST web site, the 2.0 FIPS Object Module claims
compliance for FIPS 186-3 using the Extra Random Bits method for EC
public key generation.

The implementation is FIPS 186-3 Section B.4.2, Key Pair Generation by
Testing Candidates. The ExtraRandomBits reference is inaccurate.

-Steve M.

attachment: foleyj.vcf

Re: [openssl.org #2844] TLS 1.2 server sends abort when TLS 1.2 client doesn't include Signature Algorithm extension

[John Foley]

Confirmed.  The problem is resolved in the latest snapshot.  Thank you.



On 07/06/2012 04:57 PM, Stephen Henson via RT wrote:

[fol...@cisco.com - Fri Jul 06 17:50:15 2012]:

RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
extension.  See section 7.4.1.4.1 for details.  This creates a problem
for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA
certificate is used.  Because the ClientHello does not contain the
Signature Algorithm extension, tls1_process_sigalgs() is never invoked
on the server side to set the digest used for the session context.
Later during the handshake when the server sends the ServerKeyExchange,
the call to tls12_get_sigandhash() fails, which causes the server to
abort the handshake.

The attached patch to tls12_get_sigandhash() resolves the problem.
However, the OpenSSL maintainers may have a better solution.



Have you tried a recent 1.0.1 snapshot? I came across the same issue
when developing more configurable supported signature algorithms
support. The fix I made was:

http://cvs.openssl.org/chngview?cn=22655

Steve.
attachment: foleyj.vcf

Re: [openssl.org #2844] TLS 1.2 server sends abort when TLS 1.2 client doesn't include Signature Algorithm extension

[John Foley via RT]

Confirmed.  The problem is resolved in the latest snapshot.  Thank you.



On 07/06/2012 04:57 PM, Stephen Henson via RT wrote:
 [fol...@cisco.com - Fri Jul 06 17:50:15 2012]:

 RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
 extension.  See section 7.4.1.4.1 for details.  This creates a problem
 for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA
 certificate is used.  Because the ClientHello does not contain the
 Signature Algorithm extension, tls1_process_sigalgs() is never invoked
 on the server side to set the digest used for the session context.
 Later during the handshake when the server sends the ServerKeyExchange,
 the call to tls12_get_sigandhash() fails, which causes the server to
 abort the handshake.

 The attached patch to tls12_get_sigandhash() resolves the problem.
 However, the OpenSSL maintainers may have a better solution.


 Have you tried a recent 1.0.1 snapshot? I came across the same issue
 when developing more configurable supported signature algorithms
 support. The fix I made was:

 http://cvs.openssl.org/chngview?cn=22655

 Steve.

inline: foleyj.vcf

FIPS Object Module 2.0 - Compliance with 186-3

[John Foley]

According to the NIST web site, the 2.0 FIPS Object Module claims 
compliance for FIPS 186-3 using the Extra Random Bits method for EC 
public key generation.  This is taken from:


http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html#270

The extra random bits method is defined in FIPS 186-3 Appendix B.4.1.  
After inspecting EC_KEY_generate_key(), it's not clear how the 
requirements in appendix B.4.1 have been met.  The following code from 
EC_KEY_generate_key() appears to be used to generate a random number to 
be used as the private key.


do
if (!BN_rand_range(priv_key, order))
goto err;
while (BN_is_zero(priv_key));

Can someone explain how this complies with appendix B.4.1, which states 
an additional 64 bits of random data should be generated when deriving 
the key?


Thank you.


attachment: foleyj.vcf

[openssl.org #2844] TLS 1.2 server sends abort when TLS 1.2 client doesn't include Signature Algorithm extension

[John Foley via RT]

RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm 
extension.  See section 7.4.1.4.1 for details.  This creates a problem 
for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA 
certificate is used.  Because the ClientHello does not contain the 
Signature Algorithm extension, tls1_process_sigalgs() is never invoked 
on the server side to set the digest used for the session context.  
Later during the handshake when the server sends the ServerKeyExchange, 
the call to tls12_get_sigandhash() fails, which causes the server to 
abort the handshake.

The attached patch to tls12_get_sigandhash() resolves the problem.  
However, the OpenSSL maintainers may have a better solution.

Index: t1_lib.c
===
--- t1_lib.c	(revision 585)
+++ t1_lib.c	(working copy)
@@ -2830,6 +2830,20 @@
 		return 0;
 	md_id = tls12_find_id(EVP_MD_type(md), tls12_md,
 sizeof(tls12_md)/sizeof(tls12_lookup));
+
+	/*
+	 * There's a special case that we need to check.  If
+	 * the client didn't send a signature algorithm extension, which
+	 * is possible under RFC5246 guidelines, the above check to 
+	 * find the hash algorithm will fail if the server's cert is
+	 * either DSA or ECDSA.  In this case, we default to SHA1
+	 * as the hash algorithm
+	 */
+	if (md_id == -1  
+	(EVP_MD_type(md) == NID_ecdsa_with_SHA1 || 
+	 EVP_MD_type(md) == NID_dsa)) {
+	md_id = TLSEXT_hash_sha1;
+	}
 	if (md_id == -1)
 		return 0;
 	sig_id = tls12_get_sigid(pk);
inline: foleyj.vcf

AES performance when using FIPS 2.0 Object Module

[John Foley]

Is AES performance expected to be much lower when using the FIPS 2.0
Object Module?  Below are the speed results when using AES-128-CBC with
and w/o the FIPS module.  The host system is 32-bit Linux using gcc
4.4.3.  The host system does not have AES-NI support.  No additional
config arguments were used other than 'fipscanisteronly' for building
the FIPS module and 'fips' for building 1.0.1b. 


$ ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13734067 aes-128-cbc's in 2.98s
Doing aes-128-cbc for 3s on 64 size blocks: 4149906 aes-128-cbc's in 2.95s
Doing aes-128-cbc for 3s on 256 size blocks: 1084643 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 1024 size blocks: 278767 aes-128-cbc's in 2.98s
Doing aes-128-cbc for 3s on 8192 size blocks: 34952 aes-128-cbc's in 2.99s
OpenSSL 1.0.1b-fips 26 Apr 2012
built on: Fri May 11 08:04:08 EDT 2012
options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial)
idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -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
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192
bytes
aes-128-cbc  73739.96k90031.86k92865.76k95791.08k   
95761.47k


$ ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 36109363 aes-128-cbc's in 2.96s
Doing aes-128-cbc for 3s on 64 size blocks: 11241446 aes-128-cbc's in 2.97s
Doing aes-128-cbc for 3s on 256 size blocks: 2840087 aes-128-cbc's in 2.96s
Doing aes-128-cbc for 3s on 1024 size blocks: 706161 aes-128-cbc's in 2.97s
Doing aes-128-cbc for 3s on 8192 size blocks: 90698 aes-128-cbc's in 2.97s
OpenSSL 1.0.1b 26 Apr 2012
built on: Fri May 11 08:14:14 EDT 2012
options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial)
idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192
bytes
aes-128-cbc 195185.75k   242239.91k   245629.15k   243471.00k  
250167.68k

attachment: foleyj.vcf

Re: AES performance when using FIPS 2.0 Object Module

[John Foley]

Thanks for the information, that explains it.  The vpaes-x86 module
isn't included in the FIPS module. 

The CPU information is:

model name: Intel(R) Core(TM) i7 CPU   Q 720  @ 1.60GHz




On 05/11/2012 09:07 AM, Andy Polyakov wrote:
 Is AES performance expected to be much lower when using the FIPS 2.0
 Object Module?
 Which CPU? You said it's non-AES-NI-capable, but is it SSSE3-capable? If
 yes, then see related note at
 http://www.mail-archive.com/openssl-dev@openssl.org/msg29827.html.

 Below are the speed results when using AES-128-CBC with
 and w/o the FIPS module. The host system is 32-bit Linux using gcc
 4.4.3.  The host system does not have AES-NI support.  No additional
 config arguments were used other than 'fipscanisteronly' for building
 the FIPS module and 'fips' for building 1.0.1b. 

 $ ./openssl speed -evp aes-128-cbc
 OpenSSL 1.0.1b-fips 26 Apr 2012
 type 16 bytes 64 bytes256 bytes   1024 bytes   8192
 bytes
 aes-128-cbc  73739.96k90031.86k92865.76k95791.08k   
 95761.47k

 $ ./openssl speed -evp aes-128-cbc
 OpenSSL 1.0.1b 26 Apr 2012
 compiler: gcc ... -DVPAES_ASM ...
 type 16 bytes 64 bytes256 bytes   1024 bytes   8192
 bytes
 aes-128-cbc 195185.75k   242239.91k   245629.15k   243471.00k  
 250167.68k
 Ratio suggests that it's Nehalem core...
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

attachment: foleyj.vcf

[openssl.org #2767] test/testssl script does not exercise TLS 1.2

[John Foley via RT]

In version 1.0.1, the TLS unit test script does not invoke any of the
TLS 1.2 methods. 

The attached patch resolves this problem by adding support for the
-tls1_2 option to ssl/ssltest.c.  The test/testssl script is also
modified to utilize this new option.

Index: ssl/ssltest.c
===
--- ssl/ssltest.c	(revision 352)
+++ ssl/ssltest.c	(working copy)
@@ -350,6 +350,7 @@
 #endif
 #ifndef OPENSSL_NO_TLS1
 	fprintf(stderr, -tls1 - use TLSv1\n);
+	fprintf(stderr, -tls1_2   - use TLSv1.2\n);
 #endif
 	fprintf(stderr, -CApath arg   - PEM format directory of CA's\n);
 	fprintf(stderr, -CAfile arg   - PEM format file of CA's\n);
@@ -504,7 +505,7 @@
 	int badop=0;
 	int bio_pair=0;
 	int force=0;
-	int tls1=0,ssl2=0,ssl3=0,ret=1;
+	int tls12=0,tls1=0,ssl2=0,ssl3=0,ret=1;
 	int client_auth=0;
 	int server_auth=0,i;
 	struct app_verify_arg app_verify_arg =
@@ -661,6 +662,8 @@
 			ssl2=1;
 		else if	(strcmp(*argv,-tls1) == 0)
 			tls1=1;
+		else if	(strcmp(*argv,-tls1_2) == 0)
+			tls12=1;
 		else if	(strcmp(*argv,-ssl3) == 0)
 			ssl3=1;
 		else if	(strncmp(*argv,-num,4) == 0)
@@ -794,7 +797,7 @@
 		{
 		fprintf(stderr, This case cannot work.  Use -f to perform 
 			the test anyway (and\n-d to see what happens), 
-			or add one of -ssl2, -ssl3, -tls1, -reuse\n
+			or add one of -ssl2, -ssl3, -tls1, -tls1_2, -reuse\n
 			to avoid protocol mismatch.\n);
 		EXIT(1);
 		}
@@ -874,6 +877,9 @@
 	else 
 	if (tls1)
 		meth=TLSv1_method();
+	else 
+	if (tls12)
+		meth=TLSv1_2_method();
 	else
 	if (ssl3)
 		meth=SSLv3_method();
Index: test/testssl
===
--- test/testssl	(revision 352)
+++ test/testssl	(working copy)
@@ -158,4 +158,31 @@
   $ssltest -bio_pair -tls1 -cipher SRP -srpuser test -srppass abc123
 fi
 
+if ../util/shlib_wrap.sh ../apps/openssl no-dh; then
+  echo skipping anonymous DH tests
+else
+  echo test tls1.2 with 1024bit anonymous DH, multiple handshakes
+  $ssltest -v -bio_pair -tls1_2 -cipher ADH -dhe1024dsa -num 10 -f -time $extra || exit 1
+fi
+
+if ../util/shlib_wrap.sh ../apps/openssl no-rsa; then
+  echo skipping RSA tests
+else
+  echo 'test tls1.2 with 1024bit RSA, no (EC)DHE, multiple handshakes'
+  ../util/shlib_wrap.sh ./ssltest -v -bio_pair -tls1_2 -cert ../apps/server2.pem -no_dhe -no_ecdhe -num 10 -f -time $extra || exit 1
+
+  if ../util/shlib_wrap.sh ../apps/openssl no-dh; then
+echo skipping RSA+DHE tests
+  else
+echo test tls1.2 with 1024bit RSA, 1024bit DHE, multiple handshakes
+../util/shlib_wrap.sh ./ssltest -v -bio_pair -tls1_2 -cert ../apps/server2.pem -dhe1024dsa -num 10 -f -time $extra || exit 1
+  fi
+fi
+
+echo test tls1.2 with PSK
+$ssltest -tls1_2 -cipher PSK -psk abc123 $extra || exit 1
+
+echo test tls1.2 with PSK via BIO pair
+$ssltest -bio_pair -tls1_2 -cipher PSK -psk abc123 $extra || exit 1
+
 exit 0
inline: foleyj.vcf

Re: intel-accel library under hypervisor

[John Foley]

Based on the results, it looks like you're using AES-NI in both cases. 
Try running this command to avoid using AES-NI:

openssl speed aes-128-cbc



On 02/24/2012 12:27 PM, no_spam...@yahoo.com wrote:
 Hello.

 I am running CentOS 6.2 (i386) under VMware vSphere Hypervisor 5 on a box 
 with a Westmere CPU.

 I downloaded the intel-accel-1.4.tar.gz package from 
 http://www.openssl.org/contrib, built it following the instructions in 
 README, and tested it using the command provided in README.  However, I don't 
 see any improvement in AES performance:

 [root@george intel-accel-1.4]# uname -a
 Linux george.blah.blah 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011 
 i686 i686 i386 GNU/Linux

 [root@george intel-accel-1.4]# cat /proc/cpuinfo
 processor   : 0
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 44
 model name  : Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz
 stepping: 2
 cpu MHz : 2394.000
 cache size  : 12288 KB
 fdiv_bug: no
 hlt_bug : no
 f00f_bug: no
 coma_bug: no
 fpu : yes
 fpu_exception   : yes
 cpuid level : 11
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
 cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx rdtscp lm 
 constant_tsc up arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc 
 aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes 
 hypervisor lahf_lm ida arat epb dts
 bogomips: 4788.00
 clflush size: 64
 cache_alignment : 64
 address sizes   : 40 bits physical, 48 bits virtual
 power management:

 [root@george intel-accel-1.4]# openssl speed -evp aes128
 Doing aes-128-cbc for 3s on 16 size blocks: 77112823 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 64 size blocks: 26704648 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 256 size blocks: 7398544 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 1024 size blocks: 1899187 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 8192 size blocks: 237908 aes-128-cbc's in 3.00s
 OpenSSL 1.0.0-fips 29 Mar 2010
 built on: Wed Jan 25 02:09:30 GMT 2012
 options:bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) 
 blowfish(idx)
 compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
 -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe 
 -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
 --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
 -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM
 The 'numbers' are in 1000s of bytes per second processed.
 type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
 aes-128-cbc 411268.39k   569699.16k   631342.42k   648255.83k   649647.45k

 [root@george intel-accel-1.4]# env OPENSSL_ENGINES=`pwd` openssl speed -evp 
 aes128 -engine intel-accel
 engine intel-accel set.
 Doing aes-128-cbc for 3s on 16 size blocks: 80486271 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 64 size blocks: 27054163 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 256 size blocks: 7411894 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 1024 size blocks: 1878776 aes-128-cbc's in 3.00s
 Doing aes-128-cbc for 3s on 8192 size blocks: 237097 aes-128-cbc's in 3.00s
 OpenSSL 1.0.0-fips 29 Mar 2010
 built on: Wed Jan 25 02:09:30 GMT 2012
 options:bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) 
 blowfish(idx)
 compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
 -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe 
 -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
 --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
 -fasynchronous-unwind-tables -Wa,--noexecstack -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM
 The 'numbers' are in 1000s of bytes per second processed.
 type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
 aes-128-cbc 429260.11k   577155.48k   632481.62k   641288.87k   647432.87k
 [root@george intel-accel-1.4]#

 I must be doing something obvious wrong, but I'm not sure what.  Any ideas?


 Thanks.

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

attachment: foleyj.vcf

Re: FIPS self-tests failing on Windows

[John Foley]

Is this Windows 7?  Try adding the FIXED flag to the Microsoft linker. 
Windows 7 will relocate DLLs (quite often).  When this occurs, the FIPS
signature will fail.


On 09/06/2011 04:22 PM, Dr. Stephen Henson wrote:
 On Tue, Sep 06, 2011, Tyrel Haveman wrote:

 It looks like there's a failure in the FIPS module 2.0 self tests on Windows
 currently. It happens on both x86 and AMD64. The failure is in the integrity
 check. Complete output of fips_test_suite.exe is below.

 FIPS-mode test application
 FIPS 2.0-dev unvalidated test module xx XXX 

 1. Non-Approved cryptographic operation test...
 a. Included algorithm (D-H)..successful
 POST started
 Integrity  test started
 ERROR:2D06B06F:lib=45,func=107,reason=111:file=.\fips\fips.c:line=224
 Integrity  test FAILED!!
 DRBG AES-256-CTR DF test started
 DRBG AES-256-CTR DF test OK
 DRBG AES-256-CTR test started
 DRBG AES-256-CTR test OK
 DRBG SHA256 test started
 DRBG SHA256 test OK
 DRBG HMAC-SHA256 test started
 DRBG HMAC-SHA256 test OK
 X9.31 PRNG keylen=16 test started
 X9.31 PRNG keylen=16 test OK
 X9.31 PRNG keylen=24 test started
 X9.31 PRNG keylen=24 test OK
 X9.31 PRNG keylen=32 test started
 X9.31 PRNG keylen=32 test OK
 Digest SHA1 test started
 Digest SHA1 test OK
 Digest SHA1 test started
 Digest SHA1 test OK
 Digest SHA1 test started
 Digest SHA1 test OK
 HMAC SHA1 test started
 HMAC SHA1 test OK
 HMAC SHA224 test started
 HMAC SHA224 test OK
 HMAC SHA256 test started
 HMAC SHA256 test OK
 HMAC SHA384 test started
 HMAC SHA384 test OK
 HMAC SHA512 test started
 HMAC SHA512 test OK
 CMAC AES-128-CBC test started
 CMAC AES-128-CBC test OK
 CMAC AES-192-CBC test started
 CMAC AES-192-CBC test OK
 CMAC AES-256-CBC test started
 CMAC AES-256-CBC test OK
 CMAC DES-EDE3-CBC test started
 CMAC DES-EDE3-CBC test OK
 Cipher AES-128-ECB test started
 Cipher AES-128-ECB test OK
 CCM  test started
 CCM  test OK
 GCM  test started
 GCM  test OK
 XTS AES-128-XTS test started
 XTS AES-128-XTS test OK
 XTS AES-256-XTS test started
 XTS AES-256-XTS test OK
 Cipher DES-EDE3-ECB test started
 Cipher DES-EDE3-ECB test OK
 Cipher DES-EDE3-ECB test started
 Cipher DES-EDE3-ECB test OK
 Signature RSA test started
 Signature RSA test OK
 Signature ECDSA test started
 Signature ECDSA test OK
 Signature ECDSA test started
 Signature ECDSA test OK
 Signature DSA test started
 Signature DSA test OK
 POST Failed
 2. Automatic power-up self test...Failed!
 *** Tests Failed ***
 Strange. No problems on either platform here.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Fwd: New Timing Attack on OpenSSL ECDSA

[John Foley]

David,

Would your ECDSA implementation be subject to the following timing attack?


 Original Message 
Subject:New Timing Attack on OpenSSL ECDSA
Date:   Wed, 25 May 2011 15:59:58 +0200
From:   Mounir IDRASSI mounir.idra...@idrix.net
Reply-To:   openssl-dev@openssl.org
Organization:   IDRIX
To: openssl-dev@openssl.org



Hi all,

Is there any plan for implementing counter measures against the newly 
discovered vulnerability in ECDSA operations of OpenSSL?
For those not aware of it, here is the US-CERT link of this 
vulnerability : http://www.kb.cert.org/vuls/id/536044
Here is also the original paper that contains the vulnerability details 
: http://eprint.iacr.org/2011/232.pdf

The patch suggested by the paper seems simple enough. It can be enhanced 
by adding a random multiple of the order to the scalar k. Is there any 
objection for getting this merged into OpenSSL source?

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl 1.0.1 and FIPS

[John Foley]

Steve,

It looks like the FIPS 2.0 code has been going into HEAD.  When do you
plan to pull a branch for the FIPS Object Model 2.0?



On 05/13/2011 12:24 PM, Steve Marquess wrote:
  What is happening?

 

  No Fips in the Openssl 1.0.1 STABLe.

 

 

 Correct, and you won't be seeing the FIPS capable support there for
 some time.  We're concentrating on the validation of the module
 (OpenSSL FIPS Object Module 2.0) now.

 -Steve M.

 -- 
 Steve Marquess
 OpenSSL Software Foundation, Inc.
 1829 Mount Ephraim Road
 Adamstown, MD  21710
 USA
 +1 877-673-6775
 marqu...@opensslfoundation.com

Re: openssl 1.0.1 and FIPS

[John Foley]

OK, I'm still a bit confused on the version labeling.  Is it safe to
assume the next stable label pulled off HEAD (e.g. 1.0.2) will include
support for make -f Makefile.fips dist.  Or to put the question
another way, what stable label should be used to generate the FIPS
Object Model 2.0 source code?



On 05/13/2011 12:50 PM, Steve Marquess wrote:
 Steve,

 It looks like the FIPS 2.0 code has been going into HEAD.  When do you
 plan to pull a branch for the FIPS Object Model 2.0?
 We don't.  The source tarball for the eventual validated module will be
 generated with make -f Makefile.fips dist which extracts the relevant
 subset of code.  Note we have begun posting FIPS module snapshots at
 ftp://ftp.openssl.org/snapshot/.

 -Steve M.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

TLS 1.2 support

[John Foley]

It looks like TLS 1.2 is being implemented in recent commits.  Is there
an anticipated completion date for when v1.2 will be fully implemented?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org