[openssl-dev] Patch for iOS compilation failure on Xcode 9 / iOS 11 SDK

[Chris Ballinger via openssl-dev]

"-fomit-frame-pointer" is no longer allowed for armv7 targets, so I removed
it from the iphoneos-cross configure target. I noticed this
on openssl-1.0.2l.
--- Configure.orig  2017-05-25 05:54:38.0 -0700
+++ Configure   2017-09-29 12:09:45.0 -0700
@@ -652,7 +652,7 @@
 "debug-darwin64-x86_64-cc","cc:-arch x86_64 -ggdb -g2 -O0 -DL_ENDIAN 
-Wall::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:SIXTY_FOUR_BIT_LONG 
RC4_CHUNK DES_INT DES_UNROLL:".eval{my 
$asm=$x86_64_asm;$asm=~s/rc4\-[^:]+//;$asm}.":macosx:dlfcn:darwin-shared:-fPIC 
-fno-common:-arch x86_64 -dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 "debug-darwin-ppc-cc","cc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DCRYPTO_MDEBUG 
-DB_ENDIAN -g -Wall -O::-D_REENTRANT:MACOSX::BN_LLONG RC4_CHAR RC4_CHUNK 
DES_UNROLL 
BF_PTR:${ppc32_asm}:osx32:dlfcn:darwin-shared:-fPIC:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 # iPhoneOS/iOS
-"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) 
-fomit-frame-pointer 
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR 
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC 
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
+"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) 
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR 
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC 
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 
 # A/UX
 "aux3-gcc","gcc:-O2 -DTERMIO::(unknown):AUX:-lbsd:RC4_CHAR RC4_CHUNK 
DES_UNROLL BF_PTR:::",
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] Some DJGPP specific fixes and improvements for OpenSSL_1_0_2-stable.

[Juan Manuel Guerrero]

I do not know if patches for DJGPP/FreeDOS are still welcome at all for the
OpenSSL 1.0.2 branch but if yes, then I would like to propose some fixes and
improvements.  No one of the proposed changes have impact on any other port.
The patch is based on openssl-1.0.2-stable-SNAP-20170602.  Concerning its
functionality, the patch is identical to the one proposed some months ago for
the openssl-1.1.0 branch and that has found its way into that branch.

The patch will fix/improve the following issues:
1) In Configure:
 For some reason -DTERMIO is set but DJGPP has never offered TERMIO making
 the build fail.  I have changed this to -DTERMIOS as is used to be.
2) In crypto/bio/bss_dgram.c:
 I have removed superfluous macro definitions of sock_write, sock_read and
 sock_puts enclosed by WATT32.
3) In crypto/bio/bss_sock.c:
 Here the existing macro definitions for sock_write, sock_read and sock_puts
 are necessary and must be kept but they must be undefined before they can
 be defined.  This is because newer versions of Watt-32 also redefine them.
4) In crypto/conf/conf_def.c:
 If this port is used on MS-DOS or FreeDOS it becomes necessary to check if
 the underlying file system supports long file names (aka LFN) or not.  If
 it does not then file names with a leading dot like ".rnd" or ".ca_certs"
 are ilicit.  In function def_load_bio, the macros IS_RANDFILE and 
IS_CERT_DIR
 are used to check if the file system offers LFN support so that the file
 names with leading dots are licit.  If the tests fail then the new function
 dosify_filename is called and will substitute invalid characters in the 
file
 name by valid ones before using them.  This check and the call of 
dosify_filename
 is enclosed by OPENSSL_SYS_MSDOS.
5) In e_os.h:
 In the DJGPP section the macros IS_RANDFILE and IS_CERT_DIR are defined.
 Also some auxiliar macros like HAS_LFN_SUPPORT and FILE_EXISTS are defined.
 Because neither MS-DOS nor FreeDOS provide 'egd' sockets, the DEVRANDOM_EGD
 macro is undefined.  This shall inhibit the compilation of code that does
 not work on MS-DOS/FreeDOS.
6) In util/mklink.pl:
 Neither MS-DOS nor FreeDOS provide symlink support so copy files instead.
7) In INSTALL.DJGPP:
 Update URL of WATT-32 library.


I have checked the modified version of OpenSSL_1_0_2-stable on linux and Cygwin.
They are no issues.  This is no surprise because the changes are either guarded
by the __DJGPP__ or OPENSSL_SYS_MSDOS macros.
If more informaton is required please mail me.  Just in case it is required, I
have attached the patch as gzip'ed files too.


Regards,
Juan M. Guerrero





diff -aprNU5 openssl-1.0.2-stable-SNAP-20170602.orig/Configure 
openssl-1.0.2-stable-SNAP-20170602/Configure
--- openssl-1.0.2-stable-SNAP-20170602.orig/Configure   2017-06-01 20:51:32 
+
+++ openssl-1.0.2-stable-SNAP-20170602/Configure2017-06-03 19:41:20 
+
@@ -632,11 +632,11 @@ my %table=(
 "netware-libc-bsdsock", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
 "netware-libc-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include 
-I/ndk/libc/include/winsock -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE -DTERMIO -O2 
-Wall:BN_LLONG ${x86_gcc_opts}::",
 "netware-libc-bsdsock-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include 
-DNETWARE_BSDSOCK -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE -DTERMIO -O2 
-Wall:BN_LLONG ${x86_gcc_opts}::",

 # DJGPP
-"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 
-Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${x86_asm}:a.out:",
+"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer 
-O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${x86_asm}:a.out:",

 # Ultrix from Bernhard Simon 
 "ultrix-cc","cc:-std1 -O -Olimit 2500 -DL_ENDIAN::(unknown):::",
 "ultrix-gcc","gcc:-O3 -DL_ENDIAN::(unknown):::BN_LLONG",
 # K C is no longer supported; you need gcc on old Ultrix installations
@@ -1532,10 +1532,27 @@ if ($sys_id ne "")
 if ($ranlib eq "")
{
$ranlib = $default_ranlib;
}

+# DJGPP specific CFLAG adjustments
+if ($target =~ /^DJGPP/)
+   {
+   my $gccver=0;
+   if (open(FD,"$cc --version |"))
+   {
+   while() { $gccver=$1 if (/ 
(([1-3])\.|4\.([0-1])([.0-9]*))/); }
+   close(FD);
+   }
+   if ($gccver==0)
+   {
+   # For gcc 4.3.0 and above ensure that always old GNU extern 
inline semantics
+   # are used (aka -fgnu89-inline) even if ISO C99 semantics has 
been specified.
+   $cflags=~s/-fomit-frame-pointer/-fgnu89-inline 
-fomit-frame-pointer/;
+   }
+   }
+
 #my ($bn1)=split(/\s+/,$bn_obj);
 #$bn1 = "" unless defined $bn1;
 #$bn1=$bn_asm unless ($bn1 =~ /\.o$/);
 

Re: [openssl-dev] [PATCH] Missing NULLs in ssl_cipher_methods init

[Salz, Rich]

> The number of NULLS in the initialization of ssl_cipher_methods in
> ssl/ssl_ciph.c does not match the count SSL_ENC_NUM_IDX in 1.1.0c.

A better fix is to remove all the initializers and just count on C's "init to 
NULL" guarantee.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] Missing NULLs in ssl_cipher_methods init

[Leonard den Ottolander]

Hello,

The number of NULLS in the initialization of ssl_cipher_methods in
ssl/ssl_ciph.c does not match the count SSL_ENC_NUM_IDX in 1.1.0c.

Attached patch for a fix.

Regards,
Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

--- openssl-1.1.0c/ssl/ssl_ciph.c.000	2016-11-10 15:03:46.0 +0100
+++ openssl-1.1.0c/ssl/ssl_ciph.c	2017-01-08 16:28:41.710219565 +0100
@@ -103,7 +103,7 @@ static const ssl_cipher_table ssl_cipher
 
 static const EVP_CIPHER *ssl_cipher_methods[SSL_ENC_NUM_IDX] = {
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-NULL, NULL
+NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
 };
 
 #define SSL_COMP_NULL_IDX   0
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Salz, Rich]

> There were two requests: the bylaws and whether modified grant would be
> acceptable.  If, instead of an unrestricted grant in the CLA it were 
> restricted
> to relicensing to an OSI approved licence, the need to do due diligence on
> the foundation goes away.

We're not interested in changing the CLA at this time.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Richard Levitte]

In message <1483487075.2464.59.ca...@hansenpartnership.com> on Tue, 03 Jan 2017 
15:44:35 -0800, James Bottomley  said:

James.Bottomley> On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote:
James.Bottomley> > ⁣There seems to be some confusion here. 
James.Bottomley> > 
James.Bottomley> > James, I understand the tpm engine as an external project, 
not part
James.Bottomley> > of the OpenSSL source proper and not intended to be. 
James.Bottomley> > 
James.Bottomley> > However, openssl-dev@openssl.org is a list focused on the 
development
James.Bottomley> > of OpenSSL proper. That makes it a bit odd to discuss the 
tpm engine
James.Bottomley> > here. Largely off topic. 
James.Bottomley> 
James.Bottomley> Fair enough.  You were cc'd since it's a modification of code 
used by
James.Bottomley> openSSL, in case there was interest.

Strictly speaking, that belongs in openssl-us...@openssl.org.

The reason I point this out is that for code that isn't meant to be
part of OpenSSL proper, the whole discussion about CLAs, licenses and
whatnot is a red herring that belongs neither here not there.  As long
as you do stuff as a separate project, YOU (collective you) decide
what license to use, let alone your contribution policy.

Of course, I do recall that there was an attempt of patches to be
applied to OpenSSL proper.  That alone is subject to our license and
our policies, if that's still interesting (I don't know if it is).  If
it is, that should be contributed as a separate patch, preferably as a
github PR (sourceforge is entirely uninteresting to us).

Me, I haven't really minded the discussion here, as long as it didn't
become confusing.  After all, it did spark some discussion around my
STORE project ;-)

Did I leave something out or is the situation clear?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Wed, 2017-01-04 at 00:04 +, Matt Caswell wrote:
> 
> On 03/01/17 12:44, Salz, Rich wrote:
> > > > I'm still waiting on a reply ... I assume holidays are
> > > > contributing to the delay.
> > > > However, openssl_tpm_engine is a DCO project, so that concern
> > > > is
> > > > irrelevant here.
> > > 
> > > Sorry, I'll push to get the bylaws made public, is that what you
> > > need?
> > 
> > The OSF bylaws are now linked to from 
> > https://www.openssl.org/policies/
> 
> I can't actually see this link...am I just missing it, or did you not 
> push?


https://www.openssl.org/policies/osf-bylaws.pdf

Thanks for doing this!

James

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Matt Caswell]

On 03/01/17 12:44, Salz, Rich wrote:
>>> I'm still waiting on a reply ... I assume holidays are contributing to the 
>>> delay.
>>> However, openssl_tpm_engine is a DCO project, so that concern is
>>> irrelevant here.
>>
>> Sorry, I'll push to get the bylaws made public, is that what you need?
> 
> The OSF bylaws are now linked to from https://www.openssl.org/policies/

I can't actually see this link...am I just missing it, or did you not push?

Matt

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote:
> ⁣There seems to be some confusion here. 
> 
> James, I understand the tpm engine as an external project, not part
> of the OpenSSL source proper and not intended to be. 
> 
> However, openssl-dev@openssl.org is a list focused on the development
> of OpenSSL proper. That makes it a bit odd to discuss the tpm engine
> here. Largely off topic. 

Fair enough.  You were cc'd since it's a modification of code used by
openSSL, in case there was interest.

James


> Cheers 
> Richard 
> 
> Skickat från BlueMail 
> 
> Den 2 jan. 2017 19:22, kI 19:22, "Salz, Rich" 
> skrev:
> > > Really, how?  By pull request, you mean one against the openssl
> > github
> > > account so people subscribing to that account see it, I presume? 
> > >  For
> > that to
> > > happen, the tree the patch is against must actually exist within
> > > the
> > account,
> > > which this one doesn't.
> > 
> > You clone the openssl git repo, create your own branch off master,
> > apply the diffs you are mailing to the list, and commit/push and
> > then
> > make a PR.  Yes it's a bit of work for you.  But it then becomes
> > near-zero work for anyone on openssl to look at it.
> > 
> > > This patch is mostly FYI, so yes, I do given that multiple
> > > mailing
> > lists have
> > > some interest.
> > 
> > It's all about trade-offs.  Multiple people have said multiple
> > times
> > that PR's are the best way to work with OpenSSL.  If those other
> > groups, individually or collectively, are higher on your priority
> > list,
> > that's fine.  But do understand what's going on.
> > 
> > > I'm still waiting on a reply ... I assume holidays are
> > > contributing
> > to the delay.
> > > However, openssl_tpm_engine is a DCO project, so that concern is
> > irrelevant
> > > here.
> > 
> > Sorry, I'll push to get the bylaws made public, is that what you
> > need?
> > 
> > And no, it's not irrelevant.  If this is ever going to appear in
> > OpenSSL, a CLA must be signed.
> > 
> > -- 
> > 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] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Mon, 2017-01-02 at 18:22 +, Salz, Rich wrote:
> > I'm still waiting on a reply ... I assume holidays are contributing 
> > to the delay. However, openssl_tpm_engine is a DCO project, so that 
> > concern is irrelevant here.
> 
> Sorry, I'll push to get the bylaws made public, is that what you
> need?

There were two requests: the bylaws and whether modified grant would be
acceptable.  If, instead of an unrestricted grant in the CLA it were
restricted to relicensing to an OSI approved licence, the need to do
due diligence on the foundation goes away.

> And no, it's not irrelevant.  If this is ever going to appear in
> OpenSSL, a CLA must be signed.

It's not actually my code: I'm just updating it, so I'm unable to say
what the long term plan actually is.  I would think, though, that
hardware engines, since they're highly OS support dependent, would be
difficult to keep within openssl itself given that you want to compile
on multiple platforms.

James

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Salz, Rich]

> > I'm still waiting on a reply ... I assume holidays are contributing to the 
> > delay.
> > However, openssl_tpm_engine is a DCO project, so that concern is
> > irrelevant here.
> 
> Sorry, I'll push to get the bylaws made public, is that what you need?

The OSF bylaws are now linked to from https://www.openssl.org/policies/ or 
available directly at https://www.openssl.org/policies/osf-bylaws.pdf 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Richard Levitte]

⁣There seems to be some confusion here. 

James, I understand the tpm engine as an external project, not part of the 
OpenSSL source proper and not intended to be. 

However, openssl-dev@openssl.org is a list focused on the development of 
OpenSSL proper. That makes it a bit odd to discuss the tpm engine here. Largely 
off topic. 

Cheers 
Richard 

Skickat från BlueMail ​

Den 2 jan. 2017 19:22, kI 19:22, "Salz, Rich"  skrev:
>> Really, how?  By pull request, you mean one against the openssl
>github
>> account so people subscribing to that account see it, I presume?  For
>that to
>> happen, the tree the patch is against must actually exist within the
>account,
>> which this one doesn't.
>
>You clone the openssl git repo, create your own branch off master,
>apply the diffs you are mailing to the list, and commit/push and then
>make a PR.  Yes it's a bit of work for you.  But it then becomes
>near-zero work for anyone on openssl to look at it.
>
>> This patch is mostly FYI, so yes, I do given that multiple mailing
>lists have
>> some interest.
>
>It's all about trade-offs.  Multiple people have said multiple times
>that PR's are the best way to work with OpenSSL.  If those other
>groups, individually or collectively, are higher on your priority list,
>that's fine.  But do understand what's going on.
>
>> I'm still waiting on a reply ... I assume holidays are contributing
>to the delay.
>> However, openssl_tpm_engine is a DCO project, so that concern is
>irrelevant
>> here.
>
>Sorry, I'll push to get the bylaws made public, is that what you need?
>
>And no, it's not irrelevant.  If this is ever going to appear in
>OpenSSL, a CLA must be signed.
>
>-- 
>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] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Kurt Roeckx]

On Mon, Jan 02, 2017 at 08:50:24AM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote:
> > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > > This patch adds RSA signing for TPM2 keys.  There's a limitation to 
> > > the way TPM2 does signing: it must recognise the OID for the 
> > > signature.  That fails for the MD5-SHA1 signatures of the TLS/SSL 
> > > certificate verification protocol, so I'm using RSA_Decrypt for 
> > > both signing (encryption) and decryption ... meaning that this only 
> > > works with TPM decryption keys.  It is possible to use the prior 
> > > code, which preserved the distinction of signing and decryption 
> > > keys, but only at the expense of not being able to support SSL or
> > > TLS lower than 1.2
> > 
> > Please submit patches via github.
> 
> Um, that's not really possible given that openssl_tpm_engine is a
> sourceforge project.

I obviously didn't look at it and assumed it was for openssl, not
some other project.


Kurt

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Salz, Rich]

> Really, how?  By pull request, you mean one against the openssl github
> account so people subscribing to that account see it, I presume?  For that to
> happen, the tree the patch is against must actually exist within the account,
> which this one doesn't.

You clone the openssl git repo, create your own branch off master, apply the 
diffs you are mailing to the list, and commit/push and then make a PR.  Yes 
it's a bit of work for you.  But it then becomes near-zero work for anyone on 
openssl to look at it.

> This patch is mostly FYI, so yes, I do given that multiple mailing lists have
> some interest.

It's all about trade-offs.  Multiple people have said multiple times that PR's 
are the best way to work with OpenSSL.  If those other groups, individually or 
collectively, are higher on your priority list, that's fine.  But do understand 
what's going on.

> I'm still waiting on a reply ... I assume holidays are contributing to the 
> delay.
> However, openssl_tpm_engine is a DCO project, so that concern is irrelevant
> here.

Sorry, I'll push to get the bylaws made public, is that what you need?

And no, it's not irrelevant.  If this is ever going to appear in OpenSSL, a CLA 
must be signed.

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Mon, 2017-01-02 at 17:53 +, Salz, Rich wrote:
> > Um, that's not really possible given that openssl_tpm_engine is a
> > sourceforge project.
> 
> Sure it is.

Really, how?  By pull request, you mean one against the openssl github
account so people subscribing to that account see it, I presume?  For
that to happen, the tree the patch is against must actually exist
within the account, which this one doesn't.

>   You just find it easier to email patches. 

This patch is mostly FYI, so yes, I do given that multiple mailing
lists have some interest.

>  This is now the second time you’ve been asked.
> 
> And also, you had concerns about the CLA before.  Have they been
> resolved?  If not you should probably stop.

I'm still waiting on a reply ... I assume holidays are contributing to
the delay.  However, openssl_tpm_engine is a DCO project, so that
concern is irrelevant here.

James

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Salz, Rich]

> Um, that's not really possible given that openssl_tpm_engine is a
> sourceforge project.

Sure it is.  You just find it easier to email patches.  This is now the second 
time you’ve been asked.

And also, you had concerns about the CLA before.  Have they been resolved?  If 
not you should probably stop.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote:
> On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > This patch adds RSA signing for TPM2 keys.  There's a limitation to 
> > the way TPM2 does signing: it must recognise the OID for the 
> > signature.  That fails for the MD5-SHA1 signatures of the TLS/SSL 
> > certificate verification protocol, so I'm using RSA_Decrypt for 
> > both signing (encryption) and decryption ... meaning that this only 
> > works with TPM decryption keys.  It is possible to use the prior 
> > code, which preserved the distinction of signing and decryption 
> > keys, but only at the expense of not being able to support SSL or
> > TLS lower than 1.2
> 
> Please submit patches via github.

Um, that's not really possible given that openssl_tpm_engine is a
sourceforge project.

James


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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Kurt Roeckx]

On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> This patch adds RSA signing for TPM2 keys.  There's a limitation to the
> way TPM2 does signing: it must recognise the OID for the signature. 
>  That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
> verification protocol, so I'm using RSA_Decrypt for both signing
> (encryption) and decryption ... meaning that this only works with TPM
> decryption keys.  It is possible to use the prior code, which preserved
> the distinction of signing and decryption keys, but only at the expense
> of not being able to support SSL or TLS lower than 1.2

Please submit patches via github.


Kurt

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

[openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

This patch adds RSA signing for TPM2 keys.  There's a limitation to the
way TPM2 does signing: it must recognise the OID for the signature. 
 That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
verification protocol, so I'm using RSA_Decrypt for both signing
(encryption) and decryption ... meaning that this only works with TPM
decryption keys.  It is possible to use the prior code, which preserved
the distinction of signing and decryption keys, but only at the expense
of not being able to support SSL or TLS lower than 1.2

Signed-off-by: James Bottomley 

---
v2: - use TPM2_RSA_Decrypt for both decryption and signing operations
- Add authority processing
- Add TPM internal key creation
- allow persistent parents
- update to use transient connections to the TPM
---
 Makefile.am   |  12 +-
 create_tpm2_key.c | 451 +++
 e_tpm2.c  | 559 ++
 tpm2-asn.h|  59 ++
 tpm2-common.c | 175 +
 tpm2-common.h |  10 +
 6 files changed, 1264 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

diff --git a/Makefile.am b/Makefile.am
index 6695656..fb4f529 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,12 +2,20 @@ SUBDIRS=. test
 
 EXTRA_DIST = README  openssl.cnf.sample
 
-openssl_engine_LTLIBRARIES=libtpm.la
-bin_PROGRAMS=create_tpm_key
+openssl_engine_LTLIBRARIES=libtpm.la libtpm2.la
+bin_PROGRAMS=create_tpm_key create_tpm2_key
 openssl_enginedir=@libdir@/openssl/engines
 
 libtpm_la_LIBADD=-lcrypto -lc -ltspi
 libtpm_la_SOURCES=e_tpm.c e_tpm.h e_tpm_err.c
 
+libtpm2_la_LIBADD=-lcrypto -lc -ltss
+libtpm2_la_SOURCES=e_tpm2.c tpm2-common.c
+libtpm2_la_CFLAGS=-g -Werror
+
 create_tpm_key_SOURCES=create_tpm_key.c
 create_tpm_key_LDADD=-ltspi
+
+create_tpm2_key_SOURCES=create_tpm2_key.c tpm2-common.c
+create_tpm2_key_LDADD=-lcrypto -ltss
+create_tpm2_key_CFLAGS=-Werror
diff --git a/create_tpm2_key.c b/create_tpm2_key.c
new file mode 100644
index 000..ca3b38f
--- /dev/null
+++ b/create_tpm2_key.c
@@ -0,0 +1,451 @@
+/*
+ *
+ *   Copyright (C) 2016 James Bottomley 
+ *
+ *   GPLv2
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "tpm2-asn.h"
+#include "tpm2-common.h"
+
+static struct option long_options[] = {
+   {"auth", 0, 0, 'a'},
+   {"help", 0, 0, 'h'},
+   {"key-size", 1, 0, 's'},
+   {"name-scheme", 1, 0, 'n'},
+   {"parent-handle", 1, 0, 'p'},
+   {"wrap", 1, 0, 'w'},
+   {0, 0, 0, 0}
+};
+
+static TPM_ALG_ID name_alg = TPM_ALG_SHA256;
+static int name_alg_size = SHA256_DIGEST_SIZE;
+
+void
+usage(char *argv0)
+{
+   fprintf(stderr, "\t%s: create a TPM key and write it to disk\n"
+   "\tusage: %s [options] \n\n"
+   "\tOptions:\n"
+   "\t\t-a|--auth  require a password for the key [NO]\n"
+   "\t\t-h|--help  print this help message\n"
+   "\t\t-s|--key-size  key size in bits [2048]\n"
+   "\t\t-n|--name-scheme   name algorithm to use sha1 [sha256] 
sha384 sha512\n"
+   "\t\t-p|--parent-handle persistent handle of parent key\n"
+   "\t\t-w|--wrap [file]   wrap an existing openssl PEM key\n"
+   "\nReport bugs to %s\n",
+   argv0, argv0, PACKAGE_BUGREPORT);
+   exit(-1);
+}
+
+void
+openssl_print_errors()
+{
+   ERR_load_ERR_strings();
+   ERR_load_crypto_strings();
+   ERR_print_errors_fp(stderr);
+}
+
+int
+openssl_write_tpmfile(const char *file, BYTE *pubkey, int pubkey_len,
+ BYTE *privkey, int privkey_len, int empty_auth,
+ TPM_HANDLE parent)
+{
+   TSSLOADABLE tssl;
+   BIO *outb;
+
+   /* clear structure so as not to have to set optional parameters */
+   memset(, 0, sizeof(tssl));
+   if ((outb = BIO_new_file(file, "w")) == NULL) {
+fprintf(stderr, "Error opening file for write: %s\n", file);
+   return 1;
+   }
+   tssl.type = OBJ_txt2obj(OID_loadableKey, 1);
+   tssl.emptyAuth = empty_auth;
+   if ((parent & 0xff00) == 0x8100) {
+   tssl.parent = ASN1_INTEGER_new();
+   ASN1_INTEGER_set(tssl.parent, parent);
+   }
+   tssl.pubkey = ASN1_OCTET_STRING_new();
+   ASN1_STRING_set(tssl.pubkey, pubkey, pubkey_len);
+   tssl.privkey = ASN1_OCTET_STRING_new();
+   ASN1_STRING_set(tssl.privkey, privkey, privkey_len);
+
+   PEM_write_bio_TSSLOADABLE(outb, );
+   BIO_free(outb);
+   return 0;
+}
+
+EVP_PKEY *
+openssl_read_key(char *filename)
+{
+BIO *b = NULL;

[openssl-dev] [PATCH 0/1] TPM2 engine support for openssl

[James Bottomley]

This is a completed version of the original RFC.  It's working now both
on the TPM2 simulator and on real hardware (I've converted my laptop to
TPM2).  I've updated it to use the latest version of the ASN.1 for the
key format (still using a TCG OID).

I have it building here (it's what I'm currently using for my laptop
VPNs):

https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/openssl_tpm_engine

But note that this version also has experimental patches to activate
the in-kernel TPM Resource Manager because for multiple applications
TPM2 really doesn't work well without one.  Since the patch for the RM
is currently not upstream (yet), it's not going to work unless you have
a patched kernel.

James

---

James Bottomley (1):
  add TPM2 version of create_tpm2_key and libtpm2.so engine

 Makefile.am   |  12 +-
 create_tpm2_key.c | 451 +++
 e_tpm2.c  | 559 ++
 tpm2-asn.h|  59 ++
 tpm2-common.c | 175 +
 tpm2-common.h |  10 +
 6 files changed, 1264 insertions(+), 2 deletions(-)
 create mode 100644 create_tpm2_key.c
 create mode 100644 e_tpm2.c
 create mode 100644 tpm2-asn.h
 create mode 100644 tpm2-common.c
 create mode 100644 tpm2-common.h

-- 
2.6.6

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

[openssl-dev] [PATCH] openssl tpm engine: add new openssl bio method for seamless loading of tpm keys

[James Bottomley]

Permits this engine to be used as part of the openssl pem
routines for loading TPM based keys.  To use this, the
tpm engine must be preloaded via the openssl.cnf file

Signed-off-by: James Bottomley 
---
 configure.in |   2 +
 e_tpm.c  | 139 +++
 2 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/configure.in b/configure.in
index d07617d..4e2eff9 100644
--- a/configure.in
+++ b/configure.in
@@ -51,6 +51,8 @@ AC_PROG_LIBTOOL
 CFLAGS="$CFLAGS -Wall"
 AC_SUBST(CFLAGS)
 
+AC_CHECK_LIB(crypto, ENGINE_find_engine_load_key, 
[AC_DEFINE(HAVE_ENGINE_FIND_ENGINE_LOAD_KEY)])
+
 AC_OUTPUT(Makefile test/Makefile)
 
 echo "CFLAGS=$CFLAGS"
diff --git a/e_tpm.c b/e_tpm.c
index 3e20f8e..40ed4da 100644
--- a/e_tpm.c
+++ b/e_tpm.c
@@ -43,13 +43,20 @@
 #ifndef OPENSSL_NO_HW
 #ifndef OPENSSL_NO_HW_TPM
 
+struct tpm_ui {
+UI_METHOD *ui_method;
+pem_password_cb *pem_cb;
+};
+
 /* engine specific functions */
 static int tpm_engine_destroy(ENGINE *);
 static int tpm_engine_init(ENGINE *);
 static int tpm_engine_finish(ENGINE *);
 static int tpm_engine_ctrl(ENGINE *, int, long, void *, void (*)());
 static EVP_PKEY *tpm_engine_load_key(ENGINE *, const char *, UI_METHOD *, void 
*);
-static char *tpm_engine_get_auth(UI_METHOD *, char *, int, char *, void *);
+/* note unused unless HAVE_ENGINE_FIND_ENGINE_LOAD_KEY is defined */
+static int tpm_engine_load_key_bio(ENGINE *, EVP_PKEY **, BIO *, 
pem_password_cb *, void *) __attribute__((unused));
+static char *tpm_engine_get_auth(struct tpm_ui *, char *, int, char *, void *);
 
 #ifndef OPENSSL_NO_RSA
 /* rsa functions */
@@ -212,6 +219,9 @@ static int bind_helper(ENGINE * e)
!ENGINE_set_ctrl_function(e, tpm_engine_ctrl) ||
!ENGINE_set_load_pubkey_function(e, tpm_engine_load_key) ||
!ENGINE_set_load_privkey_function(e, tpm_engine_load_key) ||
+#ifdef HAVE_ENGINE_FIND_ENGINE_LOAD_KEY
+!ENGINE_set_load_privkey_bio_function(e, tpm_engine_load_key_bio) 
||
+#endif
!ENGINE_set_cmd_defns(e, tpm_cmd_defns))
return 0;
 
@@ -244,7 +254,7 @@ void ENGINE_load_tpm(void)
ERR_clear_error();
 }
 
-int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+int tpm_load_srk(struct tpm_ui *ui, void *cb_data)
 {
TSS_RESULT result;
UINT32 authusage;
@@ -451,8 +461,9 @@ err:
return 0;
 }
 
-static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
-char *input_string, void *cb_data)
+static char *tpm_engine_get_auth_ui(UI_METHOD *ui_method, char *auth,
+   int maxlen, char *input_string,
+   void *cb_data)
 {
UI *ui;
 
@@ -479,6 +490,30 @@ static char *tpm_engine_get_auth(UI_METHOD *ui_method, 
char *auth, int maxlen,
return auth;
 }
 
+static char *tpm_engine_get_auth_pem(pem_password_cb *pem_cb, char *auth,
+   int maxlen, char *input_string,
+   void *cb_data)
+{
+   EVP_set_pw_prompt(input_string);
+   if (!pem_cb)
+   pem_cb = PEM_def_callback;
+   pem_cb(auth, maxlen, 0, cb_data);
+   EVP_set_pw_prompt(NULL);
+
+   return auth;
+}
+
+static char *tpm_engine_get_auth(struct tpm_ui *ui, char *auth,
+ int maxlen, char *input_string, void *cb_data)
+{
+   if (ui->ui_method)
+   return tpm_engine_get_auth_ui(ui->ui_method, auth, maxlen,
+ input_string, cb_data);
+   else
+   return tpm_engine_get_auth_pem(ui->pem_cb, auth, maxlen,
+  input_string, cb_data);
+}
+
 static int tpm_engine_finish(ENGINE * e)
 {
DBG("%s", __FUNCTION__);
@@ -575,8 +610,9 @@ int fill_out_rsa_object(RSA *rsa, TSS_HKEY hKey)
return 1;
 }
 
-static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
-UI_METHOD *ui, void *cb_data)
+static int tpm_engine_load_key_core(ENGINE *e, EVP_PKEY **ppkey,
+   const char *key_id, BIO *bio,
+   struct tpm_ui *ui, void *cb_data)
 {
ASN1_OCTET_STRING *blobstr;
TSS_HKEY hKey;
@@ -589,39 +625,57 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const 
char *key_id,
 
DBG("%s", __FUNCTION__);
 
-   if (!key_id) {
+   if (!key_id && !bio) {
TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_PASSED_NULL_PARAMETER);
-   return NULL;
-   }
-
-   if (!tpm_load_srk(ui, cb_data)) {
-   TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
-   return NULL;
+   return 0;
}
 
-   if ((bf = BIO_new_file(key_id, "r")) == NULL) {
-   TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
-  

[openssl-dev] [PATCH] openssl tpm engine: add new openssl bio method for seamless loading of tpm keys

[James Bottomley]

Permits this engine to be used as part of the openssl pem
routines for loading TPM based keys.  To use this, the
tpm engine must be preloaded via the openssl.cnf file

Signed-off-by: James Bottomley 

diff --git a/e_tpm.c b/e_tpm.c
index 3e20f8e..9cb1d6c 100644
--- a/e_tpm.c
+++ b/e_tpm.c
@@ -43,13 +43,19 @@
 #ifndef OPENSSL_NO_HW
 #ifndef OPENSSL_NO_HW_TPM
 
+struct tpm_ui {
+UI_METHOD *ui_method;
+pem_password_cb *pem_cb;
+};
+
 /* engine specific functions */
 static int tpm_engine_destroy(ENGINE *);
 static int tpm_engine_init(ENGINE *);
 static int tpm_engine_finish(ENGINE *);
 static int tpm_engine_ctrl(ENGINE *, int, long, void *, void (*)());
 static EVP_PKEY *tpm_engine_load_key(ENGINE *, const char *, UI_METHOD *, void 
*);
-static char *tpm_engine_get_auth(UI_METHOD *, char *, int, char *, void *);
+static int tpm_engine_load_key_flags(ENGINE *, EVP_PKEY **, const char *, 
pem_password_cb *, void *, unsigned int);
+static char *tpm_engine_get_auth(struct tpm_ui *, char *, int, char *, void *);
 
 #ifndef OPENSSL_NO_RSA
 /* rsa functions */
@@ -212,6 +218,9 @@ static int bind_helper(ENGINE * e)
!ENGINE_set_ctrl_function(e, tpm_engine_ctrl) ||
!ENGINE_set_load_pubkey_function(e, tpm_engine_load_key) ||
!ENGINE_set_load_privkey_function(e, tpm_engine_load_key) ||
+#ifdef ENGINE_LOAD_KEY_FLAG_BIO
+!ENGINE_set_load_key_flags_function(e, tpm_engine_load_key_flags) 
||
+#endif
!ENGINE_set_cmd_defns(e, tpm_cmd_defns))
return 0;
 
@@ -244,7 +253,7 @@ void ENGINE_load_tpm(void)
ERR_clear_error();
 }
 
-int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+int tpm_load_srk(struct tpm_ui *ui, void *cb_data)
 {
TSS_RESULT result;
UINT32 authusage;
@@ -451,8 +460,9 @@ err:
return 0;
 }
 
-static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
-char *input_string, void *cb_data)
+static char *tpm_engine_get_auth_ui(UI_METHOD *ui_method, char *auth,
+   int maxlen, char *input_string,
+   void *cb_data)
 {
UI *ui;
 
@@ -479,6 +489,30 @@ static char *tpm_engine_get_auth(UI_METHOD *ui_method, 
char *auth, int maxlen,
return auth;
 }
 
+static char *tpm_engine_get_auth_pem(pem_password_cb *pem_cb, char *auth,
+   int maxlen, char *input_string,
+   void *cb_data)
+{
+   EVP_set_pw_prompt(input_string);
+   if (!pem_cb)
+   pem_cb = PEM_def_callback;
+   pem_cb(auth, maxlen, 0, cb_data);
+   EVP_set_pw_prompt(NULL);
+
+   return auth;
+}
+
+static char *tpm_engine_get_auth(struct tpm_ui *ui, char *auth,
+ int maxlen, char *input_string, void *cb_data)
+{
+   if (ui->ui_method)
+   return tpm_engine_get_auth_ui(ui->ui_method, auth, maxlen,
+ input_string, cb_data);
+   else
+   return tpm_engine_get_auth_pem(ui->pem_cb, auth, maxlen,
+  input_string, cb_data);
+}
+
 static int tpm_engine_finish(ENGINE * e)
 {
DBG("%s", __FUNCTION__);
@@ -575,8 +609,19 @@ int fill_out_rsa_object(RSA *rsa, TSS_HKEY hKey)
return 1;
 }
 
-static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
-UI_METHOD *ui, void *cb_data)
+static inline int tpm_flag_is_bio(unsigned int flags)
+{
+#ifdef ENGINE_LOAD_KEY_FLAG_BIO
+   return flags & ENGINE_LOAD_KEY_FLAG_BIO;
+#else
+   return 0;
+#endif
+}
+
+static int tpm_engine_load_key_core(ENGINE *e, EVP_PKEY **ppkey,
+ const char *key_id,
+  struct tpm_ui *ui,
+  void *cb_data, unsigned int flags)
 {
ASN1_OCTET_STRING *blobstr;
TSS_HKEY hKey;
@@ -591,37 +636,55 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const 
char *key_id,
 
if (!key_id) {
TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_PASSED_NULL_PARAMETER);
-   return NULL;
-   }
-
-   if (!tpm_load_srk(ui, cb_data)) {
-   TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
-   return NULL;
+   return 0;
}
 
-   if ((bf = BIO_new_file(key_id, "r")) == NULL) {
-   TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
-  TPM_R_FILE_NOT_FOUND);
-   return NULL;
+   if (tpm_flag_is_bio(flags)) {
+   bf = (BIO *)key_id;
+   } else {
+   if ((bf = BIO_new_file(key_id, "r")) == NULL) {
+   TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
+  TPM_R_FILE_NOT_FOUND);
+   return 0;
+   }
}
 
blobstr = 

Re: [openssl-dev] [PATCH] rand/randfile: return the home directory if possible

[Salz, Rich]

> Won't work for "normal" user. This was change in commit fc6076ca272f
> ("rand/randfile.c: make it non-ASCII-savvy."). Was this change on purpose?

The change was on purpose and a slightly different fix is in progress and will 
show up soon.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] rand/randfile: return the home directory if possible

[Sebastian Andrzej Siewior]

From: Sebastian Andrzej Siewior 

The command
|$ openssl rand -base64 3
|gIX3
|unable to write 'random state'

the last line is an error because `s' is never initialized if RANDFILE
is not set. It never tries to look for $HOME for the normal user. The
manpage says:

|On all systems, if the environment variable RANDFILE is set, its value
|will be used as the seed file name.

not possible, go on

|Otherwise, the file is called ".rnd", found in platform dependent locations:
| On all other systems
| $HOME

Won't work for "normal" user. This was change in commit fc6076ca272f
("rand/randfile.c: make it non-ASCII-savvy."). Was this change on
purpose?

Signed-off-by: Sebastian Andrzej Siewior 
---

 crypto/rand/randfile.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c
index 7aeb87174370..0574cfcc3860 100644
--- a/crypto/rand/randfile.c
+++ b/crypto/rand/randfile.c
@@ -318,7 +318,8 @@ const char *RAND_file_name(char *buf, size_t size)
 #else
 if (OPENSSL_issetugid() == 0) {
 s = getenv("RANDFILE");
-} else {
+}
+if (!s) {
 use_randfile = 0;
 if (OPENSSL_issetugid() == 0)
 s = getenv("HOME");
-- 
2.9.3

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

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Tue, 2016-08-30 at 12:38 +0200, Andy Polyakov wrote:
> > So for other applications to try to read OpenSSL's PKCs#12 files, what
> > we need to do is first convert the sane Unicode rendition of the
> > password into the native locale charset (e.g. Windows-1252), then take
> > that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE
> > to check the MAC. Then if that fails, take the same Windows-1252
> > bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to
> > see if it works.
> 
> Are you sure you want to know? I mean you already said "I wish I hadn't
> ask", and now you are bringing Windows into conversation :-) :-) :-)

I concede, I am a masochist. :)

> Yes, it's as bad as you can possibly imagine, and trouble is that there
> is no "right thing" to do *if* you formulate "keep old data accessible"
> as goal.

Yeah, if you want to be able to create PKCS#12 files that'll work (in
the same locale) with older versions of OpenSSL, you're kind of stuck.

I can live with that historical accident, and the workaround of
"convert to the locale charset, then pretend that's ISO8859-1 and try
again". I can even live with the fact that, for the reasons you've
stated, OpenSSL *still* produces files which need that workaround.

But I *really* wish you hadn't added *another* bug, and required
another workaround

> At the same time a way to access and generate
> specification-compliant data is provided (on *ix it takes *an* UTF8
> locale, which is default in absolute majority of cases bu now, and on
> Windows it's an *opt-in* environment variable for the time being).

... so instead of doing the UTF-8 thing whenever the incoming
bytestream happens to be interpretable as valid UTF-8, why not do it
only if LC_CTYPE actually *is* UTF-8?

So my (admittedly contrived and unlikely) example of "ĂŻ" in an
ISO8859-2 locale would only continue to do the *old* wrong thing, and
not a *new* wrong thing that needs an additional workaround :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[Andy Polyakov]

> Hm, words fail me.
> 
> Well, that's not entirely true. But *polite* words fail me...

:-)

> Let me try to understand this... you have always ignored, and still
> ignore, the actual LC_CTYPE which tells you the character set in which
> the password was provided from the user.
> 
> You *used* to convert it through your horribly misnamed
> OPENSSL_asc2uni() function, which actually converts ISO8859-1 to
> UTF16BE by simply expanding it and inserting 0x00 between each byte of
> the original. So effectively you were "assuming" the input was
> ISO8859-1.

Unfortunately yes.

> Now you assume it's UTF-8, and convert it with OPENSSL_utf8touni().
> (And now what happens when the locale input *isn't* valid UTF-8,
> because it's a legacy 8-bit charset? That conversion should fail,
> right?)

Right. Though more correct formulation probably "is likely to fail"
instead of "should fail".

> Your latest workaround (from which I started this thread) is addressing
> the first problem *purely* for the case of the UTF-8 locale. It checks
> for the "we treated UTF-8 as if it were ISO8859-1" case, which is what
> leads to the 006e 0061 00c3 00af 0076 0065 example you gave above.

Yes.

> But you *haven't* actually implemented any workaround for the other
> whole set of "we treated locale X as if it were ISO8859-1" bugs
> that your original code had. Or the whole set of "we treated local
> X as if it were UTF-8" bugs that the new code has.

Yes.

> So for other applications to try to read OpenSSL's PKCs#12 files, what
> we need to do is first convert the sane Unicode rendition of the
> password into the native locale charset (e.g. Windows-1252), then take
> that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE
> to check the MAC. Then if that fails, take the same Windows-1252
> bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to
> see if it works.

Are you sure you want to know? I mean you already said "I wish I hadn't
ask", and now you are bringing Windows into conversation :-) :-) :-)
Yes, it's as bad as you can possibly imagine, and trouble is that there
is no "right thing" to do *if* you formulate "keep old data accessible"
as goal. I mean the right thing to do is to perform all due conversions
to obtain locale-neutral big-endian UTF-16 (though it's not obvious if
it's actually desired to bring in dependency on something like iconv
into libcrypto), but trouble is that it will more than likely render old
data inaccessible. That's why somewhat opportunistic approach is taken
in this version, unfortunate as it is. Main goal is that given otherwise
unchanged circumstances new version *has to* be able to read old data
generated by previous version on the *same* system, irregardless how
broken it is. At the same time a way to access and generate
specification-compliant data is provided (on *ix it takes *an* UTF8
locale, which is default in absolute majority of cases bu now, and on
Windows it's an *opt-in* environment variable for the time being).

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

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 23:01 +0200, Andy Polyakov wrote:
> > 
> > So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
> > and the locale (not that it *should* matter) is ISO8859-2.
> When it comes to locale in *this* case you should rather wonder what
> does your terminal emulator program do and how does it interact with
> your shell. Because these two are responsible for composing the string
> that OPENSSL_[asc|utf8]2uni gets.

Right. And for the purpose of my example I have moved to eastern Europe
and fallen through a time-warp into the 20th century, so I'm using an
ISO8859-2 locale.

> > The correct rendition is 01 02 01 7b.
> Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as
> argument or console input under an UTF-8 locale. Otherwise it would have
> been passed as 'c3 af'.

No. My locale is ISO8859-2 so the password "ĂŻ" *is* passed as 'c3 af'.

Old OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform an ISO8859-1 to UCS16BE conversion using the doubly-misnamed
OPENSSL_asc2uni() function. So it'll use '00 c3 00 af'.

New OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform a UTF-8 to UCS16BE conversion using the only singly renamed
OPENSSL_utf82uni() function. So it'll use '00 ef'.

You had a bug because you made assumptions about the input data and
didn't properly convert from the locale charset to UTF16BE as you
should have done. Instead of fixing the bug, you just changed the
assumption you made to one that's slightly more likely to be valid in
today's world.

Leaving the rest of us with *two* buggy behaviours to try to work
around.

> > 
> > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
> > to *convert* to ISO8859-2 (giving c3 af).
> No, no conversion from UTF-8 to ISO8859-x or any other conversion was
> *ever* performed. Nor is it performed now. It was and still is all about
> how string is composed by *somebody else*. That's why I said that "we
> assume that you don't change locale when you upgrade OpenSSL".

I'm talking about how other libraries should attempt to read the
PKCS#12 files created by OpenSSL. In my code I have the string "ĂŻ"
which the user has provided as the password. It doesn't matter what
charset it's in, as long as I *know* what charset it's in, and haven't
wantonly thrown that information away and started making *assumptions*
about how to interpret the stream of bytes.

So in order to try to emulate the old OpenSSL bug and read the file, I
need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and
treat it as ISO8859-1 for the purpose of converting to UTF16BE and
trying to decrypt. Which gives me the '00 c3 00 af' as above.

And in order to emulate the new OpenSSL bug and read the file, I need
to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it
as UTF-8 for the purpose of converting to UTF16BE and trying to
decrypt. Which gives me the '00 ef' that current OpenSSL will use.

This latter buggy behaviour hasn't actually been released yet, has it?
Is it too late to fix it properly?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[Andy Polyakov]

> So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
> and the locale (not that it *should* matter) is ISO8859-2.

When it comes to locale in *this* case you should rather wonder what
does your terminal emulator program do and how does it interact with
your shell. Because these two are responsible for composing the string
that OPENSSL_[asc|utf8]2uni gets.

> The correct rendition is 01 02 01 7b.

Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as
argument or console input under an UTF-8 locale. Otherwise it would have
been passed as 'c3 af'.

> The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
> to *convert* to ISO8859-2 (giving c3 af).

No, no conversion from UTF-8 to ISO8859-x or any other conversion was
*ever* performed. Nor is it performed now. It was and still is all about
how string is composed by *somebody else*. That's why I said that "we
assume that you don't change locale when you upgrade OpenSSL".

> Then to interpret those bytes
> as ISO8859-1 (in which they would mean "ï") and convert *that* to
> UTF16LE to give 00 c3 00 af

Previously OpenSSL would convert 'c4 82 c5 bb' to '00 c4 00 82 00 c5 00
bb'. Now it converts it to '01 02 01 7b', but attempts even '00 c4 00 82
00 c5 00 bb' for "old times sake". And for 'c3 af' question is if it's
valid UTF-8 encoding. If it is (it is in this example), then it would
attempt '00 ef' (in this example) and then '00 c3 00 af', and if not,
then it would go straight to '00 c3 00 af'.


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

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 18:40 +0100, David Woodhouse wrote:
> 
> So... let's have a password 'nałve', in a ISO8859-2 environment where
> that is represented by the bytes 6e 61 b3 76 65.
> 
> First I should try the correct version according to the spec:
>  006e 0061 0142 0076 0065
> 
> Then we try the "OpenSSL assumed it was ISO8859-1" version:
>  006e 0061 00b3 0076 0065
> 
> And finally we try the "OpenSSL assumed it was UTF-8" version:
>  006e 0061 ... actually you *can't* convert that byte sequence "from"
> UTF-8 since it isn't valid UTF-8. So what will new OpenSSL do here,
> again?

In this specific example (the byte stream is not valid UTF-8 it looks
like OPENSSL_utf8touni() will assume it's actually ISO8859-1 and thus
the final case will be identical to the previous one.

So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
and the locale (not that it *should* matter) is ISO8859-2.

The correct rendition is 01 02 01 7b.

The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
to *convert* to ISO8859-2 (giving c3 af). Then to interpret those bytes
as ISO8859-1 (in which they would mean "ï") and convert *that* to
UTF16LE to give 00 c3 00 af

The "new buggy OpenSSL" rendition, again in the ISO8859-2 locale, would
again be to convert to ISO8859-2 (c3 af). Then to interpret those bytes
as UTF-8 (in which they would mean "ï") and convert *that* to UTF16LE
to give 00 ef.

Right?

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 15:25 +0200, Andy Polyakov wrote:
> First of all. *Everything* that is said below (and what modifications in
> question are about) applies to non-ASCII passwords. ASCII-only passwords
> are not affected by this and keep working as they were.
> 
> > 
> > > 
> > > commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9
> > > 
> > > OpenSSL versions before 1.1.0 didn't convert non-ASCII
> > > UTF8 PKCS#12 passwords to Unicode correctly.
> > > 
> > > To correctly decrypt older files, if MAC verification fails
> > > with the supplied password attempt to use the broken format
> > > which is compatible with earlier versions of OpenSSL.
> > > 
> > > Reviewed-by: Richard Levitte 
> > 
> > Hm, this sounds like something that other crypto libraries also ought
> > to try to work around. 
> > 
> > Please could you elaborate on the specific problem, and/or show a test
> > case?
> 
> Note that there is 80-test_pkcs12.t that refers to shibboleth.pfx.

Thanks.

> > I'm not quite sure how to interpret the patch itself. You pass the
> > password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() — which
> > is essentially converting ISO8859-1 to UTF-8.
> 
> You make it sound like these two are called one after another. But
> that's not what happens. It *tries* to access data with passwords
> converted with OPENSSL_asc2uni *or* OPENSSL_utf82uni, effectively
> independently of each other, in order to see which one is right. So that
> you can *transparently* access old broken data, as well as
> specification-compliant one.

Hm... at line 541 of pkcs12.c we call PKCS12_verify_mac(…mpass…) with
the original provided password. Which is in the locale-native character
set, is it not? No attempt to convert to anything known.

Then if that *fails* we do indeed convert it via OPENSSL_asc2uni() and
OPENSSL_uni2utf8() to make 'badpass' and try again:

} else if (!PKCS12_verify_mac(p12, mpass, -1)) {
/*
 * May be UTF8 from previous version of OpenSSL:
 * convert to a UTF8 form which will translate
 * to the same Unicode password.
 */
unsigned char *utmp;
int utmplen;
utmp = OPENSSL_asc2uni(mpass, -1, NULL, );
if (utmp == NULL)
goto end;
badpass = OPENSSL_uni2utf8(utmp, utmplen);
OPENSSL_free(utmp);
if (!PKCS12_verify_mac(p12, badpass, -1)) {
BIO_printf(bio_err, "Mac verify error: invalid password?\n");
ERR_print_errors(bio_err);
goto end;
} else {
BIO_printf(bio_err, "Warning: using broken algorithm\n");
if (!twopass)
cpass = badpass;
}

The shibboleth.pfx test seems to pass on the *first* call to
PKCS12_verify_mac() — it *isn't* testing this fallback. If I add a
space to the end of the correct password and stick a breakpoint on
PKCS12_verify_mac(), I see the following calls:

#0  PKCS12_verify_mac (p12=0x956e40, 
pass=0x956a30 "σύνθημα γνώρισμα ", passlen=-1)
at crypto/pkcs12/p12_mutl.c:152
#1  0x00425567 in pkcs12_main (argc=0, argv=0x7fffdd90)
at apps/pkcs12.c:541


And then it converts that string from ISO8859-1 (which it wasn't) to
UTF-8, and calls PKCS12_verify_mac() again:

#0  PKCS12_verify_mac (p12=0x956e40, 
pass=0x9597e0 "Ï\302\203Ï\302\215νθημα
γνÏ\302\216Ï\302\201ιÏ\302\203μα ", passlen=-1) at
crypto/pkcs12/p12_mutl.c:152
#1  0x004255fc in pkcs12_main (argc=0, argv=0x7fffdd90)
at apps/pkcs12.c:554

> > 
> > So, if my password is "naïve". In UTF-8 that's 6e 61 c3 af 76 65, which
> > is the correct sequence of bytes to use for the password?
> 
> 00 6e 00 61 00 ef 00 76 00 65, big-endian UTF-16.

Is that conversion done inside PKCS12_verify_mac()? Because we
definitely aren't passing UTF-16-BE into PKCS12_verify_mac().

> > 
> > And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65
> > by assuming it's ISO8859-1 (which would be 'naïve') and converting to 
> > UTF-8?
> 
> I don't follow. Why would it have to be converted to this sequence?

That's what it's doing. Changing the example above and showing the same
breakpoints as they get hit again...

Starting program: /home/dwmw2/git/openssl/apps/openssl pkcs12 -noout -password 
pass:naïve -in test/shibboleth.pfx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x956a30 "naïve", 
passlen=-1) at crypto/pkcs12/p12_mutl.c:152
152 if (p12->mac == NULL) {
(gdb) x/7bx pass
0x956a30:   0x6e0x610xc30xaf0x760x650x00
(gdb) c
Continuing.

Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x959960 "naïve", 
passlen=-1) at crypto/pkcs12/p12_mutl.c:152
152 if (p12->mac == NULL) {
(gdb) x/8bx pass
0x959960:   0x6e0x610xc30x83 

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[Andy Polyakov]

First of all. *Everything* that is said below (and what modifications in
question are about) applies to non-ASCII passwords. ASCII-only passwords
are not affected by this and keep working as they were.

>> commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9
>>
>> OpenSSL versions before 1.1.0 didn't convert non-ASCII
>> UTF8 PKCS#12 passwords to Unicode correctly.
>>
>> To correctly decrypt older files, if MAC verification fails
>> with the supplied password attempt to use the broken format
>> which is compatible with earlier versions of OpenSSL.
>>
>> Reviewed-by: Richard Levitte 
> 
> Hm, this sounds like something that other crypto libraries also ought
> to try to work around. 
> 
> Please could you elaborate on the specific problem, and/or show a test
> case?

Note that there is 80-test_pkcs12.t that refers to shibboleth.pfx.

> I'm not quite sure how to interpret the patch itself. You pass the
> password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() — which
> is essentially converting ISO8859-1 to UTF-8.

You make it sound like these two are called one after another. But
that's not what happens. It *tries* to access data with passwords
converted with OPENSSL_asc2uni *or* OPENSSL_utf82uni, effectively
independently of each other, in order to see which one is right. So that
you can *transparently* access old broken data, as well as
specification-compliant one.

> So, if my password is "naïve". In UTF-8 that's 6e 61 c3 af 76 65, which
> is the correct sequence of bytes to use for the password?

00 6e 00 61 00 ef 00 76 00 65, big-endian UTF-16.

> And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65
> by assuming it's ISO8859-1 (which would be 'naïve') and converting to UTF-8?

I don't follow. Why would it have to be converted to this sequence?

> So... what was the bug that was actually being worked around?

6e 61 c3 af 76 65 was expanded to 00 6e 00 61 00 c3 00 af 00 76 00 65,
in violation of specification.

> That
> older versions were converting from the local charset to UTF-8 twice in
> a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback
> which will cope with that in *some* locales but not all...?

Yeah, something like that. Note that if you have created PKCS#12 file
with a non-UTF8 locale, it's not given that you can read it with another
locale, UTF-8 or not. This was *always* the case. And that's *not* what
we try to address here. We assume that you don't change locale when you
upgrade OpenSSL version. Ultimate goal is to make it compliant with
specification and therefore interoperable with other compliant
implementations. But we can't just switch, because then it stops
interoperate with older OpenSSL versions. This is the reason for why it
looks messy. It's about having it both ways... Though there is one
ambiguity in this. Said interoperability assumes UTF-8 locale (on *ix,
or OPENSSL_WIN32_UTF8 opt-in environment variable on Windows). I.e. it's
not given that users that use non-UTF8 locale can actually interoperate
with other implementations. It's assumed that such users are not
actually interested to, and if they express interest, they will be
advised to switch to UTF-8 locale and convert their data to
interoperable format.

Is this helpful?

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

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Wed, 2016-08-24 at 18:55 +0100, Dr. Stephen Henson wrote:
> commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9
>
> OpenSSL versions before 1.1.0 didn't convert non-ASCII
> UTF8 PKCS#12 passwords to Unicode correctly.
> 
> To correctly decrypt older files, if MAC verification fails
> with the supplied password attempt to use the broken format
> which is compatible with earlier versions of OpenSSL.
> 
> Reviewed-by: Richard Levitte 

Hm, this sounds like something that other crypto libraries also ought
to try to work around. 

Please could you elaborate on the specific problem, and/or show a test
case?

I'm not quite sure how to interpret the patch itself. You pass the
password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() — which
is essentially converting ISO8859-1 to UTF-8.

So, if my password is "naïve". In UTF-8 that's 6e 61 c3 af 76 65, which
is the correct sequence of bytes to use for the password?

And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65
by assuming it's ISO8859-1 (which would be 'naïve') and converting to
UTF-8?

So... what was the bug that was actually being worked around? That
older versions were converting from the local charset to UTF-8 twice in
a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback
which will cope with that in *some* locales but not all...? I don't
really understand.

Thanks for any light you can shed on it!

/me goes off to add non-ASCII passwords to the growing torture test
suite at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path.

[Andy Polyakov]

>> Originally new-line was suppressed, because double new-line was
>> observed under wine. But it appears rather to be a wine bug,
>> because on real Windows new-line is much needed.
>>
>> Reviewed-by: Richard Levitte 
> 
> Hm, this commit comment needs an explicit reference to the mentioned
> bug in bugs.winehq.org.
> 
> I can't find it. Is it related to 
> https://bugs.winehq.org/show_bug.cgi?id=27229 ?

Well, the commit message is based on empirical findings. I mean it
simply reflects the fact that code was originally debugged under wine,
but then it was found that on actual Windows console prompts appear on
the same line. And since we have to accept that Windows is right,
workaround for double new-line under wine was disengaged.

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

Re: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path.

[David Woodhouse]

On Mon, 2016-08-01 at 10:48 +0200, Andy Polyakov wrote:
> Originally new-line was suppressed, because double new-line was
> observed under wine. But it appears rather to be a wine bug,
> because on real Windows new-line is much needed.
> 
> Reviewed-by: Richard Levitte 

Hm, this commit comment needs an explicit reference to the mentioned
bug in bugs.winehq.org.

I can't find it. Is it related to 
https://bugs.winehq.org/show_bug.cgi?id=27229 ?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Mon, 2016-07-25 at 16:29 +0100, David Woodhouse wrote:
> I'm currently trying to stop it whining about DTLSv1_client_method()
> being deprecated; I can't see how to make it work using
> DTLS_client_method().

The SSL_OP_CISCO_ANYCONNECT hack doesn't work so well with
DTLS_client_method. Instead of there being one simple place where we
can set s->client_version = s->version = DTLS1_BAD_VER, we'd end up
having to play silly buggers in quite a few places. So I figured I
should probably just do it properly with support for DTLS1_BAD_VER, as
below.

Although arguably, if I've used SSL_set_session() such that
s->session->ssl_version == DTLS1_BAD_VER, that should have been
honoured.

Two new commits at the tip of PR#1296 for comment...
https://github.com/openssl/openssl/pull/1296/commits/a1c341f7
(Make DTLS1_BAD_VER work with DTLS_client_method())

https://github.com/openssl/openssl/pull/1296/commits/41800497
(Honour SSL version in SSL_set_session()).

Not entirely sure if those are the best approach... but hey, you have a
test case now :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

I added a basic test in PR #1296. It just simulates the basic session
resume and — since it seemed relatively trivial to add while I was at
it — out-of-order packet RX:
https://github.com/openssl/openssl/pull/1296/commits/9538be65

This test catches all the bugs that the pull request fixes, and also
tests the session resume method that OpenConnect uses, of manually
building the ASN.1 with the session details and then using
d2i_SSL_SESSION().

It validates the handshake MAC, which is different for DTLS1_BAD_VER
because it doesn't include the handshake message headers.

It also checks the handling of the 3-byte Change Cipher Spec message,
in both directions.

I'm currently trying to stop it whining about DTLSv1_client_method()
being deprecated; I can't see how to make it work using
DTLS_client_method().

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> Can you describe how DTLS1_BAD_VER is supposed to work?  Is this
> version send over the wire?  Is it negotiated?

It does indeed appear on the wire.

In the AnyConnect/OpenConnect case — which, as you rightly observe, is
the only remaining user of this version of the protocol — it's not
actually negotiated in the normal sense at all; we "resume" a session
having established the master secret and session-id over a separate
channel.

http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/dtls.c#l157

> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

Yeah, test coverage would be useful... I'm not sure how complete our
*server* side support of DTLS1_BAD_VER is. I did start looking at it
briefly once, but got distracted. I'll have another look.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[Kurt Roeckx]

On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote:
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
> available:ssl/statem/statem_clnt.c:927:
> 
> I tried the naïvely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Can you describe how DTLS1_BAD_VER is supposed to work?  Is this
version send over the wire?  Is it negotiated?

We have no test suite coverage doing anything with DTLS1_BAD_VER
and I think the OpenConnect VPN is the only user of it.


Kurt

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

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 19:13 +, Viktor Dukhovni wrote:
> 
> Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
> that you're actually doing a comparison. 

Well, 'cmp' with one argument isn't *so* easily interpreted as a
comparison, but OK :)

I've also added a comment explaining a little about what's going on.


>  Given this macro, one
> might consider complementing the versions, so that the ordinals
> compare in the usual way:
> 
>     #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ 
> (v)))

I suppose we can, if someone feels strongly about it. It didn't seem
worth the additional churn.

One of 4 patches in https://github.com/openssl/openssl/pull/1296 which
actually make OpenConnect work again...

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Fix missing return value checks in SCTP

[David Woodhouse]

On Tue, 2015-08-11 at 19:36 +0100, Matt Caswell wrote:
> There are some missing return value checks in the SCTP code. In master this
> was causing a compilation failure when config'd with
> "--strict-warnings sctp".
> 
> Reviewed-by: Tim Hudson 
> ---
>  ssl/d1_clnt.c | 16 
>  ssl/d1_srvr.c | 18 +-
>  2 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
> index 566c154..d411614 100644
> --- a/ssl/d1_clnt.c
> +++ b/ssl/d1_clnt.c
> @@ -364,11 +364,15 @@ int dtls1_connect(SSL *s)
>   sizeof(DTLS1_SCTP_AUTH_LABEL),
>   DTLS1_SCTP_AUTH_LABEL);
>  
> -SSL_export_keying_material(s, sctpauthkey,
> +if (SSL_export_keying_material(s, sctpauthkey,
> sizeof(sctpauthkey),
> labelbuffer,
> sizeof(labelbuffer), NULL, 0,
> -   0);
> +   0) <= 0) {
> +ret = -1;
> +s->state = SSL_ST_ERR;
> +goto end;
> +}
>  
>  BIO_ctrl(SSL_get_wbio(s),
>   BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY,

This commit (d8e8590e) and its backport to 1.0.2 (b3a62dc0) have broken
OpenConnect when SCTP is enabled, because SSL_export_keying_material()
*does* fail there. Perhaps it shouldn't...

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 08e3673..6db4f3a 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -2231,7 +2231,7 @@ int SSL_export_keying_material(SSL *s, unsigned char 
*out, size_t olen,
const unsigned char *p, size_t plen,
int use_context)
 {
-if (s->version < TLS1_VERSION)
+if (s->version < TLS1_VERSION && s->version != DTLS1_BAD_VER)
 return -1;
 
 return s->method->ssl3_enc->export_keying_material(s, out, olen, label,

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[Viktor Dukhovni]

On Fri, Jul 08, 2016 at 07:30:26PM +0100, David Woodhouse wrote:

> > I tried the naïvely obvious step of changing all instances of
> > DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.
> 
> Of course, it's because DTLS_VERSION_LT and friends are doing precisely
> the opposite of what their names imply, numerically. I hesitate to call
> this a 'fix' but it highlights the issue:

Yes, unfortunately, the DTLS "bad" version of 0x0100 looks like a
very high DTLS version.  So comparisons require a special case.
Given that DTLS1_VERSION is 0xFEFF, indeed the next "lower" version
is 0xFF00 as you suggest below:


> diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
> index ef5eb8c..218dcce 100644
> --- a/ssl/ssl_locl.h
> +++ b/ssl/ssl_locl.h
> @@ -259,10 +259,11 @@
>c[1]=(unsigned char)(((l)>> 8)&0xff), \
>c[2]=(unsigned char)(((l))&0xff)),c+=3)
>  
> -#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
> -#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
> -#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
> -#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
> +#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
> +#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
> +#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))

Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
that you're actually doing a comparison.  Given this macro, one
might consider complementing the versions, so that the ordinals
compare in the usual way:

#define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ 
(v)))

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

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 17:43 +0100, David Woodhouse wrote:
> On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> > Reviewed-by: Viktor Dukhovni 
> > 
> > MR: #1595
> > ---
> >  ssl/s3_lib.c | 534 
> > +++
> >  ssl/ssl_ciph.c   | 196 +
> >  ssl/ssl_lib.c    |   4 +-
> >  ssl/ssl_locl.h   |  21 +-
> >  ssl/ssl_txt.c    |   2 +-
> >  ssl/statem/statem_clnt.c |  18 +-
> >  ssl/statem/statem_lib.c  |   6 +-
> >  ssl/t1_lib.c |  41 ++--
> >  8 files changed, 504 insertions(+), 318 deletions(-)
> > 
> > diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> > index 51fb161..093ff09 100644
> > --- a/ssl/s3_lib.c
> > +++ b/ssl/s3_lib.c
> > @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> >   SSL_aRSA,
> >   SSL_eNULL,
> >   SSL_MD5,
> > - SSL_SSLV3,
> > + SSL3_VERSION, TLS1_2_VERSION,
> > + DTLS1_VERSION, DTLS1_2_VERSION,
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
> available:ssl/statem/statem_clnt.c:927:
> 
> I tried the naïvely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Of course, it's because DTLS_VERSION_LT and friends are doing precisely
the opposite of what their names imply, numerically. I hesitate to call
this a 'fix' but it highlights the issue:

diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
index ef5eb8c..218dcce 100644
--- a/ssl/ssl_locl.h
+++ b/ssl/ssl_locl.h
@@ -259,10 +259,11 @@
   c[1]=(unsigned char)(((l)>> 8)&0xff), \
   c[2]=(unsigned char)(((l))&0xff)),c+=3)
 
-#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
-#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
-#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
-#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
+#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
+#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
+#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
+#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
+#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))
 
 /* LOCAL STUFF */
 
> 
> Having said that, reverting this change isn't *sufficient* to fix
> OpenSSL 1.1; it still fails with 
> 
> DTLS handshake failed: 1
> 67609664:error:14160098:SSL routines:read_state_machine:excessive message 
> size:ssl/statem/statem.c:586:
> 
> ... which goes back to before 1.1.0-pre1. I'll find that one later...

That one's simpler:

diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index 26c4d10..b2160cd 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -704,6 +704,8 @@ unsigned long ossl_statem_client_max_message_size(SSL *s)
 return SERVER_HELLO_DONE_MAX_LENGTH;
 
 case TLS_ST_CR_CHANGE:
+if (s->client_version == DTLS1_BAD_VER)
+return 3;
 return CCS_MAX_LENGTH;
 
 case TLS_ST_CR_SESSION_TICKET:
-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> Reviewed-by: Viktor Dukhovni 
> 
> MR: #1595
> ---
>  ssl/s3_lib.c | 534 
> +++
>  ssl/ssl_ciph.c   | 196 +
>  ssl/ssl_lib.c    |   4 +-
>  ssl/ssl_locl.h   |  21 +-
>  ssl/ssl_txt.c    |   2 +-
>  ssl/statem/statem_clnt.c |  18 +-
>  ssl/statem/statem_lib.c  |   6 +-
>  ssl/t1_lib.c |  41 ++--
>  8 files changed, 504 insertions(+), 318 deletions(-)
> 
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index 51fb161..093ff09 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
>   SSL_aRSA,
>   SSL_eNULL,
>   SSL_MD5,
> - SSL_SSLV3,
> + SSL3_VERSION, TLS1_2_VERSION,
> + DTLS1_VERSION, DTLS1_2_VERSION,

This broke the OpenConnect VPN client, which now fails thus:

DTLS handshake failed: 1
67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
available:ssl/statem/statem_clnt.c:927:

I tried the naïvely obvious step of changing all instances of
DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.


Having said that, reverting this change isn't *sufficient* to fix
OpenSSL 1.1; it still fails with 

DTLS handshake failed: 1
67609664:error:14160098:SSL routines:read_state_machine:excessive message 
size:ssl/statem/statem.c:586:

... which goes back to before 1.1.0-pre1. I'll find that one later...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] PATCH: fix cast-alignment of "struct lhash_st *"

[Salz, Rich]

This looks like a good change.

> This clears what looks to be hundreds of alignment related warnings like
> below.
> 
> $ git diff include/openssl/lhash.h
> diff --git a/include/openssl/lhash.h b/include/openssl/lhash.h index
> 2edd738..5da5054 100644
> --- a/include/openssl/lhash.h
> +++ b/include/openssl/lhash.h
> @@ -180,7 +180,7 @@ void lh_node_usage_stats_bio(const _LHASH *lh, BIO
> *out);  # define LHASH_OF(type) struct lhash_st_##type
> 
>  # define DEFINE_LHASH_OF(type) \
> -LHASH_OF(type) { int dummy; }; \
> +LHASH_OF(type) { unsigned long dummy; }; \
>  static ossl_inline LHASH_OF(type) * \
>  lh_##type##_new(unsigned long (*hfn)(const type *), \
>  int (*cfn)(const type *, const type *)) \

Does changing it to "void *dummy" also work?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[Ángel González]

Thanks for your promptly response, Viktor.
Viktor Dukhovni wrote:
> > On Mar 3, 2016, at 8:07 PM, Ángel González 
> > wrote:
> > 
> > They were showed in the help, but providing them failed with an
> > “unknown option” error, and showed the help which listed it
> > as a valid option.
> The patch is not right.  For example, when TLSv1 is disabled, it is
> not the case that TLSv1.1 and TLSv1.2 are disabled.  

When OPENSSL_NO_TLS1 is disabled, the -tls1_2, -tls1_1 and -tls1
options to s_client are not parsed. See lines 958-964:
> #ifndef OPENSSL_NO_TLS1
> else if (strcmp(*argv, "-tls1_2") == 0)
> meth = TLSv1_2_client_method();
> else if (strcmp(*argv, "-tls1_1") == 0)
> meth = TLSv1_1_client_method();
> else if (strcmp(*argv, "-tls1") == 0)
> meth = TLSv1_client_method();
> #endif

I agree it doesn't seem the best name to control tls 1.2, but I assumed
that they were all using some shared functions so that OPENSSL_NO_TLS1
meant you couldn't use any TLS x function. Also note that there are no
other OPENSSL_NO_TLS* macros which would apply to the minor versions
(the most similar is OPENSSL_NO_TLS1_2_CLIENT).
Do you have more information about *what* is the right behavior here?
Sadly, the macros don't seem to be documented.



> Secondly disabled
> features should report that the feature is disabled, not a bad usage
> message, as would be the case with a mistyped option.

I agree it's a much more sensible way of erroring out, and I would be
happy to prepare a patch that does that. Do note however that such is
the way s_client works, see lines 878-1124 where dozens of argparsing
strcmps are guarded by #ifdefs (as well as on sc_usage() function).
I tried to fix the inconsistency in the least disruptive way.


Additionally, do you have any preference about the branch? I prepared
the patch against the stable branch, since it's the one on which I
noticed the problem, but perhaps you prefer it against to master
instead.

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

Re: [openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[Viktor Dukhovni]

> On Mar 3, 2016, at 8:07 PM, Ángel González  wrote:
> 
> They were showed in the help, but providing them failed with an
> “unknown option” error, and showed the help which listed it
> as a valid option.

The patch is not right.  For example, when TLSv1 is disabled, it is
not the case that TLSv1.1 and TLSv1.2 are disabled.  Secondly disabled
features should report that the feature is disabled, not a bad usage
message, as would be the case with a mistyped option.

> Patch against the stable 1.0.2 branch.
> 
>  apps/s_client.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/apps/s_client.c b/apps/s_client.c
> index 0c1102b..f68c581 100644
> --- a/apps/s_client.c
> +++ b/apps/s_client.c
> @@ -376,16 +376,22 @@ static void sc_usage(void)
> " -srp_strength int - minimal length in bits for N
> (default %d).\n",
> SRP_MINIMAL_N);
>  #endif
> +#ifndef OPENSSL_NO_SSL2
>  BIO_printf(bio_err, " -ssl2 - just use SSLv2\n");
> +#endif
>  #ifndef OPENSSL_NO_SSL3_METHOD
>  BIO_printf(bio_err, " -ssl3 - just use SSLv3\n");
>  #endif
> +#ifndef OPENSSL_NO_TLS1
>  BIO_printf(bio_err, " -tls1_2   - just use TLSv1.2\n");
>  BIO_printf(bio_err, " -tls1_1   - just use TLSv1.1\n");
>  BIO_printf(bio_err, " -tls1 - just use TLSv1\n");
> +#endif
> +#ifndef OPENSSL_NO_DTLS1
>  BIO_printf(bio_err, " -dtls1- just use DTLSv1\n");
> -BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
>  BIO_printf(bio_err, " -mtu  - set the link layer MTU\n");
> +#endif
> +BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
>  BIO_printf(bio_err,
> " -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 -
> turn off that protocol\n");
>  BIO_printf(bio_err,
> -- 
> 2.7.2
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Viktor.

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

[openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[Ángel González]

They were showed in the help, but providing them failed with an
“unknown option” error, and showed the help which listed it
as a valid option.

---

Patch against the stable 1.0.2 branch.

 apps/s_client.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 0c1102b..f68c581 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -376,16 +376,22 @@ static void sc_usage(void)
" -srp_strength int - minimal length in bits for N
(default %d).\n",
SRP_MINIMAL_N);
 #endif
+#ifndef OPENSSL_NO_SSL2
 BIO_printf(bio_err, " -ssl2 - just use SSLv2\n");
+#endif
 #ifndef OPENSSL_NO_SSL3_METHOD
 BIO_printf(bio_err, " -ssl3 - just use SSLv3\n");
 #endif
+#ifndef OPENSSL_NO_TLS1
 BIO_printf(bio_err, " -tls1_2   - just use TLSv1.2\n");
 BIO_printf(bio_err, " -tls1_1   - just use TLSv1.1\n");
 BIO_printf(bio_err, " -tls1 - just use TLSv1\n");
+#endif
+#ifndef OPENSSL_NO_DTLS1
 BIO_printf(bio_err, " -dtls1- just use DTLSv1\n");
-BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
 BIO_printf(bio_err, " -mtu  - set the link layer MTU\n");
+#endif
+BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
 BIO_printf(bio_err,
" -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 -
turn off that protocol\n");
 BIO_printf(bio_err,
-- 
2.7.2
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] [openssl.org #2558] make windres controllable via build env var settings

[Mike Frysinger via RT]

atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools.  So add support for the standard $RC
/ $WINDRES env vars as well.
---
 Configure   | 1 +
 Makefile.in | 2 ++
 Makefile.shared | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Configure b/Configure
index 080bc06..f5b1257 100755
--- a/Configure
+++ b/Configure
@@ -888,6 +888,7 @@ $target{ranlib} = $ENV{'RANLIB'} || $target{ranlib} || 
$default_ranlib;
 $target{ar} = $ENV{'AR'} || "ar";
 $target{arflags} = "" if !defined($target{arflags});
 $target{nm} = "nm";
+$target{windres} = $ENV{'RC'} || $ENV{'WINDRES'} || "windres";
 # Make sure build_scheme is consistent.
 $target{build_scheme} = [ $target{build_scheme} ]
 if ref($target{build_scheme}) ne "ARRAY";
diff --git a/Makefile.in b/Makefile.in
index 30f44ff..0830b88 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -103,6 +103,7 @@ ARFLAGS= {- $target{arflags} -}
 AR=$(CROSS_COMPILE){- $target{ar} -} $(ARFLAGS) r
 RANLIB= {- $target{ranlib} -}
 NM= $(CROSS_COMPILE){- $target{nm} -}
+WINDRES= $(CROSS_COMPILE){- $target{windres} -}
 PERL= {- $config{perl} -}
 #RM= echo --
 RM= rm -f
@@ -254,6 +255,7 @@ BUILDENV=   LC_ALL=C PLATFORM='$(PLATFORM)' 
PROCESSOR='$(PROCESSOR)'\
SHARED_CFLAG='$(SHARED_CFLAG)'  \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+   WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' DYNAMIC_ENGINES='$(DYNAMIC_ENGINES)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index 9028960..adcfe40 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -280,7 +280,7 @@ link_shlib.cygwin:
echo "$(PERL) $(SRCDIR)/util/mkrc.pl $$dll_name |" \
 "$(CROSS_COMPILE)windres $(SHARED_RCFLAGS) -o rc.o"; \
$(PERL) $(SRCDIR)/util/mkrc.pl $$dll_name | \
-   $(CROSS_COMPILE)windres $(SHARED_RCFLAGS) -o rc.o; \
+   $(WINDRES) $(SHARED_RCFLAGS) -o rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared 
-Wl,--enable-auto-image-base -Wl,-Bsymbolic 
-Wl,--out-implib,lib$(LIBNAME).dll.a rc.o"; \
-- 
2.6.2


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

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

Re: [openssl-dev] [PATCH] Add missing semi colon in crypto/o_str.c

[Salz, Rich]

Yes already fixed, thanks.

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

[openssl-dev] [PATCH] Add missing semi colon in crypto/o_str.c

[Masanari Iida]

Missing semi colon cause following error.

Wa,--noexecstack -fPIC   -c -o o_str.o o_str.c
o_str.c: In function 'CRYPTO_strndup':
o_str.c:144:5: error: expected ';' before 'ret'
 ret = CRYPTO_malloc(maxlen + 1, file, line);
 ^
make[1]: *** [o_str.o] Error 1
make[1]: Leaving directory `/home/iida/Repo/openssl/crypto'
make: *** [build_crypto] Error 1

Signed-off-by: Masanari Iida 
---
 crypto/o_str.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/o_str.c b/crypto/o_str.c
index b01128c..84005e6 100644
--- a/crypto/o_str.c
+++ b/crypto/o_str.c
@@ -139,7 +139,7 @@ char *CRYPTO_strndup(const char *str, size_t s, const char* 
file, int line)
 if (str == NULL)
 return NULL;
 
-maxlen = OPENSSL_strnlen(str, s)
+maxlen = OPENSSL_strnlen(str, s);
 
 ret = CRYPTO_malloc(maxlen + 1, file, line);
 if (ret) {
-- 
2.7.2.333.g70bd996

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

[openssl-dev] Patch for grep on Solaris

[Kristian Amlie]

Simple build fix for Solaris. See commit message in the patch for details.

I hope this can make it into the openssl repository.

-- 
Kristian
>From 2e535aeb08ae275c13e93440641a1c4577bbd42d Mon Sep 17 00:00:00 2001
From: Kristian Amlie 
Date: Mon, 18 Jan 2016 15:18:56 +0100
Subject: [PATCH] Don't use "grep -q", "-q" is not POSIX, and fails on
 Solaris.

---
 util/domd |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/domd b/util/domd
index e39d3e3..16de5c7 100755
--- a/util/domd
+++ b/util/domd
@@ -16,8 +16,8 @@ fi
 if [ "$MAKEDEPEND" = "" ]; then MAKEDEPEND=makedepend; fi
 
 cp Makefile Makefile.save
-if ${MAKEDEPEND} --version 2>&1 | grep -q "clang" ||
-   echo $MAKEDEPEND | grep -q "gcc"; then
+if ${MAKEDEPEND} --version 2>&1 | grep "clang" > /dev/null ||
+   echo $MAKEDEPEND | grep "gcc" > /dev/null; then
 args=""
 while [ $# -gt 0 ]; do
 	if [ "$1" != "--" ]; then args="$args $1"; fi
-- 
1.7.9.5

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

Re: [openssl-dev] Patch for grep on Solaris

[Richard Levitte]

In message <569cf670.3020...@cfengine.com> on Mon, 18 Jan 2016 15:28:00 +0100, 
Kristian Amlie  said:

kristian.amlie> Simple build fix for Solaris. See commit message in the patch 
for details.
kristian.amlie> 
kristian.amlie> I hope this can make it into the openssl repository.

On it.  It will hopefully appear fairly soon in our repo.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Patch for grep on Solaris

[Kristian Amlie]

On 18/01/16 15:34, Richard Levitte wrote:
> In message <569cf670.3020...@cfengine.com> on Mon, 18 Jan 2016 15:28:00 
> +0100, Kristian Amlie  said:
> 
> kristian.amlie> Simple build fix for Solaris. See commit message in the patch 
> for details.
> kristian.amlie> 
> kristian.amlie> I hope this can make it into the openssl repository.
> 
> On it.  It will hopefully appear fairly soon in our repo.

I see it's in now. Thanks!

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

Re: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS

[Paul Kehrer]

I can only plead ignorance. Those functions do indeed do what I need. With that 
I don't have any direct need for the d2i implementation, although it is still a 
bit odd for them to be defined on all the other extensions but not 
NAME_CONSTRAINTS.

Thanks for the help!

-Paul

On January 9, 2016 at 7:14:12 PM, Dr. Stephen Henson (st...@openssl.org) wrote:

On Sat, Jan 09, 2016, Paul Kehrer wrote:  

> The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in 
> the current OpenSSL releases. This is inconsistent with other extension 
> structs and (I believe) means you either need to declare them yourself or 
> attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to 
> current git master that adds support for these functions.   
>  
> If there's a preferred way to test that these macros behave as expected I'll 
> be happy to add the tests to this patch.  
>  

Why do you need the i2d/d2i functions? It is possible to encode and decode the  
extension using X509_get_ext_d2i() and X509_add1_ext_i2d().  

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

[openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS

[Paul Kehrer]

The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in the 
current OpenSSL releases. This is inconsistent with other extension structs and 
(I believe) means you either need to declare them yourself or attempt to build 
NAME_CONSTRAINTS using nconf functions. Below is a patch to current git master 
that adds support for these functions. 

If there's a preferred way to test that these macros behave as expected I'll be 
happy to add the tests to this patch.


-Paul Kehrer 



diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c 
index d3f79ba..e679f0a 100644 
--- a/crypto/x509v3/v3_ncons.c 
+++ b/crypto/x509v3/v3_ncons.c 
@@ -109,7 +109,7 @@ ASN1_SEQUENCE(NAME_CONSTRAINTS) = { 
  
  
 IMPLEMENT_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE) 
-IMPLEMENT_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS) 
+IMPLEMENT_ASN1_FUNCTIONS(NAME_CONSTRAINTS) 
  
 static void *v2i_NAME_CONSTRAINTS(const X509V3_EXT_METHOD *method, 
                                   X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval) 
diff --git a/include/openssl/x509v3.h b/include/openssl/x509v3.h 
index b5ea84a..f2e8598 100644 
--- a/include/openssl/x509v3.h 
+++ b/include/openssl/x509v3.h 
@@ -591,7 +591,7 @@ DECLARE_ASN1_ITEM(GENERAL_SUBTREE) 
 DECLARE_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE) 
  
 DECLARE_ASN1_ITEM(NAME_CONSTRAINTS) 
-DECLARE_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS) 
+DECLARE_ASN1_FUNCTIONS(NAME_CONSTRAINTS) 
  
 DECLARE_ASN1_ALLOC_FUNCTIONS(POLICY_CONSTRAINTS) 
 DECLARE_ASN1_ITEM(POLICY_CONSTRAINTS) 


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

Re: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS

[Salz, Rich]

You might also take a look at https://rt.openssl.org/Ticket/Display.html?id=3502


--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


> -Original Message-
> From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
> Sent: Saturday, January 09, 2016 3:20 PM
> To: openssl-dev@openssl.org
> Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for
> NAME_CONSTRAINTS
> 
> The ASN1 functions for NAME_CONSTRAINTS are not declared or
> implemented in the current OpenSSL releases. This is inconsistent with other
> extension structs and (I believe) means you either need to declare them
> yourself or attempt to build NAME_CONSTRAINTS using nconf functions.
> Below is a patch to current git master that adds support for these functions.
> 
> If there's a preferred way to test that these macros behave as expected I'll
> be happy to add the tests to this patch.
> 
> 
> -Paul Kehrer
> 
> 
> 
> diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c index
> d3f79ba..e679f0a 100644
> --- a/crypto/x509v3/v3_ncons.c
> +++ b/crypto/x509v3/v3_ncons.c
> @@ -109,7 +109,7 @@ ASN1_SEQUENCE(NAME_CONSTRAINTS) = {
> 
> 
>  IMPLEMENT_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)
> -IMPLEMENT_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)
> +IMPLEMENT_ASN1_FUNCTIONS(NAME_CONSTRAINTS)
> 
>  static void *v2i_NAME_CONSTRAINTS(const X509V3_EXT_METHOD
> *method,
>                                    X509V3_CTX *ctx, STACK_OF(CONF_VALUE) 
> *nval) diff --git
> a/include/openssl/x509v3.h b/include/openssl/x509v3.h index
> b5ea84a..f2e8598 100644
> --- a/include/openssl/x509v3.h
> +++ b/include/openssl/x509v3.h
> @@ -591,7 +591,7 @@ DECLARE_ASN1_ITEM(GENERAL_SUBTREE)
>  DECLARE_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)
> 
>  DECLARE_ASN1_ITEM(NAME_CONSTRAINTS)
> -DECLARE_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)
> +DECLARE_ASN1_FUNCTIONS(NAME_CONSTRAINTS)
> 
>  DECLARE_ASN1_ALLOC_FUNCTIONS(POLICY_CONSTRAINTS)
>  DECLARE_ASN1_ITEM(POLICY_CONSTRAINTS)
> 
> 
> ___
> 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] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS

[Dr. Stephen Henson]

On Sat, Jan 09, 2016, Paul Kehrer wrote:

> The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in 
> the current OpenSSL releases. This is inconsistent with other extension 
> structs and (I believe) means you either need to declare them yourself or 
> attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to 
> current git master that adds support for these functions. 
> 
> If there's a preferred way to test that these macros behave as expected I'll 
> be happy to add the tests to this patch.
> 

Why do you need the i2d/d2i functions? It is possible to encode and decode the
extension using X509_get_ext_d2i() and X509_add1_ext_i2d().

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

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Alessandro Ghedini]

On Wed, Jan 06, 2016 at 06:21:13AM +, Viktor Dukhovni wrote:
> On Tue, Jan 05, 2016 at 02:44:32PM -0800, Zi Lin wrote:
> 
> > Hi OpenSSL devs,
> > 
> > I want to propose a patch that makes OpenSSL compatible with
> > asynchronous session lookup during session resumption.
> 
> I think this is a bad idea.  If you want distributed session caches
> use session tickets,

That's not really a solution if the client doesn't support session tickets at
all. So in those cases you are left with doing no resumption or doing it
synchronously with session id in an inefficient way.

I think that with the new state machine in master this could be implemented
fairly elegantly and since there's an interest from OpenSSL users (even
BoringSSL provides this!) it seems like something worth implementing to me.

Cheers


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

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Matt Caswell]

On 06/01/16 06:14, Zi Lin wrote:
> Hi Matt,
> 
> thanks for your time. I am glad to see the big efforts done to make
> OpenSSL code better in the master branch (and v1.1.0+). I will find a
> way to start working on the master branch. A quick glance into the
> master branch state machine: the get_prev_session call happens in
> process_message "phase", and dealing with cert_cb happens in
> post_process_message "phase". Moving get_prev_session into
> post_processing_message "phase" seems non trivial as all those cipher
> check are in the process_messaage "phase", depending on resumed
> session.
> 
> Further, I see this comment. Can you clarify what that means?
> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L1150
> Only session ticket and further TLS1.3 session resumption are
> supported in v1.1+?

This comment is in specific reference to SSLv2 backwards compatible
ClientHellos. While support for SSLv2 itself has been removed from
1.1.0, we still accept SSLv2 backward compat ClientHellos. However we
will not allow session resumption in such an instance: if we are
resuming a session then we must have previously negotiated a version >
SSLv2 so it makes no sense for a client to send a backward compat
ClientHello.

Matt

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

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Viktor Dukhovni]

On Tue, Jan 05, 2016 at 02:44:32PM -0800, Zi Lin wrote:

> Hi OpenSSL devs,
> 
> I want to propose a patch that makes OpenSSL compatible with
> asynchronous session lookup during session resumption.

I think this is a bad idea.  If you want distributed session caches
use session tickets, and implement a distributed mechanism for
rotating the keys across the server farm.  Actually, there's an RT
ticket for that, but the code is not quite what I'd like to see
adopted, and is no longer compatible with the substantially modified
SSL library in 1.1.0.  So I'll likely just implement session ticket
key management from scratch when I get a chance.

I would strongly recommend against a distributed session store.

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

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Zi Lin]

Hi Matt,

thanks for your time. I am glad to see the big efforts done to make
OpenSSL code better in the master branch (and v1.1.0+). I will find a
way to start working on the master branch. A quick glance into the
master branch state machine: the get_prev_session call happens in
process_message "phase", and dealing with cert_cb happens in
post_process_message "phase". Moving get_prev_session into
post_processing_message "phase" seems non trivial as all those cipher
check are in the process_messaage "phase", depending on resumed
session.

Further, I see this comment. Can you clarify what that means?
https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L1150
Only session ticket and further TLS1.3 session resumption are
supported in v1.1+?

Best,

Zi

On Tue, Jan 5, 2016 at 9:37 PM, Matt Caswell  wrote:
> On 05/01/16 22:44, Zi Lin wrote:
>> Hi OpenSSL devs,
>>
>> I want to propose a patch that makes OpenSSL compatible with
>> asynchronous session lookup during session resumption. Currently, the
>> session lookup expects the session callback to return immediately with
>> success or failure. Now consider a cluster of hosts that want to pool
>> the ssl session together to improve session resumption, we would like
>> the session lookup callback to adopt the asynchronous paradigm of
>> "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb
>> finished its job.
>> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916
>>
>> Piotr Sikora initiated this project with ideas borrowed from BoringSSL
>> code base,
>> and since we have put some efforts to make sure no bug is introduced.
>>
>> Hence this attached patch to enable "get_session_cb" to return a fake
>> session pointer that signals the pending session lookup, and the SSL
>> state machines will adopts such signal to resume the client hello
>> processing instead of err-out. It's not a small patch since we have
>> touched multiple aspects of the SSL state machine. But this patch has
>> been verified in CloudFlare's heavy traffic production environment for quite 
>> a
>> while and we consider it is stable to be used by upstream.
>
> Hi Zi
>
> That is an interesting idea and something we may consider looking at.
> However your patch in its current form cannot be accepted because it
> targets 1.0.2. Such a change would be considered a new feature. The
> 1.0.2 branch only receives bug fixes. New features should target the
> master branch.
>
> If you take a look at master you will see that there have been
> substantial and fundamental changes to the state machine code so your
> patch would need significant work to bring it into line.
>
> BTW, please email any future submissions to r...@openssl.org so that they
> can be properly tracked.
>
> Thanks
>
> Matt
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Matt Caswell]

On 05/01/16 22:44, Zi Lin wrote:
> Hi OpenSSL devs,
> 
> I want to propose a patch that makes OpenSSL compatible with
> asynchronous session lookup during session resumption. Currently, the
> session lookup expects the session callback to return immediately with
> success or failure. Now consider a cluster of hosts that want to pool
> the ssl session together to improve session resumption, we would like
> the session lookup callback to adopt the asynchronous paradigm of
> "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb
> finished its job.
> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916
> 
> Piotr Sikora initiated this project with ideas borrowed from BoringSSL
> code base,
> and since we have put some efforts to make sure no bug is introduced.
> 
> Hence this attached patch to enable "get_session_cb" to return a fake
> session pointer that signals the pending session lookup, and the SSL
> state machines will adopts such signal to resume the client hello
> processing instead of err-out. It's not a small patch since we have
> touched multiple aspects of the SSL state machine. But this patch has
> been verified in CloudFlare's heavy traffic production environment for quite a
> while and we consider it is stable to be used by upstream.

Hi Zi

That is an interesting idea and something we may consider looking at.
However your patch in its current form cannot be accepted because it
targets 1.0.2. Such a change would be considered a new feature. The
1.0.2 branch only receives bug fixes. New features should target the
master branch.

If you take a look at master you will see that there have been
substantial and fundamental changes to the state machine code so your
patch would need significant work to bring it into line.

BTW, please email any future submissions to r...@openssl.org so that they
can be properly tracked.

Thanks

Matt


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

[openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Zi Lin]

Hi OpenSSL devs,

I want to propose a patch that makes OpenSSL compatible with
asynchronous session lookup during session resumption. Currently, the
session lookup expects the session callback to return immediately with
success or failure. Now consider a cluster of hosts that want to pool
the ssl session together to improve session resumption, we would like
the session lookup callback to adopt the asynchronous paradigm of
"cert_cb", i.e. cert_cb can be called repeatedly until cert_cb
finished its job.
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916

Piotr Sikora initiated this project with ideas borrowed from BoringSSL
code base,
and since we have put some efforts to make sure no bug is introduced.

Hence this attached patch to enable "get_session_cb" to return a fake
session pointer that signals the pending session lookup, and the SSL
state machines will adopts such signal to resume the client hello
processing instead of err-out. It's not a small patch since we have
touched multiple aspects of the SSL state machine. But this patch has
been verified in CloudFlare's heavy traffic production environment for quite a
while and we consider it is stable to be used by upstream.

Any feedback is appreciated!

Best,

Zi


openssl-async-session-lookup.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] Fix error in generated libeay32.def for OPENSSL_NO_ENGINE

[Mladen Turk]

Patch fixes
LIBEAY32.def : error LNK2001: unresolved external symbol 
TS_CONF_set_crypto_device
LIBEAY32.def : error LNK2001: unresolved external symbol 
TS_CONF_set_default_engine
caused by always adding those functions to .def file
Ensure they are added only if engine is not disabled


Regards
--
^TM
--- openssl-1.0.2c/util/libeay.num.org	2015-06-12 17:10:24.0 +0200
+++ openssl-1.0.2c/util/libeay.num	2015-10-23 10:42:10.137998838 +0200
@@ -3872,7 +3872,7 @@
 ASN1_UTCTIME_adj4251	EXIST::FUNCTION:
 TS_TST_INFO_new 4252	EXIST::FUNCTION:
 EVP_MD_do_all_sorted4253	EXIST::FUNCTION:
-TS_CONF_set_default_engine  4254	EXIST::FUNCTION:
+TS_CONF_set_default_engine  4254	EXIST::FUNCTION:ENGINE
 TS_ACCURACY_set_seconds 4255	EXIST::FUNCTION:
 TS_TST_INFO_get_time4256	EXIST::FUNCTION:
 PKCS8_pkey_get0 4257	EXIST::FUNCTION:
@@ -4097,7 +4097,7 @@
 EVP_PKEY_id 4470	EXIST::FUNCTION:
 TS_TST_INFO_set_serial  4471	EXIST::FUNCTION:
 a2i_GENERAL_NAME4472	EXIST::FUNCTION:
-TS_CONF_set_crypto_device   4473	EXIST::FUNCTION:
+TS_CONF_set_crypto_device   4473	EXIST::FUNCTION:ENGINE
 EVP_PKEY_verify_init4474	EXIST::FUNCTION:
 TS_CONF_set_policies4475	EXIST::FUNCTION:
 ASN1_PCTX_new   4476	EXIST::FUNCTION:
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined

[John Peck]

I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable 
branch build fails during the link step with unresolved symbol EVP_sha384.  The 
attached patch fixes this issue. 

p...@bay2sierra.com 
Mobile: +1-415-420-8449 

From 235d61e3b8d1c0635d18216384c72cdeded3c961 Mon Sep 17 00:00:00 2001
From: John Peck 
Date: Fri, 9 Oct 2015 09:29:08 -0700
Subject: [PATCH] Fixed compile error when OPENSSL_NO_SHA512 is defined

---
 ssl/t1_lib.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 210a5e8..8db3b93 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -886,8 +886,10 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 /* Check to see we have necessary signing algorithm */
 if (curve_id[1] == TLSEXT_curve_P_256)
 check_md = NID_ecdsa_with_SHA256;
+# ifndef OPENSSL_NO_SHA512
 else if (curve_id[1] == TLSEXT_curve_P_384)
 check_md = NID_ecdsa_with_SHA384;
+# endif
 else
 return 0;   /* Should never happen */
 for (i = 0; i < c->shared_sigalgslen; i++)
@@ -899,7 +901,11 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 if (check_md == NID_ecdsa_with_SHA256)
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha256();
 else
+# ifndef OPENSSL_NO_SHA512
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha384();
+# else
+	return 0; 	/* Should never happen */
+# endif
 }
 }
 return rv;
-- 
1.9.1

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

Re: [openssl-dev] [PATCH] GOST engine and custom paramsets

[Arseniy Ankudinov]

15.08.2015 19:29, Victor Wagner:
 On Sat, 15 Aug 2015 14:52:29 +0300
 Dmitry Belyavsky beld...@gmail.com wrote:
 
 Hello Arseniy,

 On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov
 a.ankudi...@drweb.com wrote:

 We strictly need use our custom paramsets for GOST algorithms (all
 of cipher, hash and signature,
 including X509 and TLS). If most of the functionality may be
 implemented by dirty overriding
 initialization methods, X509 requires ccgost engine sources
 patching.

 Seems 2 ways:
 1. Put our paramsets into ccgost sources and simple support for
 several paramsets in ASN1 hash
 params serializing.
 2. Allow set any paramset from outside.

 First way seems the simplest, but second - more universal and
 useful.


 The 2nd way is not universal until the GOST algorithms become the
 1st-class citizens. And becoming the 1st-class citizens is hardly
 possible. So the patch you suggest is engine-specific, and it means
 that it will be unsuitable for any other implementation.
 
 I think it would be nice to provide ability to set parameters from the
 parameter file same way as dsa and ec keys do. I don't like the idea of
 running separate command to create parameter file which contain just
 curve OID, it is why currently GOST engine accept paramset name as key
 generation parameter. But accepting either paramset name or parameter
 file with actual curve parameters seems to be feasible.
 
 S-Blocks for algorithms, derived from GOST 28147-89 also can be handled
 this way.
 
 For MAC it would look like
 
 openssl dgst -mac gost-mac -macopt paramfile:filename -macopt key:...
 
 Digest and encryption algorithms now do not have support for calling
 control function with arbitrary command from the command line utility,
 but control functions present in EVP_MD and EVP_CIPHER structures.
 
 ASN.1 structures for parameters are defined in the RFC 4357. So presence
 of such feature in the reference implementation may influence authors
 of other implementations.
 
 There are various legacy software packages which use non RFC 4357
 parameters for all algorithms, So support for explicitely specifying
 parameters would greatly help people who need to interoperate with them,

Hmm, your suggestion looks interesting.

Yet seen an unsolved problem. Pkey, X509 and key exchange asn1 structures for 
GOST algorithms store
paramsets as OIDs, without parameters embedding. So peers must know mapping 
from OID to
parameters, but I don't see good way to set these mappings through high-level 
APIs. Or set it for
s_client tool (non-authenticated), for example.

Maybe make it through config? Add sections for 281473411/3410-94/3410-2001 
paramsets, like this:

[new_oids]
id-Gost28147-89-My-Paramset = 1.3.6.1.4.1.29690.2.2.1
id-GostR3410-2001-My-Paramset = 1.3.6.1.4.1.29690.2.2.2

[gost_section]
paramsets_28147 = my_gost_sblocks
paramsets_3410_2001 = my_gost_curves
...

[my_gost_sblocks]
# similar to X509v3 extensions conf
id-Gost28147-89-My-Paramset = ASN1:UTF8String:...

[my_gost_curves]
id-GostR3410-2001-My-Paramset = ASN1:UTF8String:...



 Our current implementation for second way (see attached patch)
 requires ccgost engine directly
 using, not only through high-level APIs.

 Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and
 GOST R 34.11-94, with one paramset
 for cipher and hash):

 1. Add custom paramsets to chains:

   gost2001_paramset_append( gost2001_custom_paramset );
   gost_cipher_list_append( gost89_custom_paramset );

 2. Make private key for certificate:

   EC_KEY *ec( EC_KEY_new() );
   BN_CTX *ctx( BN_CTX_new() );
   BN_CTX_start( ctx );
   EC_GROUP
 *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p,
 gost2001_custom_paramset-a, gost2001_custom_paramset-b, ctx ) );
   EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet
 ); EC_POINT *P( EC_POINT_new( grp ) );
   EC_POINT_set_affine_coordinates_GFp( grp, P,
 gost2001_custom_paramset-x, gost2001_custom_paramset-y, ctx );
   EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 );
   EC_KEY_set_group( ec, grp );
   BN_CTX_end( ctx );

   EVP_PKEY *pkey( EVP_PKEY_new() );
   EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec );

   GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey );
   ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet;
   ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet;

 Can this feature be useful for the community? And which way seems
 be more useful?
 --
 With best regards, Arseniy Ankudinov
 Software Engineer, Doctor Web Ltd


 ___
 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
 


-- 
With best regards, Arseniy Ankudinov
Software Engineer, Doctor Web Ltd
___
openssl-dev mailing list
To unsubscribe: 

Re: [openssl-dev] [PATCH] GOST engine and custom paramsets

[Dmitry Belyavsky]

Hello Arseniy,

On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov a.ankudi...@drweb.com
wrote:

 We strictly need use our custom paramsets for GOST algorithms (all of
 cipher, hash and signature,
 including X509 and TLS). If most of the functionality may be implemented
 by dirty overriding
 initialization methods, X509 requires ccgost engine sources patching.

 Seems 2 ways:
 1. Put our paramsets into ccgost sources and simple support for several
 paramsets in ASN1 hash
 params serializing.
 2. Allow set any paramset from outside.

 First way seems the simplest, but second - more universal and useful.


The 2nd way is not universal until the GOST algorithms become the 1st-class
citizens. And becoming the 1st-class citizens is hardly possible.
So the patch you suggest is engine-specific, and it means that it will be
unsuitable for any other implementation.


 Our current implementation for second way (see attached patch) requires
 ccgost engine directly
 using, not only through high-level APIs.

 Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R
 34.11-94, with one paramset
 for cipher and hash):

 1. Add custom paramsets to chains:

   gost2001_paramset_append( gost2001_custom_paramset );
   gost_cipher_list_append( gost89_custom_paramset );

 2. Make private key for certificate:

   EC_KEY *ec( EC_KEY_new() );
   BN_CTX *ctx( BN_CTX_new() );
   BN_CTX_start( ctx );
   EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p,
 gost2001_custom_paramset-a,
 gost2001_custom_paramset-b, ctx ) );
   EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet );
   EC_POINT *P( EC_POINT_new( grp ) );
   EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x,
 gost2001_custom_paramset-y, ctx );
   EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 );
   EC_KEY_set_group( ec, grp );
   BN_CTX_end( ctx );

   EVP_PKEY *pkey( EVP_PKEY_new() );
   EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec );

   GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey );
   ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet;
   ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet;

 Can this feature be useful for the community? And which way seems be more
 useful?
 --
 With best regards, Arseniy Ankudinov
 Software Engineer, Doctor Web Ltd


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




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

Re: [openssl-dev] [PATCH] GOST engine and custom paramsets

[Victor Wagner]

On Sat, 15 Aug 2015 14:52:29 +0300
Dmitry Belyavsky beld...@gmail.com wrote:

 Hello Arseniy,
 
 On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov
 a.ankudi...@drweb.com wrote:
 
  We strictly need use our custom paramsets for GOST algorithms (all
  of cipher, hash and signature,
  including X509 and TLS). If most of the functionality may be
  implemented by dirty overriding
  initialization methods, X509 requires ccgost engine sources
  patching.
 
  Seems 2 ways:
  1. Put our paramsets into ccgost sources and simple support for
  several paramsets in ASN1 hash
  params serializing.
  2. Allow set any paramset from outside.
 
  First way seems the simplest, but second - more universal and
  useful.
 
 
 The 2nd way is not universal until the GOST algorithms become the
 1st-class citizens. And becoming the 1st-class citizens is hardly
 possible. So the patch you suggest is engine-specific, and it means
 that it will be unsuitable for any other implementation.

I think it would be nice to provide ability to set parameters from the
parameter file same way as dsa and ec keys do. I don't like the idea of
running separate command to create parameter file which contain just
curve OID, it is why currently GOST engine accept paramset name as key
generation parameter. But accepting either paramset name or parameter
file with actual curve parameters seems to be feasible.

S-Blocks for algorithms, derived from GOST 28147-89 also can be handled
this way.

For MAC it would look like

openssl dgst -mac gost-mac -macopt paramfile:filename -macopt key:...

Digest and encryption algorithms now do not have support for calling
control function with arbitrary command from the command line utility,
but control functions present in EVP_MD and EVP_CIPHER structures.

ASN.1 structures for parameters are defined in the RFC 4357. So presence
of such feature in the reference implementation may influence authors
of other implementations.

There are various legacy software packages which use non RFC 4357
parameters for all algorithms, So support for explicitely specifying
parameters would greatly help people who need to interoperate with them,


 
 
  Our current implementation for second way (see attached patch)
  requires ccgost engine directly
  using, not only through high-level APIs.
 
  Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and
  GOST R 34.11-94, with one paramset
  for cipher and hash):
 
  1. Add custom paramsets to chains:
 
gost2001_paramset_append( gost2001_custom_paramset );
gost_cipher_list_append( gost89_custom_paramset );
 
  2. Make private key for certificate:
 
EC_KEY *ec( EC_KEY_new() );
BN_CTX *ctx( BN_CTX_new() );
BN_CTX_start( ctx );
EC_GROUP
  *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p,
  gost2001_custom_paramset-a, gost2001_custom_paramset-b, ctx ) );
EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet
  ); EC_POINT *P( EC_POINT_new( grp ) );
EC_POINT_set_affine_coordinates_GFp( grp, P,
  gost2001_custom_paramset-x, gost2001_custom_paramset-y, ctx );
EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 );
EC_KEY_set_group( ec, grp );
BN_CTX_end( ctx );
 
EVP_PKEY *pkey( EVP_PKEY_new() );
EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec );
 
GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey );
ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet;
ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet;
 
  Can this feature be useful for the community? And which way seems
  be more useful?
  --
  With best regards, Arseniy Ankudinov
  Software Engineer, Doctor Web Ltd
 
 
  ___
  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] [PATCH] GOST engine and custom paramsets

[Arseniy Ankudinov]

We strictly need use our custom paramsets for GOST algorithms (all of cipher, 
hash and signature,
including X509 and TLS). If most of the functionality may be implemented by 
dirty overriding
initialization methods, X509 requires ccgost engine sources patching.

Seems 2 ways:
1. Put our paramsets into ccgost sources and simple support for several 
paramsets in ASN1 hash
params serializing.
2. Allow set any paramset from outside.

First way seems the simplest, but second - more universal and useful.

Our current implementation for second way (see attached patch) requires ccgost 
engine directly
using, not only through high-level APIs.

Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R 
34.11-94, with one paramset
for cipher and hash):

1. Add custom paramsets to chains:

  gost2001_paramset_append( gost2001_custom_paramset );
  gost_cipher_list_append( gost89_custom_paramset );

2. Make private key for certificate:

  EC_KEY *ec( EC_KEY_new() );
  BN_CTX *ctx( BN_CTX_new() );
  BN_CTX_start( ctx );
  EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p, 
gost2001_custom_paramset-a,
gost2001_custom_paramset-b, ctx ) );
  EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet );
  EC_POINT *P( EC_POINT_new( grp ) );
  EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x,
gost2001_custom_paramset-y, ctx );
  EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 );
  EC_KEY_set_group( ec, grp );
  BN_CTX_end( ctx );

  EVP_PKEY *pkey( EVP_PKEY_new() );
  EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec );

  GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey );
  ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet;
  ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet;

Can this feature be useful for the community? And which way seems be more 
useful?
-- 
With best regards, Arseniy Ankudinov
Software Engineer, Doctor Web Ltd

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: text/x-patch;
 name=tls_gost_custom_paramsets.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=tls_gost_custom_paramsets.patch


diff -Naur --no-dereference openssl-1.0.2d/crypto/crypto.h openssl-1.0.2d.new/crypto/crypto.h
--- openssl-1.0.2d/crypto/crypto.h	2015-07-09 11:53:21.0 +
+++ openssl-1.0.2d.new/crypto/crypto.h	2015-08-07 06:09:44.0 +
@@ -332,6 +332,7 @@
 # define CRYPTO_EX_INDEX_ECDH13
 # define CRYPTO_EX_INDEX_COMP14
 # define CRYPTO_EX_INDEX_STORE   15
+# define CRYPTO_EX_INDEX_GOST341016
 
 /*
  * Dynamically assigned indexes start from this value (don't use directly,
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/Makefile openssl-1.0.2d.new/engines/ccgost/Makefile
--- openssl-1.0.2d/engines/ccgost/Makefile	2015-07-09 12:03:07.0 +
+++ openssl-1.0.2d.new/engines/ccgost/Makefile	2015-08-07 06:09:44.0 +
@@ -8,9 +8,9 @@
 CFLAGS= $(INCLUDES) $(CFLAG)
 LIB=$(TOP)/libcrypto.a
 
-LIBSRC= gost2001.c gost2001_keyx.c gost89.c gost94_keyx.c gost_ameth.c gost_asn1.c gost_crypt.c gost_ctl.c gost_eng.c gosthash.c gost_keywrap.c gost_md.c gost_params.c gost_pmeth.c gost_sign.c
+LIBSRC= gost2001.c gost2001_keyx.c gost89.c gost94_keyx.c gost_ameth.c gost_asn1.c gost_crypt.c gost_ctl.c gost_eng.c gosthash.c gost_keywrap.c gost_lib.c gost_md.c gost_params.c gost_pmeth.c gost_sign.c
 
-LIBOBJ= e_gost_err.o gost2001_keyx.o gost2001.o gost89.o gost94_keyx.o gost_ameth.o gost_asn1.o gost_crypt.o gost_ctl.o gost_eng.o gosthash.o gost_keywrap.o gost_md.o gost_params.o gost_pmeth.o gost_sign.o
+LIBOBJ= e_gost_err.o gost2001_keyx.o gost2001.o gost89.o gost94_keyx.o gost_ameth.o gost_asn1.o gost_crypt.o gost_ctl.o gost_eng.o gosthash.o gost_keywrap.o gost_lib.o gost_md.o gost_params.o gost_pmeth.o gost_sign.o
 
 SRC=$(LIBSRC)
 
@@ -274,3 +274,4 @@
 gost_sign.o: e_gost_err.h gost89.h gost_lcl.h gost_params.h gost_sign.c
 gost_sign.o: gosthash.h
 gosthash.o: gost89.h gosthash.c gosthash.h
+gost_lib.o: e_gost_err.h gost89.h gost_lcl.h gost_lib.c gosthash.h
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/e_gost_err.c openssl-1.0.2d.new/engines/ccgost/e_gost_err.c
--- openssl-1.0.2d/engines/ccgost/e_gost_err.c	2015-07-09 11:53:21.0 +
+++ openssl-1.0.2d.new/engines/ccgost/e_gost_err.c	2015-08-07 06:09:44.0 +
@@ -115,6 +115,8 @@
 {ERR_FUNC(GOST_F_PUB_ENCODE_GOST01), PUB_ENCODE_GOST01},
 {ERR_FUNC(GOST_F_UNPACK_CC_SIGNATURE), UNPACK_CC_SIGNATURE},
 {ERR_FUNC(GOST_F_UNPACK_CP_SIGNATURE), UNPACK_CP_SIGNATURE},
+{ERR_FUNC(GOST_F_ECGOST_DATA_NEW_METHOD), ECGOST_DATA_NEW_METHOD},
+{ERR_FUNC(GOST_F_GOST3410_EX_DATA_NEW_METHOD), GOST3410_EX_DATA_NEW_METHOD},
 {0, NULL}
 };
 
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/e_gost_err.h openssl-1.0.2d.new/engines/ccgost/e_gost_err.h
--- 

Re: [openssl-dev] [PATCH] Fix broken argument parsing for genrsa

[Salz, Rich]

 See the Feedback and Contributions section on the main wiki page:
 https://wiki.openssl.org/index.php/Main_Page
 
 Also this page:
 https://wiki.openssl.org/index.php/Use_of_Git
 
 Also some stuff here:
 https://wiki.openssl.org/index.php/Developing_For_OpenSSL
 
 On the website here:
 https://www.openssl.org/support/rt.html
 
 And of course also in the README.

All fixed.

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

Re: [openssl-dev] [PATCH] Fix broken argument parsing for genrsa

[Matt Caswell]

On 28/07/15 16:22, Adam Eijdenberg wrote:
 Sorry Rich, I didn't mean to imply it was (especially since it included
 the weekend!) - I'm still trying to understand the correct workflow for
 this project - do you normally prefer mail to this list or pull requests
 with that type of patch?  The README file talks about sending patches to
 this list, whereas the Wiki talks about GitHub pull requests so I wanted
 to make sure I was following the right process.

We really need to sort that out! :-)

The preferred approach is an email to r...@openssl.org either with patches
attached or with a referenced github pull request.

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

Re: [openssl-dev] [PATCH] Fix broken argument parsing for genrsa

[Adam Eijdenberg]

Sorry Rich, I didn't mean to imply it was (especially since it included the
weekend!) - I'm still trying to understand the correct workflow for this
project - do you normally prefer mail to this list or pull requests with
that type of patch?  The README file talks about sending patches to this
list, whereas the Wiki talks about GitHub pull requests so I wanted to make
sure I was following the right process.

Cheers, Adam

On Tue, Jul 28, 2015 at 8:14 AM Salz, Rich rs...@akamai.com wrote:

  We saw your pull request.  Three days is not a long time.
  ___
 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] [PATCH] Fix broken argument parsing for genrsa

[Salz, Rich]

We saw your pull request.  Three days is not a long time.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] Fix broken argument parsing for genrsa

[Adam Eijdenberg]

HI openssl-dev,

This is my first patch, so hope I'm following the right process.  The
argument parsing for openssl genrsa is missing a break; statement and
as a consequence control the users gets a set of spurious warnings about a
missing engine that they didn't actually intentionally specify.  A quick
grep found 2 other similar issues.

I created a pull request on Friday (
https://github.com/openssl/openssl/pull/339) but since I didn't hear
anything there I am attaching the small (3 line) patch to this message.

Cheers, Adam
From 36f4de1c10acb4b16fd9dda01d3389f28b15da46 Mon Sep 17 00:00:00 2001
From: Adam Eijdenberg adam.eijdenb...@gmail.com
Date: Fri, 24 Jul 2015 19:27:39 -0700
Subject: [PATCH] Fix missing break for -out argument parsing that causes
 genrsa to attempt to load engine with name of out.key.

e.g. without fix, operation succeeds but with warnings:

$ apps/openssl genrsa -out out.key
invalid engine out.key
140735214080848:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared 
library:dso_dlfcn.c:172:filename(/usr/local/ssl/lib/engines/libout.key.dylib): 
dlopen(/usr/local/ssl/lib/engines/libout.key.dylib, 2): image not found
140735214080848:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:228:
140735214080848:error:260B6084:engine routines:DYNAMIC_LOAD:dso not 
found:eng_dyn.c:458:
140735214080848:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:eng_list.c:379:id=out.key
140735214080848:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared library:dso_dlfcn.c:172:filename(libout.key.dylib): 
dlopen(libout.key.dylib, 2): image not found
140735214080848:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:228:
140735214080848:error:260B6084:engine routines:DYNAMIC_LOAD:dso not 
found:eng_dyn.c:458:
Generating RSA private key, 2048 bit long modulus
.+++
.+++
e is 65537 (0x010001)

A quick grep for = on a line before case found two other similar issues 
addressed in same commit.
---
 apps/genrsa.c  | 1 +
 apps/pkeyutl.c | 1 +
 apps/req.c | 1 -
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/apps/genrsa.c b/apps/genrsa.c
index bb8437f..1fea351 100644
--- a/apps/genrsa.c
+++ b/apps/genrsa.c
@@ -141,6 +141,7 @@ int genrsa_main(int argc, char **argv)
 break;
 case OPT_OUT:
 outfile = opt_arg();
+break;
 case OPT_ENGINE:
 e = setup_engine(opt_arg(), 0);
 break;
diff --git a/apps/pkeyutl.c b/apps/pkeyutl.c
index 4c267c1..741dd64 100644
--- a/apps/pkeyutl.c
+++ b/apps/pkeyutl.c
@@ -200,6 +200,7 @@ int pkeyutl_main(int argc, char **argv)
 break;
 case OPT_REV:
 rev = 1;
+break;
 case OPT_ENCRYPT:
 pkey_op = EVP_PKEY_OP_ENCRYPT;
 break;
diff --git a/apps/req.c b/apps/req.c
index b3220ba..a16febd 100644
--- a/apps/req.c
+++ b/apps/req.c
@@ -344,7 +344,6 @@ int req_main(int argc, char **argv)
 case OPT_NO_ASN1_KLUDGE:
 kludge = 0;
 break;
-multirdn = 1;
 case OPT_DAYS:
 days = atoi(opt_arg());
 break;
-- 
2.5.0.rc2.392.g76e840b

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

Re: [openssl-dev] [PATCH] Fix broken argument parsing for genrsa

[Matt Caswell]

On 28/07/15 16:54, Salz, Rich wrote:
 or pull requests with that type of patch?  The README file talks about
 sending patches to this list, whereas the Wiki talks about GitHub pull
 requests so I wanted to make sure I was following the right process.

 We really need to sort that out! :-)
 
 Can you point me to the wiki page? I'll fix it.  And update the README.

We have this documented (inconsistently) in a few different places:

See the Feedback and Contributions section on the main wiki page:
https://wiki.openssl.org/index.php/Main_Page

Also this page:
https://wiki.openssl.org/index.php/Use_of_Git

Also some stuff here:
https://wiki.openssl.org/index.php/Developing_For_OpenSSL

On the website here:
https://www.openssl.org/support/rt.html

And of course also in the README.


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

[openssl-dev] [PATCH] to fix hang in RAND_poll on Windows 7 / Server 2008R2 and other performance problems

[Adam Walling]

When Heap32First is called while RtlAllocateHeap is executing on
another thread, the process can deadlock. The underlying bug has a
hotfix from Microsoft, but is not part of a service pack. Only Windows
7 or 2008R2 are affected:

https://support.microsoft.com/en-us/kb/2719306

Deadlock noted in various places, such as:

http://rt.openssl.org/Ticket/Display.html?id=2485user=guestpass=guest
http://comments.gmane.org/gmane.comp.encryption.openssl.devel/20440

And the performance was discussed and had workarounds as noted here:

http://rt.openssl.org/Ticket/Display.html?id=2100user=guestpass=guest

The discussion here:

http://openssl.6102.n7.nabble.com/Deadlock-in-RAND-poll-s-Heap32First-call-td13043.html

proposed a similar solution to this, but discussion diverged from the
actual problem.

While using the heap as a source of entropy is debatable, we can still
fix this issue while also avoiding the performance issue that was
already patched with the workaround.

In the existing code, the process ID of 0 is passed to
CreateToolhelp32Snapshot, so it only iterates the heaps of the current
process. This patch uses HeapWalk to implement the same behavior in a
safer manner; toolhelp is still used to iterate the modules, threads,
processes for entropy. HeapWalk and other functions used by this patch
are available since NT 3.51, though they are dynamically loaded
anyway.

Most of the time, a windows process will only have or use one heap,
but sometimes private heaps are used. However they cannot really be
traversed safely since some may be created without serialization. The
attached version patch will only use the main heap returned by
GetProcessHeap since this is a safe operation.

If there is only one heap, then this version matches the entropy
provided by the existing implementation without the performance
implications or deadlock / hang. If there is interest, I also have a
version of this patch that iterates all heaps of the process in
addition to the main heap (GetProcessHeap). However I am uncertain if
the extra motes of entropy that those private heaps provide are worth
potentially destabilizing the process.

I did my best to maintain style using the OpenSSL style guide and
'when-in-rome' guidelines; for example there was a pre-existing mix of
tabs and spaces for indentation, so I kept them where it already
existed.

I've been encountering this quite often on some machines that can't
realistically be updated, and the patch works very well for both
0.9.8gz and 1.0.1h.

The only changes are rand_win.c -- I've attached the unified diff for
1.0.1h, though the differences in the implementation of this change
between 1.0.1h and 0.9.8zg are cosmetic only. I also have a diff for
0.9.8zg, as well as the implementation of walking all heaps for both
of these release branches as well, but I'd rather not pollute this
list with mostly-redundant patches.

If preferred, I can create a pull request, but it seems that
submitting simpler patches to the mailing list is suggested initial
approach.

Thanks,

-- 

- Adam D. Walling
--- rand_win.c.original 2014-06-05 05:41:30.0 -0400
+++ rand_win.c  2015-07-28 12:28:43.393846200 -0400
@@ -168,13 +168,15 @@
 
 typedef HANDLE (WINAPI *CREATETOOLHELP32SNAPSHOT)(DWORD, DWORD);
 typedef BOOL (WINAPI *CLOSETOOLHELP32SNAPSHOT)(HANDLE);
-typedef BOOL (WINAPI *HEAP32FIRST)(LPHEAPENTRY32, DWORD, size_t);
-typedef BOOL (WINAPI *HEAP32NEXT)(LPHEAPENTRY32);
-typedef BOOL (WINAPI *HEAP32LIST)(HANDLE, LPHEAPLIST32);
 typedef BOOL (WINAPI *PROCESS32)(HANDLE, LPPROCESSENTRY32);
 typedef BOOL (WINAPI *THREAD32)(HANDLE, LPTHREADENTRY32);
 typedef BOOL (WINAPI *MODULE32)(HANDLE, LPMODULEENTRY32);
 
+typedef BOOL(WINAPI *HEAPWALK) (HANDLE, LPPROCESS_HEAP_ENTRY);
+typedef BOOL(WINAPI *HEAPLOCK) (HANDLE);
+typedef BOOL(WINAPI *HEAPUNLOCK) (HANDLE);
+typedef HANDLE(WINAPI *GETPROCESSHEAP) (VOID);
+
 #include lmcons.h
 #include lmstats.h
 #if 1 /* The NET API is Unicode only.  It requires the use of the UNICODE
@@ -432,7 +434,67 @@
FreeLibrary(user);
}
 
-   /* Toolhelp32 snapshot: enumerate processes, threads, modules and heap
+   if (kernel) {
+   GETPROCESSHEAP get_process_heap;
+   HEAPWALK heap_walk;
+   HEAPLOCK heap_lock;
+   HEAPUNLOCK heap_unlock;
+
+   HANDLE heap;
+
+   DWORD starttime = 0;
+   
+   // HeapWalk et al available as of NT 3.51
+   get_process_heap = (GETPROCESSHEAP)
+   GetProcAddress(kernel, GetProcessHeap);
+   heap_walk = (HEAPWALK) GetProcAddress(kernel, HeapWalk);
+   heap_lock = (HEAPLOCK) GetProcAddress(kernel, HeapLock);
+   heap_unlock = (HEAPUNLOCK) GetProcAddress(kernel, HeapUnlock);
+
+   if (get_process_heap  heap_walk  heap_lock  heap_unlock) {
+
+   if (good)
+   starttime = GetTickCount();
+
+   

[openssl-dev] [PATCH] logjam vulnerability changes for 0.9.8f version

[Rao, Yarlagadda Srinivasa (MCOU)]

Hello All,

This patch fixes/back port the DH parameters changes from 1.0.1 stable branch 
to 0.9.8f version.

---
$ cat /tmp/patch.txt
--- s3_clnt.c_org   2015-06-10 14:27:54.0 +0530
+++ s3_clnt.c   2015-06-11 08:05:46.0 +0530
@@ -2575,22 +2575,31 @@
 }
#endif
#ifndef OPENSSL_NO_DH
-if ((algs  SSL_kEDH) 
-!(has_bits(i, EVP_PK_DH | EVP_PKT_EXCH) || (dh != NULL))) {
-SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, SSL_R_MISSING_DH_KEY);
+if ((algs  SSL_kEDH)  dh == NULL) {
+SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, ERR_R_INTERNAL_ERROR);
 goto f_err;
-} else if ((algs  SSL_kDHr)  !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
+}
+if ((algs  SSL_kDHr)  !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
 SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
SSL_R_MISSING_DH_RSA_CERT);
 goto f_err;
 }
# ifndef OPENSSL_NO_DSA
-else if ((algs  SSL_kDHd)  !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
+if ((algs  SSL_kDHd)  !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
 SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
SSL_R_MISSING_DH_DSA_CERT);
 goto f_err;
 }
# endif
+/* Check DHE only: static DH not implemented. */
+if (algs  SSL_kEDH) {
+int dh_size = BN_num_bits(dh-p);
+if ((!SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  dh_size  768)
+|| (SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  dh_size  512)) {
+SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, 
SSL_R_DH_KEY_TOO_SMALL);
+goto f_err;
+}
+}
#endif

 if (SSL_C_IS_EXPORT(s-s3-tmp.new_cipher)  !has_bits(i, EVP_PKT_EXP)) {
--- ssl.h_org   2015-06-10 14:24:27.0 +0530
+++ ssl.h   2015-06-11 08:05:28.0 +0530
@@ -2036,6 +2036,7 @@
# define SSL_R_DATA_LENGTH_TOO_LONG   146
# define SSL_R_DECRYPTION_FAILED  147
# define SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC281
+# define SSL_R_DH_KEY_TOO_SMALL   372
# define SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG148
# define SSL_R_DIGEST_CHECK_FAILED149
# define SSL_R_DTLS_MESSAGE_TOO_BIG   318
--- ssl_err.c_org   2015-06-10 14:21:03.0 +0530
+++ ssl_err.c   2015-06-11 08:05:21.0 +0530
@@ -390,6 +390,7 @@
 {ERR_REASON(SSL_R_DECRYPTION_FAILED), decryption failed},
 {ERR_REASON(SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC),
  decryption failed or bad record mac},
+{ERR_REASON(SSL_R_DH_KEY_TOO_SMALL), dh key too small},
 {ERR_REASON(SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG),
  dh public value length is wrong},
 {ERR_REASON(SSL_R_DIGEST_CHECK_FAILED), digest check failed},
--- dhparam.c_org   2015-06-10 14:17:53.0 +0530
+++ dhparam.c   2015-06-11 08:04:47.0 +0530
@@ -130,7 +130,7 @@
# undef PROG
# define PROGdhparam_main

-# define DEFBITS 512
+# define DEFBITS 2048

/*-
  * -inform arg  - input format - default PEM (DER or PEM)
@@ -254,7 +254,7 @@
 BIO_printf(bio_err,
 -5generate parameters using  5 as the 
generator value\n);
 BIO_printf(bio_err,
-numbits   number of bits in to generate (default 
512)\n);
+numbits   number of bits in to generate (default 
2048)\n);
# ifndef OPENSSL_NO_ENGINE
 BIO_printf(bio_err,
 -engine e use engine e, possibly a hardware 
device.\n);
--- gendh.c_org 2015-06-10 14:18:31.0 +0530
+++ gendh.c 2015-06-11 08:04:55.0 +0530
@@ -80,7 +80,7 @@
# include openssl/x509.h
# include openssl/pem.h

-# define DEFBITS 512
+# define DEFBITS 2048
# undef PROG
# define PROG gendh_main

--- s_server.c_org  2015-06-10 14:16:40.0 +0530
+++ s_server.c  2015-06-11 08:04:38.0 +0530
@@ -197,7 +197,7 @@
unsigned int *id_len);
#ifndef OPENSSL_NO_DH
static DH *load_dh_param(const char *dhfile);
-static DH *get_dh512(void);
+static DH *get_dh2048(void);
#endif

#ifdef MONOLITH
@@ -213,30 +213,48 @@
#endif

#ifndef OPENSSL_NO_DH
-static unsigned char dh512_p[] = {
-0xDA, 0x58, 0x3C, 0x16, 0xD9, 0x85, 0x22, 0x89, 0xD0, 0xE4, 0xAF, 0x75,
-0x6F, 0x4C, 0xCA, 0x92, 0xDD, 0x4B, 0xE5, 0x33, 0xB8, 0x04, 0xFB, 0x0F,
-0xED, 0x94, 0xEF, 0x9C, 0x8A, 0x44, 0x03, 0xED, 0x57, 0x46, 0x50, 0xD3,
-0x69, 0x99, 0xDB, 0x29, 0xD7, 0x76, 0x27, 0x6B, 0xA2, 0xD3, 0xD4, 0x12,
-0xE2, 0x18, 0xF4, 0xDD, 0x1E, 0x08, 0x4C, 0xF6, 0xD8, 0x00, 0x3E, 0x7C,
-0x47, 0x74, 0xE8, 0x33,
+static unsigned char dh2048_p[] = {
+0xF6,0x42,0x57,0xB7,0x08,0x7F,0x08,0x17,0x72,0xA2,0xBA,0xD6,
+0xA9,0x42,0xF3,0x05,0xE8,0xF9,0x53,0x11,0x39,0x4F,0xB6,0xF1,
+0x6E,0xB9,0x4B,0x38,0x20,0xDA,0x01,0xA7,0x56,0xA3,0x14,0xE9,
+0x8F,0x40,0x55,0xF3,0xD0,0x07,0xC6,0xCB,0x43,0xA9,0x94,0xAD,
+

[openssl-dev] [PATCH] for capi_load_ssl_client_cert

[Андрей Даровских]

Hello.

 capi_load_ssl_client_cert function does not select the certificates that
have a chain of issuers if the server transmits only the root certificate of
the issuer.
Attached patch fixes this error.


e_capi.c.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Patch for CRL-Times in openssl ca

[Matt Caswell]

On 15/04/15 17:57, Felix Dörre wrote:
 Hi,
 
 I'd like to specify the start and end times for the CRLs generated with
 openssl ca. I prepared a patch and created a Github Pull-Request
 (https://github.com/openssl/openssl/pull/258). Is there anything else, I
 can do to help that this change is incorporated into the official
 openssl source code?
 

You should create an RT ticket (send email to r...@openssl.org) with a
link to the pull request.

Matt

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

Re: [openssl-dev] Patch for CRL-Times in openssl ca

[Salz, Rich]

 I'd like to specify the start and end times for the CRLs generated with
 openssl ca. I prepared a patch and created a Github Pull-Request
 (https://github.com/openssl/openssl/pull/258). Is there anything else, I can
 do to help that this change is incorporated into the official openssl source
 code?

Nope, it's good.

We're working our way through a huge code-review of the apps code right now.  
Once that hits master, then I'll integrate your patch (and various other 
pending ones).
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Patch for CRL-Times in openssl ca

[Felix Dörre]

Hi,

I'd like to specify the start and end times for the CRLs generated with 
openssl ca. I prepared a patch and created a Github Pull-Request 
(https://github.com/openssl/openssl/pull/258). Is there anything else, I 
can do to help that this change is incorporated into the official 
openssl source code?


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

[openssl-dev] [PATCH] evp: fix memory corruption on absent payload

[Fedor Indutny]

Hello!

aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD
payload, but fail to operate if it wasn't supplied. In fact, in case of
absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the
memory will be corrupted (which sometimes leads to the crash).

NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this
in 1.0.2, so this commit could be considered to be a partial back-port
of that one.

Attached is the suggested patch.

Thank you,
Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a
PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N
z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0
kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL
Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD
fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1
Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS
HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c
GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX
P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb
kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv
pl3+vgsqfHkGs0I+W6Hy
=GkP4
-END PGP SIGNATURE-


0001-evp-fix-memory-corruption-on-absent-payload.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] patch for capi_load_ssl_client_cert

[Андрей Даровских]

Hello.

 capi_load_ssl_client_cert function does not select the certificates that
have a chain of issuers if the server transmits only the root certificate of
the issuer.
Attached patch fixes this error.


e_capi.c.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] remove double initialization of cryptodev engine

[Cristian Stoica]

cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.

Signed-off-by: Cristian Stoica cristian.sto...@freescale.com
---
 crypto/engine/eng_all.c | 12 
 crypto/engine/engine.h  |  4 
 crypto/evp/c_all.c  |  5 -
 util/libeay.num |  2 +-
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/crypto/engine/eng_all.c b/crypto/engine/eng_all.c
index 7edf12e..8f5d1b2 100644
--- a/crypto/engine/eng_all.c
+++ b/crypto/engine/eng_all.c
@@ -125,15 +125,3 @@ void ENGINE_load_builtin_engines(void)
 #endif
 ENGINE_register_all_complete();
 }
-
-#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void)
-{
-static int bsd_cryptodev_default_loaded = 0;
-if (!bsd_cryptodev_default_loaded) {
-ENGINE_load_cryptodev();
-ENGINE_register_all_complete();
-}
-bsd_cryptodev_default_loaded = 1;
-}
-#endif
diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h
index e81096a..1c70250 100644
--- a/crypto/engine/engine.h
+++ b/crypto/engine/engine.h
@@ -858,10 +858,6 @@ typedef int (*dynamic_bind_engine) (ENGINE *e, const char 
*id,
  */
 void *ENGINE_get_static_state(void);
 
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void);
-# endif
-
 /* BEGIN ERROR CODES */
 /*
  * The following lines are auto generated by the script mkerr.pl. Any changes
diff --git a/crypto/evp/c_all.c b/crypto/evp/c_all.c
index a3ed00d..719e34d 100644
--- a/crypto/evp/c_all.c
+++ b/crypto/evp/c_all.c
@@ -82,9 +82,4 @@ void OPENSSL_add_all_algorithms_noconf(void)
 OPENSSL_cpuid_setup();
 OpenSSL_add_all_ciphers();
 OpenSSL_add_all_digests();
-#ifndef OPENSSL_NO_ENGINE
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-ENGINE_setup_bsd_cryptodev();
-# endif
-#endif
 }
diff --git a/util/libeay.num b/util/libeay.num
index b594caf..9eb2423 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -2803,7 +2803,7 @@ BIO_indent  3242  
EXIST::FUNCTION:
 BUF_strlcpy 3243   EXIST::FUNCTION:
 OpenSSLDie  3244   EXIST::FUNCTION:
 OPENSSL_cleanse 3245   EXIST::FUNCTION:
-ENGINE_setup_bsd_cryptodev  3246   
EXIST:__FreeBSD__:FUNCTION:ENGINE
+ENGINE_setup_bsd_cryptodev  3246   NOEXIST::FUNCTION:
 ERR_release_err_state_table 3247   EXIST::FUNCTION:LHASH
 EVP_aes_128_cfb83248   EXIST::FUNCTION:AES
 FIPS_corrupt_rsa3249   NOEXIST::FUNCTION:
-- 
2.3.5

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

[openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings

[Mike Frysinger via RT]

atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools.  So add support for the standard $RC
/ $WINDRES env vars as well.
---
 Configure   | 3 +++
 Makefile.org| 2 ++
 Makefile.shared | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Configure b/Configure
index 97c2573..c137a4c 100755
--- a/Configure
+++ b/Configure
@@ -1307,6 +1307,7 @@ my $shared_ldflag = $table{$target}-{shared_ldflag};
 my $shared_extension = $table{$target}-{shared_extension};
 my $ranlib = $ENV{'RANLIB'} || $table{$target}-{ranlib};
 my $ar = $ENV{'AR'} || ar;
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || windres;
 my $arflags = $table{$target}-{arflags};
 my $multilib = $table{$target}-{multilib};
 
@@ -1774,12 +1775,14 @@ while (IN)
s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+   s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc 
eq gcc;
}
else{
s/^CC=.*$/CC= $cc/;
s/^AR=\s*ar/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
+   s/^WINDRES=.*/WINDRES= $windres/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc || ($cc eq 
'cc'  $target =~ /darwin/);
}
s/^CFLAG=.*$/CFLAG= $cflags/;
diff --git a/Makefile.org b/Makefile.org
index f254d76..a6d9471 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -66,6 +66,7 @@ EXE_EXT=
 ARFLAGS=
 AR=ar $(ARFLAGS) r
 RANLIB= ranlib
+WINDRES= windres
 NM= nm
 PERL= perl
 #RM= echo --
@@ -216,6 +217,7 @@ BUILDENV=   PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' 
\
CC='$(CC)' CFLAG='$(CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+   WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index babeb46..e8903ca 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -282,7 +282,7 @@ link_a.cygwin:
fi; \
dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
$(PERL) util/mkrc.pl $$dll_name | \
-   $(CROSS_COMPILE)windres -o rc.o; \
+   $(WINDRES) -o rc.o; \
extras=$$extras rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
-- 
2.3.4


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

[openssl-dev] [PATCH] Fix (new!) uninitialized-use undefined behaviors

[Pascal Cuoq]

Hello,

we have found some uses of uninitialized memory in OpenSSL that,
unlike other infamous ones, have not been previously discussed (to
the best of our knowledge).

These uses of uninitialized memory have characteristics that might make
them worth fixing even if other uses of uninitialized memory remain in
OpenSSL:

- the uninitialized access occurs in a single branch of an
if-then-else. An obvious optimization for a compiler is to
compile out the condition and the branch containing undefined
behavior (UB), leaving only the non-undefined branch.
The blog post below shows the widely used GCC C compiler
optimizing a program according to this very idea:
http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined

- Sometimes the obligation the compiler has to produce code that
must work for inputs that do not cause UB will in practice make
the UB relatively harmless. 
Here, the uninitialized access occurs within a macro, BN_with_flags,
meaning that a particular use of the macro for inputs that cause
UB is NOT protected by separate compilation compiler constraints.

- If a compiler has applied the optimization from the aforementioned
blog post, or if a future compiler decides to, the resulting flaw will not
be visible in functional tests (it will not be a functional bug) but it could
still lead to side-channel vulnerabilities in OpenSSL (as far as I understand
the surrounding code).

- The uninitialized memory access does add any value. It does not make
the PRNG work better or anything, it is purely incidental (it occurs
in a pattern that could also have been implemented using bit-fields,
the difference being that it is legal to assign x.bitfield1 when x.bitfield2
is uninitialized, whereas doing so by hand as in the macro BN_with_flags
invokes undefined behavior).


With help of an anonymous good soul on the Internet, we have investigated
the code produced by the GCC version that was used for the aforementioned
blog post 4.4.3. We have found that:
* GCC authors must not have found that this agressive optimization was
very desirable, since this GCC behavior had disappeared in 4.4.7.
* Nevertheless, GCC 4.4.3 was the packaged compiler for a Ubuntu LTS
distribution. The behavior in GCC 4.4.3 was not acknowledged as a bug,
and it was not fixed in the Ubuntu distribution, and it could be re-introduced
in a future GCC version. The behavior may also already exist or
be introduced in another C compiler. 
* GCC 4.4.3 does not appear to optimize the specific source code pattern
in OpenSSL the way it optimizes the one in the blog post.

Best regards,

Pascal Cuoq
TrustInSoft Chief Scientist



uninitialized.patch
Description: uninitialized.patch


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

[openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Matt Cross]

I am working with something that does a lot of SHA1's.  I am trying to
profile my application and generate flame graphs (see
http://www.brendangregg.com/flamegraphs.html ), but profiling tools cannot
successfully backtrace when the processor is running the optimized SHA1
code on x86_64.  This patch adds CFI directives when compiled with a GNU
assembler to enable tools that understand DWARF debugging information to
backtrace in this circumstance.

I don't have a build environment for win64, but I did verify that the perl
code does not generate the CFI directives if we are not generating code for
the GNU assembler (IE if $cfi is not set).

-Matt


commit 9522d706fa58679abd0b6f923aad623fad39abe5
Author: Matt Cross matt.cr...@gmail.com
Date:   Wed Mar 25 14:15:37 2015 -0400

Add CFI directives to the x86_64 SHA1 implementation to allow DWARF
aware utilities to backtrace through these routines.

diff --git a/crypto/sha/asm/sha1-x86_64.pl b/crypto/sha/asm/sha1-x86_64.pl
index 9bb6b49..9fe7b2b 100755
--- a/crypto/sha/asm/sha1-x86_64.pl
+++ b/crypto/sha/asm/sha1-x86_64.pl
@@ -95,6 +95,7 @@ die can't locate x86_64-xlate.pl;
 if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 21`
  =~ /GNU assembler version ([2-9]\.[0-9]+)/) {
  $avx = ($1=2.19) + ($1=2.22);
+ $cfi = 1
 }

 if (!$avx  $win64  ($flavour =~ /nasm/ || $ENV{ASM} =~ /nasm/) 
@@ -247,6 +248,8 @@ $code.=___;
 .type sha1_block_data_order,\@function,3
 .align 16
 sha1_block_data_order:
+`.cfi_startproc if $cfi`
+
  mov OPENSSL_ia32cap_P+0(%rip),%r9d
  mov OPENSSL_ia32cap_P+4(%rip),%r8d
  mov OPENSSL_ia32cap_P+8(%rip),%r10d
@@ -275,17 +278,35 @@ $code.=___;
 .align 16
 .Lialu:
  mov %rsp,%rax
+`.cfi_def_cfa_register rax if $cfi`
  push %rbx
+# The CFA (Cononical Frame Address) is after the pushed return value, so
RBX was just stored at CFA - 16:
+`.cfi_offset rbx,-16 if $cfi`
  push %rbp
+`.cfi_offset rbp,-24 if $cfi`
  push %r12
+`.cfi_offset r12,-32 if $cfi`
  push %r13
+`.cfi_offset r13,-40 if $cfi`
  push %r14
+`.cfi_offset r14,-48 if $cfi`
  mov %rdi,$ctx # reassigned argument
  sub \$`8+16*4`,%rsp
  mov %rsi,$inp # reassigned argument
  and \$-64,%rsp
  mov %rdx,$num # reassigned argument
  mov %rax,`16*4`(%rsp)
+# This adds a CFA expression to say that the CFA is calculated by
reading the value at RSP+0x40, and adding 8 to it:
+# DW_CFA_def_cfa_expression0x0f   : says CFA is calculated by
evaluating the following expression
+# BLOCK
+#   length (ULEB128)   0x06   : number of bytes remaining
+#   DW_OP_breg7 0x40   0x77 0xc0 0x00 : read RSP, add 0x40, and
push onto stack - note SLEB128 encoding of 0x40
+#   requires 2 bytes to avoid
sign extension
+#   DW_OP_deref0x06   : read from addr on top of
stack
+#   DW_OP_plus_uconst 0x8  0x23 0x08  : pop top of stack, add 8,
push back onto stack
+
+`.cfi_escape 0x0f,0x06,0x77,0xc0,0x00,0x06,0x23,0x08 if $cfi`
+
 .Lprologue:

  mov 0($ctx),$A
@@ -319,14 +340,22 @@ $code.=___;
  jnz .Lloop

  mov `16*4`(%rsp),%rsi
+`.cfi_def_cfa rsi,8 if $cfi`
  mov -40(%rsi),%r14
+`.cfi_restore r14 if $cfi`
  mov -32(%rsi),%r13
+`.cfi_restore r13 if $cfi`
  mov -24(%rsi),%r12
+`.cfi_restore r12 if $cfi`
  mov -16(%rsi),%rbp
+`.cfi_restore rbp if $cfi`
  mov -8(%rsi),%rbx
+`.cfi_restore rbx if $cfi`
  lea (%rsi),%rsp
+`.cfi_def_cfa rsp,8 if $cfi`
 .Lepilogue:
  ret
+`.cfi_endproc if $cfi`
 .size sha1_block_data_order,.-sha1_block_data_order
 ___
 if ($shaext) {{{
@@ -342,6 +371,7 @@ $code.=___;
 .align 32
 sha1_block_data_order_shaext:
 _shaext_shortcut:
+`.cfi_startproc if $cfi`
 ___
 $code.=___ if ($win64);
  lea `-8-4*16`(%rsp),%rsp
@@ -440,6 +470,7 @@ $code.=___ if ($win64);
 ___
 $code.=___;
  ret
+`.cfi_endproc if $cfi`
 .size sha1_block_data_order_shaext,.-sha1_block_data_order_shaext
 ___
 }}}
@@ -473,12 +504,19 @@ $code.=___;
 .align 16
 sha1_block_data_order_ssse3:
 _ssse3_shortcut:
+`.cfi_startproc if $cfi`
  mov %rsp,%rax
+`.cfi_def_cfa_register rax if $cfi`
  push %rbx
+`.cfi_offset rbx,-16 if $cfi`
  push %rbp
+`.cfi_offset rbp,-24 if $cfi`
  push %r12
+`.cfi_offset r12,-32 if $cfi`
  push %r13 # redundant, done to share Win64 SE handler
+`.cfi_offset r13,-40 if $cfi`
  push %r14
+`.cfi_offset r14,-48 if $cfi`
  lea `-64-($win64?6*16:0)`(%rsp),%rsp
 ___
 $code.=___ if ($win64);
@@ -492,6 +530,7 @@ $code.=___ if ($win64);
 ___
 $code.=___;
  mov %rax,%r14 # original %rsp
+`.cfi_def_cfa_register r14 if $cfi`
  and \$-64,%rsp
  mov %rdi,$ctx # reassigned argument
  mov %rsi,$inp # reassigned argument
@@ -907,14 +946,22 @@ $code.=___ if ($win64);
 ___
 $code.=___;
  lea (%r14),%rsi
+`.cfi_def_cfa_register rsi if $cfi`
  mov -40(%rsi),%r14
+`.cfi_restore r14 if $cfi`
  mov -32(%rsi),%r13
+`.cfi_restore r13 if $cfi`
  mov -24(%rsi),%r12
+`.cfi_restore r12 if $cfi`
  mov -16(%rsi),%rbp
+`.cfi_restore rbp if $cfi`
  mov -8(%rsi),%rbx
+`.cfi_restore rbx if $cfi`
  lea (%rsi),%rsp

Re: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Wim Lewis]

On Mar 25, 2015, at 11:56 AM, Matt Cross matt.cr...@gmail.com wrote:
 I am working with something that does a lot of SHA1's.  I am trying to 
 profile my application and generate flame graphs (see 
 http://www.brendangregg.com/flamegraphs.html ), but profiling tools cannot 
 successfully backtrace when the processor is running the optimized SHA1 code 
 on x86_64.  This patch adds CFI directives when compiled with a GNU assembler 
 to enable tools that understand DWARF debugging information to backtrace in 
 this circumstance.


FYI, I submitted a patch a few years ago to do this for many of the x86-32 
assembly files. The perlasm preprocessor already tries to track the stack 
offset, which means that a lot of those .cfi directives can be generated 
automatically, without requiring the programmer to keep track of them.

The patches are here:
   http://rt.openssl.org/Ticket/Display.html?id=2562

As you point out, this is pretty useful to allow profiling and/or debugging 
code that spends a lot of its time in OpenSSL.


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

Re: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Matt Cross]

On Wed, Mar 25, 2015 at 3:19 PM, Wim Lewis w...@omnigroup.com wrote:



 FYI, I submitted a patch a few years ago to do this for many of the x86-32
 assembly files. The perlasm preprocessor already tries to track the stack
 offset, which means that a lot of those .cfi directives can be generated
 automatically, without requiring the programmer to keep track of them.

 The patches are here:
http://rt.openssl.org/Ticket/Display.html?id=2562

 As you point out, this is pretty useful to allow profiling and/or
 debugging code that spends a lot of its time in OpenSSL.


That's an interesting approach, much more maintainable going forward.  As
you noted in your bug report, there is some code in the sha1 implementation
that does something like this:

mov %rsp,%rax
and $-64,%rsp
mov %rax,64(%rsp)
[more code that trashes rax]

Then, in the epilogue it does something like this:
mov 64(%rsp),%rsi
[restore callee-saved variables]
mov %rsi,%rsp

This is done to align %rsp to a 64 byte boundary, and the original %rsp is
stored on the stack; so the only way to get the actual frame pointer is to
read 64(%rsp) and add an offset to that.  I managed to do that by inserting
a raw DWARF expression.  It's not clear to me that the perlasm preprocessor
could (or should) do this; but perhaps it makes sense to add some
directives for the perlasm preprocessor and let it generate the raw DWARF
expression.

If I understand correctly, your patch was not folded in.  Do you recall why?

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

Re: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing

[Wim Lewis]

On Mar 25, 2015, at 2:42 PM, Matt Cross matt.cr...@gmail.com wrote:
 This is done to align %rsp to a 64 byte boundary, and the original %rsp is 
 stored on the stack; so the only way to get the actual frame pointer is to 
 read 64(%rsp) and add an offset to that.  I managed to do that by inserting a 
 raw DWARF expression.  It's not clear to me that the perlasm preprocessor 
 could (or should) do this; but perhaps it makes sense to add some directives 
 for the perlasm preprocessor and let it generate the raw DWARF expression.

I think the cfi_cfa_indirect pseudo-directive handles that case (it’s defined 
in x86gas.pl and used in, e.g., aesni-x86, which does a similar stack 
alignment). It uses a minuscule “assembler” for DWARF location opcode 
expressions included in the 3-cfi patch, which makes it easier to handle cases 
where the assembly is doing something clever.

The SHA256 and SHA512 implementations on x86_32 did something trickier: each 
round adjusted the stack frame forwards by some number of bytes, so that it 
could read the previous round and write the new data from fixed offsets from 
$esp (presumably this saves a register). I didn’t try writing DWARF info to 
unwind that. I don’t think the x86_64 code does that, though, since registers 
aren’t as scarce.


 If I understand correctly, your patch was not folded in.  Do you recall why?

IIRC, the maintainer said it would be too much trouble to integrate.



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

[openssl-dev] [PATCH] [openssl.org #2464] TLS-RSA-PSK support

[A. Klitzing]

Hi there!

I like to ask if this RSA-PSK patch could be reviewed (and maybe added) by
someone. We are looking forward to see this feature in 1.1.0 someday.

Any comments or hints?

Best regards
   André Klitzing



2015-01-30 16:32 GMT+01:00 Giuseppe D'Angelo via RT r...@openssl.org:

 New version of the patch, targeting master.

 It's basically style changes after the massive OpenSSL refactoring.

 Thanks,
 --
 Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
 KDAB (UK) Ltd., a KDAB Group company
 Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions

From db9155f74e7cb3785851a49f1d11be2d57f70c9e Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo giuseppe.dang...@kdab.com
Date: Sat, 8 Nov 2014 20:44:23 +0100
Subject: [PATCH] Introduce TLS-RSA-PSK support

Build on the existing PSK support and introduce RSA-PSK
(cf. RFC 4279, 5487).
Based on the original patch by Christian J. Dietrich.

This work has been sponsored by Governikus GmbH  Co. KG.

PR: 2464
---
 CHANGES  |3 +
 doc/apps/ciphers.pod |   12 +++
 ssl/s3_clnt.c|  122 ++-
 ssl/s3_lib.c |  208 -
 ssl/s3_srvr.c|  227 +++---
 ssl/ssl.h|2 +
 ssl/ssl_ciph.c   |9 +-
 ssl/ssl_lib.c|6 ++
 ssl/ssl_locl.h   |2 +
 ssl/tls1.h   |   36 
 10 files changed, 592 insertions(+), 35 deletions(-)

diff --git a/CHANGES b/CHANGES
index 26ea797..726a54a 100644
--- a/CHANGES
+++ b/CHANGES
@@ -351,6 +351,9 @@
  whose return value is often ignored. 
  [Steve Henson]
 
+  *) Support for TLS-RSA-PSK ciphersuites has been added.
+ [Giuseppe D'Angelo, Christian J. Dietrich]
+
  Changes between 1.0.1k and 1.0.2 [xx XXX ]
 
   *) Facilitate universal ARM builds targeting range of ARM ISAs, e.g.
diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index 6d39c54..79644ef 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -587,10 +587,22 @@ Note: these ciphers can also be used in SSL v3.
 
 =head2 Pre shared keying (PSK) cipheruites
 
+ TLS_RSA_PSK_WITH_RC4_128_SHA  RSA-PSK-RC4-SHA
+ TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA-PSK-3DES-EDE-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_128_CBC_SHA  RSA-PSK-AES128-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_256_CBC_SHA  RSA-PSK-AES256-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_128_CBC_SHA256   RSA-PSK-AES128-CBC-SHA256
+ TLS_RSA_PSK_WITH_AES_256_CBC_SHA384   RSA-PSK-AES256-CBC-SHA384
+ TLS_RSA_PSK_WITH_AES_128_GCM_SHA256   RSA-PSK-AES128-GCM-SHA256
+ TLS_RSA_PSK_WITH_AES_256_GCM_SHA384   RSA-PSK-AES256-GCM-SHA384
  TLS_PSK_WITH_RC4_128_SHA  PSK-RC4-SHA
  TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK-3DES-EDE-CBC-SHA
  TLS_PSK_WITH_AES_128_CBC_SHA  PSK-AES128-CBC-SHA
  TLS_PSK_WITH_AES_256_CBC_SHA  PSK-AES256-CBC-SHA
+ TLS_PSK_WITH_AES_128_CBC_SHA256   PSK-AES128-CBC-SHA256
+ TLS_PSK_WITH_AES_256_CBC_SHA384   PSK-AES256-CBC-SHA384
+ TLS_PSK_WITH_AES_128_GCM_SHA256   PSK-AES128-GCM-SHA256
+ TLS_PSK_WITH_AES_256_GCM_SHA384   PSK-AES256-GCM-SHA384
 
 =head1 NOTES
 
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index a383eee..d7908e5 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -320,7 +320,7 @@ int ssl3_connect(SSL *s)
 case SSL3_ST_CR_CERT_A:
 case SSL3_ST_CR_CERT_B:
 /* Check if it is anon DH/ECDH, SRP auth */
-/* or PSK */
+/* or plain PSK */
 if (!
 (s-s3-tmp.
  new_cipher-algorithm_auth  (SSL_aNULL | SSL_aSRP))
@@ -1367,9 +1367,9 @@ int ssl3_get_key_exchange(SSL *s)
 }
 #ifndef OPENSSL_NO_PSK
 /*
- * In plain PSK ciphersuite, ServerKeyExchange can be omitted if no
- * identity hint is sent. Set session-sess_cert anyway to avoid
- * problems later.
+ * In PSK ciphersuites, ServerKeyExchange can be omitted if no
+ * identity hint is sent. Set session-sess_cert for plain PSK
+ * anyway to avoid problems later.
  */
 if (alg_k  SSL_kPSK) {
 s-session-sess_cert = ssl_sess_cert_new();
@@ -1414,7 +1414,12 @@ int ssl3_get_key_exchange(SSL *s)
 al = SSL_AD_DECODE_ERROR;
 
 #ifndef OPENSSL_NO_PSK
-if (alg_k  SSL_kPSK) {
+/* handle PSK identity hint */
+if (alg_k  (SSL_kPSK
+#ifndef OPENSSL_NO_RSA
+ | SSL_kRSAPSK
+#endif
+ )) {
 char tmp_id_hint[PSK_MAX_IDENTITY_LEN + 1];
 
 param_len = 2;
@@ -1569,7 +1574,11 @@ int ssl3_get_key_exchange(SSL *s)
 } else
 #endif  /* !OPENSSL_NO_SRP */
 #ifndef OPENSSL_NO_RSA
-if (alg_k  SSL_kRSA) {
+if (alg_k  (SSL_kRSA
+#ifndef OPENSSL_NO_PSK
+ | SSL_kRSAPSK
+#endif
+ )) {
 /* Temporary RSA keys only 

[openssl-dev] [PATCH] [openssl.org #2464] TLS-RSA-PSK support

[A. Klitzing via RT]

Hi there!

I like to ask if this RSA-PSK patch could be reviewed (and maybe added) by
someone. We are looking forward to see this feature in 1.1.0 someday.

Any comments or hints?

Best regards
   André Klitzing



2015-01-30 16:32 GMT+01:00 Giuseppe D'Angelo via RT r...@openssl.org:

 New version of the patch, targeting master.

 It's basically style changes after the massive OpenSSL refactoring.

 Thanks,
 --
 Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
 KDAB (UK) Ltd., a KDAB Group company
 Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions


From db9155f74e7cb3785851a49f1d11be2d57f70c9e Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo giuseppe.dang...@kdab.com
Date: Sat, 8 Nov 2014 20:44:23 +0100
Subject: [PATCH] Introduce TLS-RSA-PSK support

Build on the existing PSK support and introduce RSA-PSK
(cf. RFC 4279, 5487).
Based on the original patch by Christian J. Dietrich.

This work has been sponsored by Governikus GmbH  Co. KG.

PR: 2464
---
 CHANGES  |3 +
 doc/apps/ciphers.pod |   12 +++
 ssl/s3_clnt.c|  122 ++-
 ssl/s3_lib.c |  208 -
 ssl/s3_srvr.c|  227 +++---
 ssl/ssl.h|2 +
 ssl/ssl_ciph.c   |9 +-
 ssl/ssl_lib.c|6 ++
 ssl/ssl_locl.h   |2 +
 ssl/tls1.h   |   36 
 10 files changed, 592 insertions(+), 35 deletions(-)

diff --git a/CHANGES b/CHANGES
index 26ea797..726a54a 100644
--- a/CHANGES
+++ b/CHANGES
@@ -351,6 +351,9 @@
  whose return value is often ignored. 
  [Steve Henson]
 
+  *) Support for TLS-RSA-PSK ciphersuites has been added.
+ [Giuseppe D'Angelo, Christian J. Dietrich]
+
  Changes between 1.0.1k and 1.0.2 [xx XXX ]
 
   *) Facilitate universal ARM builds targeting range of ARM ISAs, e.g.
diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index 6d39c54..79644ef 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -587,10 +587,22 @@ Note: these ciphers can also be used in SSL v3.
 
 =head2 Pre shared keying (PSK) cipheruites
 
+ TLS_RSA_PSK_WITH_RC4_128_SHA  RSA-PSK-RC4-SHA
+ TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA-PSK-3DES-EDE-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_128_CBC_SHA  RSA-PSK-AES128-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_256_CBC_SHA  RSA-PSK-AES256-CBC-SHA
+ TLS_RSA_PSK_WITH_AES_128_CBC_SHA256   RSA-PSK-AES128-CBC-SHA256
+ TLS_RSA_PSK_WITH_AES_256_CBC_SHA384   RSA-PSK-AES256-CBC-SHA384
+ TLS_RSA_PSK_WITH_AES_128_GCM_SHA256   RSA-PSK-AES128-GCM-SHA256
+ TLS_RSA_PSK_WITH_AES_256_GCM_SHA384   RSA-PSK-AES256-GCM-SHA384
  TLS_PSK_WITH_RC4_128_SHA  PSK-RC4-SHA
  TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK-3DES-EDE-CBC-SHA
  TLS_PSK_WITH_AES_128_CBC_SHA  PSK-AES128-CBC-SHA
  TLS_PSK_WITH_AES_256_CBC_SHA  PSK-AES256-CBC-SHA
+ TLS_PSK_WITH_AES_128_CBC_SHA256   PSK-AES128-CBC-SHA256
+ TLS_PSK_WITH_AES_256_CBC_SHA384   PSK-AES256-CBC-SHA384
+ TLS_PSK_WITH_AES_128_GCM_SHA256   PSK-AES128-GCM-SHA256
+ TLS_PSK_WITH_AES_256_GCM_SHA384   PSK-AES256-GCM-SHA384
 
 =head1 NOTES
 
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index a383eee..d7908e5 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -320,7 +320,7 @@ int ssl3_connect(SSL *s)
 case SSL3_ST_CR_CERT_A:
 case SSL3_ST_CR_CERT_B:
 /* Check if it is anon DH/ECDH, SRP auth */
-/* or PSK */
+/* or plain PSK */
 if (!
 (s-s3-tmp.
  new_cipher-algorithm_auth  (SSL_aNULL | SSL_aSRP))
@@ -1367,9 +1367,9 @@ int ssl3_get_key_exchange(SSL *s)
 }
 #ifndef OPENSSL_NO_PSK
 /*
- * In plain PSK ciphersuite, ServerKeyExchange can be omitted if no
- * identity hint is sent. Set session-sess_cert anyway to avoid
- * problems later.
+ * In PSK ciphersuites, ServerKeyExchange can be omitted if no
+ * identity hint is sent. Set session-sess_cert for plain PSK
+ * anyway to avoid problems later.
  */
 if (alg_k  SSL_kPSK) {
 s-session-sess_cert = ssl_sess_cert_new();
@@ -1414,7 +1414,12 @@ int ssl3_get_key_exchange(SSL *s)
 al = SSL_AD_DECODE_ERROR;
 
 #ifndef OPENSSL_NO_PSK
-if (alg_k  SSL_kPSK) {
+/* handle PSK identity hint */
+if (alg_k  (SSL_kPSK
+#ifndef OPENSSL_NO_RSA
+ | SSL_kRSAPSK
+#endif
+ )) {
 char tmp_id_hint[PSK_MAX_IDENTITY_LEN + 1];
 
 param_len = 2;
@@ -1569,7 +1574,11 @@ int ssl3_get_key_exchange(SSL *s)
 } else
 #endif  /* !OPENSSL_NO_SRP */
 #ifndef OPENSSL_NO_RSA
-if (alg_k  SSL_kRSA) {
+if (alg_k  (SSL_kRSA
+#ifndef OPENSSL_NO_PSK
+ | SSL_kRSAPSK
+#endif
+ )) {
 /* Temporary RSA keys 

Re: [openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings

[Roumen Petrov via RT]

Mike Frysinger via RT wrote:
 atm, the windres code in openssl is only usable via the cross-compile prefix
 option unlike all the other build tools.  So add support for the standard $RC
 / $WINDRES env vars as well.
 ---
 [SNIP]
   else{
   s/^CC=.*$/CC= $cc/;
   s/^AR=\s*ar/AR= $ar/;
   s/^RANLIB=.*/RANLIB= $ranlib/;
 + s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
   s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc || ($cc eq 
 'cc'  $target =~ /darwin/);
   }
Is above line correct ?

[SNIP]
Regards,
Roumen


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

[openssl-dev] [PATCH] Clean up portable implementation of ROTL

[關振德]

Clean up portable implementation of ROTL so that there is no
 undefined behaviour in shift and some commonly used compilers can
generate efficient code using rotate instructions.  This is tested on
x86_64, little-endian POWER and aarch64 with gcc-4.9 and current top
of trunk clang.  Both compilers generate native rotation instructions
for 32-bit inputs.  Since the portable implementation is now clean,
there is no need for the special code guarded by PEDANTIC.

---
 crypto/cast/cast_lcl.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/crypto/cast/cast_lcl.h b/crypto/cast/cast_lcl.h
index b0f0829..588da44 100644
--- a/crypto/cast/cast_lcl.h
+++ b/crypto/cast/cast_lcl.h
@@ -152,10 +152,8 @@

 #if defined(OPENSSL_SYS_WIN32)  defined(_MSC_VER)
 # define ROTL(a,n) (_lrotl(a,n))
-#elif defined(PEDANTIC)
-# define ROTL(a,n) a)(n))0xL)|((a)((32-(n))31)))
 #else
-# define ROTL(a,n) a)(n))0xL)|((a)(32-(n
+# define ROTL(a,n) a)(n))|((a)(-(n)31)))0xL)
 #endif

 #define C_M0x3fc
-- 
2.2.0.rc0.207.ga3a616c
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings

[Mike Frysinger via RT]

atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools.  So add support for the standard $RC
/ $WINDRES env vars as well.
---
 Configure   | 3 +++
 Makefile.org| 2 ++
 Makefile.shared | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Configure b/Configure
index 5dbfa6c..080cfe2 100755
--- a/Configure
+++ b/Configure
@@ -744,6 +744,7 @@ my $shared_extension = $fields[$idx_shared_extension];
 my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
 my $ar = $ENV{'AR'} || ar;
 my $arflags = $fields[$idx_arflags];
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || windres;
 my $multilib = $fields[$idx_multilib];
 
 # if $prefix/lib$multilib is not an existing directory, then
@@ -1210,12 +1211,14 @@ while (IN)
s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+   s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc 
eq gcc;
}
else{
s/^CC=.*$/CC= $cc/;
s/^AR=\s*ar/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
+   s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc || ($cc eq 
'cc'  $target =~ /darwin/);
}
s/^CFLAG=.*$/CFLAG= $cflags/;
diff --git a/Makefile.org b/Makefile.org
index 50f7ae2..83fa45a 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -66,6 +66,7 @@ EXE_EXT=
 ARFLAGS=
 AR=ar $(ARFLAGS) r
 RANLIB= ranlib
+WINDRES= windres
 NM= nm
 PERL= perl
 #RM= echo --
@@ -216,6 +217,7 @@ BUILDENV=   PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' 
\
CC='$(CC)' CFLAG='$(CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+   WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index babeb46..e8903ca 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -282,7 +282,7 @@ link_a.cygwin:
fi; \
dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
$(PERL) util/mkrc.pl $$dll_name | \
-   $(CROSS_COMPILE)windres -o rc.o; \
+   $(WINDRES) -o rc.o; \
extras=$$extras rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
-- 
2.3.1


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

Re: [openssl-dev] [patch] fix allocation in e_capi

[Stefan Küng]

 Hi,

 There's a memory allocation on the stack in engines/e_capi.c which
 allocates only half of the required memory.
 This then leads to stack corruption.
 Attached a simple and small patch that fixes this.


Sorry, false alarm.
'len' is already in bytes.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [patch] fix allocation in e_capi

[Stefan Kueng]

Hi,

There's a memory allocation on the stack in engines/e_capi.c which 
allocates only half of the required memory.

This then leads to stack corruption.
Attached a simple and small patch that fixes this.

Stefan
Index: e_capi.c
===
--- e_capi.c(revision 26275)
+++ e_capi.c(working copy)
@@ -1189,7 +1189,7 @@
 return 0;
 }
 if (sizeof(TCHAR) != sizeof(char))
-name = alloca(len);
+name = alloca(len * sizeof(WCHAR));
 else
 name = OPENSSL_malloc(len);
 if (!CryptEnumProviders(idx, NULL, 0, ptype, name, len)) {
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Daniel Kahn Gillmor]

On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote:
 On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote:
 On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote:
 Add missing forward declarations and export declarations for DHparams
 and EC[PK]PARAMETERS.

 Add public functions to convert between EC_GROUP objects and 
 EC[PK]PARAMETERS
 objects: EC_GROUP_new_from_ec[pk]parameters(), 
 EC_GROUP_get_ec[pk]parameters().
 
 fwiw, the IETF TLS WG is moving away from the possibility of arbitrary
 EC groups, and toward the requirement of specified and vetted EC
 groups.  I'm not sure how much extra work should be done to maintain
 that as a public-facing interface.

 As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited
 to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but 
 for
 the 'low level' libcrypto library, which is in my opinion a general purpose 
 crypto
 library. As such, it should not make assumptions on or impose restrictions to 
 possible
 use cases of the library. Neither should it enforce standards, but provide 
 algorithms.

 My patch does not introduce new features or change existing ones. It just 
 makes
 functionality available for reuse. I needed this particular functionality and 
 I 
 had the choice between 1) copy  paste the code 2) patch OpenSSL privately, or
 3) submit a patch. So I chose the latter.

Your choice of action makes sense to me, thanks!

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Salz, Rich]

  3) submit a patch. So I chose the latter.
 
 Your choice of action makes sense to me, thanks!

Thanks for the patch, it seems useful and makes sense.

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

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

[Dr. Matthias St. Pierre]

Hello,

On 01/28/2015 12:52 AM, Matt Caswell wrote:
 Please submit patches to r...@openssl.org.

Sorry about that, I will repost it.

I overlooked https://www.openssl.org/support/rt.html. Instead, 
I followed the FAQ which sent me to the README file, and there 
was no mention of the request tracker. 

Maybe you could update the FAQ and the README accordingly?


Matthias

see
https://www.openssl.org/support/faq.html#MISC3
https://github.com/openssl/openssl/blob/master/README

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