RE: [openssl.org #3451] patch for x509.c

[Salz, Rich]

> date '+%Y%m%d%H%M%SZ' -d '1 month 12 hours'

Wow.  Old code never dies; that's "my" get_date code from August 1990 :)

/r$

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

openssl apps; flags, parsing dates, etc.

[Salz, Rich]

> I agree with that as well. I did not look at the actual code in openssl so I 
> did
> not know that the fractional argument with the current version does not
> error out.

I have a branch that adds pretty comprehensive option-checking to all the 
openssl commands:
; ./openssl x509 --CA /no/such/file
x509: Cannot open input file /no/such/file, No such file or directory
x509: Use -help for summary.
; ./openssl x509 -days 1.2
x509: Invalid number "1.2" for -days
x509: Use -help for summary.
; ./openssl rsa -out /vmlinuz
rsa: Cannot open output file /vmlinuz, Permission denied
rsa: Use -help for summary.

I know I broke some things; please try things out.  The branch is here:
  https://github.com/akamai/openssl/tree/rsalz-monolith

This is NOT planned for 1.0.2, but hopefully the very next one after that.


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

RE: openssl apps; flags, parsing dates, etc.

[Salz, Rich]

> You've declared "-days" to take only positive numbers, it should allow
> negative numbers.

Pushed, thanks.

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

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

RE: openssl apps; flags, parsing dates, etc.

[Salz, Rich]

> "keyform", OPT_KEYFORM, 'f', "Private key file format (PEM or ENGINE)"
> 
> while the valid choices seem to be PEM or DER, not PEM or ENGINE:

No, it depends on the command.  Some, for example, expect keys to be stored in 
the ENGINE (presumably an HSM).
The docs are often outdated.  But pem/der is the majority of choices.

The right thing to do is change opt_format to be generic, and specify exactly 
which types of formats are supported.

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

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

RE: openssl apps; flags, parsing dates, etc.

[Salz, Rich]

> The right thing to do is change opt_format to be generic, and specify exactly
> which types of formats are supported.

Done and pushed.  Some of the bit-settings are probably more loose than I'd 
like, but it works.

/r$

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

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

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

[Salz, Rich]

Yes, you’re totally right about the root cause being poor abstractions.

We will probably remove all mention of MSDOS, which should be another way to 
fix the problem, right?

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

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

[Salz, Rich]

You are preaching to the choir.  Look at the rsalz-monolith branch in 
akamai/openssl on github.
If you have a patch to go into that, I'll take it right away.

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

[Salz, Rich]

We’re going to address the larger issues, in time.  For now:  does removing 
MSDOS fix the problem?

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

RE: [openssl.org #3467] FW: Critical vulnerabilities found (#8083-432678597-2590)

[Salz, Rich]

Where did you get your SSL package?  Did it come with the OS?  If so, then ask 
them for an update.
If not, then where did you get it?  Contact them.
If you built it internally, you'll have to learn or buy expertise.
--  
Principal Security Engineer, Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

GCC performance hack

[Salz, Rich]

If you're doing multi-threaded builds with GCC, the following performance hack 
can help a great deal.

#ifdef _GNU_SOURCE
int gnu_builtin_sync(int *pointer, int amount, int type, const char *file,  int 
line)
{
  int ret;

  if (amount > 0)
ret = __sync_add_and_fetch(pointer, amount);
  else if (amount < 0)
  {
int diff = abs(amount);
ret = __sync_sub_and_fetch(pointer, diff);
  }
  else
ret = *pointer;

  return ret;
}
#endif

Then when you set up your locking, do this:
CRYPTO_set_add_lock_callback(gnu_builtin_sync);

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

RE: [LibReSSL] Allow key generation to use arbitrary public exponents

[Salz, Rich]

> I'd like to propose to include the following additional two command line
> arguments for the openssl binary when creating RSA keys. While the patch is

This seems reasonable, thanks.

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


> -Original Message-
> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org] On Behalf Of Benny Baumann
> Sent: Saturday, August 09, 2014 9:22 AM
> To: openbsd-t...@openbsd.org; openssl-dev@openssl.org
> Subject: [LibReSSL] Allow key generation to use arbitrary public exponents
> 
> Hi,
> 
> written to apply to LibReSSL 2.0.5 it should apply to genrsa.c of OpenSSL 
> 1.0.1
> just fine too.
> 
> While the default of 65537 is a sane default it's not strictly forced by any
> standard. In contrast when looking at NIST SP-800-56B section 6.2.1 bullet 2b
> it is described as "an odd positive integer such that 65537 <= e < 2**256"
> 
> As the plain RSA only requires e to be co-prime to both p-1 and q-1 and given
> the obvious limitation for e=1 yielding no security, there is no mathematical
> backing for any upper bound for e (except the obvious one given by p*q-1).
> 
> The change only affects the key generation and extends the possibility to use
> custom public exponents as has been done in certain areas previously.
> Implementations conforming to the mathematical foundation should be
> unaffected as otherwise they would have been broken for decryption all
> along.
> 
> Kind regards,
> Benny Baumann
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

If you use kerberos/ssl

[Salz, Rich]

Can you take a look at http://rt.openssl.org/Ticket/Display.html?id=549
And let us know what you think?

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

RE: Forcing client to send Certificate record

[Salz, Rich]

> There is no need for an API for a non-interoperable feature that would
> violate the TLS protocol:
> 
> https://tools.ietf.org/html/rfc5246#section-7.4.6

Perhaps more usefully, see 
http://datatracker.ietf.org/doc/draft-thomson-tls-care/

This will almost definitely be part of TLS 1.3.  Note that it's 
version-neutral, so it will probably show up in other stacks as well.
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

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

RE: Question in regards to early warning about new openssl versions

[Salz, Rich]

Thanks for your kind words.  We do post a notice that we're putting out a 
security update.  Not sure how you missed it...

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

session cache and multiple threads

[Salz, Rich]

What's the programming model for using session cache with a multi-threaded 
server?
When a client connections, a refcount on the object is incremented. But then 
fields can be changed (such as ecpointformat).  Does it make more sense for 
session to deep-copy the session from the cache?

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

RE: session cache and multiple threads

[Salz, Rich]

We're using the standard internal session (maintained per SSL_CTX object); not 
tickets.

We're seeing that the sessions are shared, a refcount is maintained, but that 
SSL does modified fields within a session while it's being used.  Most notably 
an address sanitizer build found the EC point stuff being mangled.

It seems there are bugs in the OpenSSL stuff.

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

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

Netware support?

[Salz, Rich]

Is anyone willing to step up and maintain the Netware port?

If not, then we will probably remove it after the next release.

/r$

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

RE: Netware support?

[Salz, Rich]

> please dont do that! I maintained it in the past (and try to do in future as 
> my
> time permits), and currently it still builds (except for asm support were ich

Okay.  Thanks for your efforts.

The NETWARE port is really messy, with about 130 #ifdef flags in 70 files.  It 
would be great if we could reduce that impact.  And are NETWARE_BSDSOCK and 
NETWARE_CLIB still useful?

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

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

RE: Netware support?

[Salz, Rich]

Thanks for the info!

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: Single-Makefile Build Experiment report

[Salz, Rich]

> Just a comment. the OpenSSL build already depends on Perl and Perl already
> has a "Make" of it's own .

Ooh, that could be interesting.  What's the perl make thing called?  A web 
search for "perl make" was too voluminous...

/r$

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

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

RE: [openssl.org #2483] X509 conversions

[Salz, Rich]

> Problem solved by me three years ago. Still using old platform. Works fine.

Glad it works!  Anything worth sharing or was it very specific?

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

RE: [openssl.org #832] ocsp and dsa key+socket option SO_REUSEADDR for responder

[Salz, Rich]

Ugh, you're right.  Re-opening this.  BIO sockets are a tangle that will take 
some time to figure out.

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

RE: [openssl.org #2917] [PATCH] dsa: fix return code when -noout is used

[Salz, Rich]

> Why not fix in 1.0.2?

That’s a good question.  No single reason stounds out, but a handful of smaller 
ones:
I'm lazy
Still a git newbie
1.0.2 has already had multiple release candidate/beta releases
This bug is two years old and been around forever and doesn't seem high 
priority
I want more people testing the monolith branch
Want to social the "fixed in next release" concept

If folks don't find it compelling -- or, rather, someone says backport the 
three-line fix, I'll do it :)

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

Platform query

[Salz, Rich]

Does anyone want to speak up for the requirement that we continue to support 
BEOS (apparently B/1 and R5?), OS/2, or pre-Windows MSDOS?

Unless there is strong interest and commitment, we will drop these after 1.0.2

/r$

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

RE: Platform query

[Salz, Rich]

> Minor clarification is appropriate. MSDOS is supported in single "stance",
> namely DJGPP, which is 32-bit environment.

Good point.

So the idea is that MSDOS gets turned into DJGPP.  BEOS and OS/2 are removed in 
HEAD (i.e., after 1.0.2), and Microsoft means WINDOWS of various flavors.

If this is a problem for anyone, please speak up now.
/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: Platform query

[Salz, Rich]

I'm not sure what WINDOWS means. And I'm not sure MSFT knows either :)

Less flippantly, the goal is that OPENSSL_SYS_WINDOWS means any Windows 
platform, and then there are subtypes within that.  We'll figure it out as we  
go along.  It's gonna take a while to clean up the #ifdef world without 
breaking folks, but we're trying to address it per our roadmap, 
https://www.openssl.org/about/roadmap.html .

/r$

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

RE: Platform query

[Salz, Rich]

Thanks for the feedback!

There are 70 files that have OS2 in them, for a total of 130 instances.  That's 
rather a lot for a platform that hasn't had an update in five years.

This is my personal opinion, as a team member.  We will release 1.0.2 this 
year.  At that time we will announce end of life for some platforms.  This 
means that they only get bugfixes, and only in 1.0.2. I hope we release 1.0.3, 
or whatever it's called, in 2015.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: AW: Platform query

[Salz, Rich]

> So I would not understand that we go in a hurry to remove WCE compatibility

I do not think we are in a hurry to do that.

Your patch looks nice.  I am CC'ing rt, so that this thread becomes an issue 
and we'll see the link to your mail.

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


> -Original Message-
> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org] On Behalf Of Pierre DELAAGE
> Sent: Thursday, August 21, 2014 6:05 AM
> To: openssl-dev@openssl.org
> Subject: Re: AW: Platform query
> 
> Dear All,
> At least for WCE, I can say that with this patch:
> https://www.mail-archive.com/openssl-dev@openssl.org/msg35958.html
> 
> which is W32 compatible and NOT WCE specific, and consists of only one
> typedef (which is highly clarifying the code ALSO for win32) and one CAST
> error (cast error that SHOULD be corrected ALSO for win32 platform),
> Openssl 1.1.0 master20140721  is perfectly working for WC5/WM6/WM7, and
> still compatible with w8 phones and CE SDK 2013 (yes it does exist).
> 
> while, most of the time (and after improvment in the past to switch to
> winsock2) , WCE code is just the same as win32 desktop code.
> 
> Yours sincerely
> Pierre Delaage
> 
> 
> 
> Le 20/08/2014 18:32, stefan.n...@t-online.de a écrit :
> > And a question concerning a different platform. Is there any interest
> > in integrating "official" support for Windows Phone (old win CE "of
> > course" is something largely different...)?
> 
> 
> __
> 
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: Platform query

[Salz, Rich]

> Did I miss something, or did you happen to count the includes of "e_os2.h"
> which is not OS/2 specific at all? Or both?

No, I made the stupid mistake.

> The current version of eComStation, 2.1, was released only a year
> after version 2.0, in May 2011.

We were not aware of eComStation.  Thanks.  Still not clear that 
OS/2&eComStation are a viable platform to support, but something to think about.

/r$

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

RE: [openssl.org #3497] Move dclean actions to clean

[Salz, Rich]

> Just generated a pull request for this; let me know if it's what you actually
> had in mind:
> 
> https://github.com/openssl/openssl/pull/161

I already had the fix in-hand :)  See attached.



--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
--- Begin Message ---
commit e02129dea29f7d091ce301b4f34e05559bb840d3
Author: Rich Salz 
Date:   Thu Aug 21 12:45:28 2014 -0400

RT3497: (re)move actions from dclean to clean

Remove all special actions (anything other than building
dependencies) from dclean target to clean target.
Also, consistently use RECURSIVE_MAKE (not RECURSIVE_BUILD_CMD)
for all Makefiles that did recursive builds.

diff --git a/Makefile.fips b/Makefile.fips
index b3811df..84a85f0 100644
--- a/Makefile.fips
+++ b/Makefile.fips
@@ -251,23 +251,23 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' 
\
 # BUILD_CMD is a generic macro to build a given target in a given
 # subdirectory.  The target must be given through the shell variable
 # `target' and the subdirectory to build in must be given through `dir'.
-# This macro shouldn't be used directly, use RECURSIVE_BUILD_CMD or
-# BUILD_ONE_CMD instead.
+# This macro shouldn't be used directly, use RECURSIVE_MAKE or
+# MAKE_ONE instead.
 #
-# BUILD_ONE_CMD is a macro to build a given target in a given
-# subdirectory if that subdirectory is part of $(DIRS).  It requires
-# exactly the same shell variables as BUILD_CMD.
-#
-# RECURSIVE_BUILD_CMD is a macro to build a given target in all
+# RECURSIVE_MAKE is a macro to build a given target in all
 # subdirectories defined in $(DIRS).  It requires that the target
 # is given through the shell variable `target'.
+#
+# MAKE_ONE is a macro to build a given target in a given
+# subdirectory if that subdirectory is part of $(DIRS).  It requires
+# exactly the same shell variables as BUILD_CMD.
 BUILD_CMD=  if [ -d "$$dir" ]; then \
(   cd $$dir && echo "making $$target in $$dir..." && \
$(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target 
\
) || exit 1; \
fi
-RECURSIVE_BUILD_CMD=for dir in $(DIRS); do $(BUILD_CMD); done
-BUILD_ONE_CMD=\
+RECURSIVE_MAKE=for dir in $(DIRS); do $(BUILD_CMD); done
+MAKE_ONE=\
if expr " $(DIRS) " : ".* $$dir " >/dev/null 2>&1; then \
$(BUILD_CMD); \
fi
@@ -364,7 +364,7 @@ build_all: build_libs
 build_libs: build_crypto build_fips

 build_fips:
-   @dir=fips; target=all; [ -z "$(FIPSCANLIB)" ] || $(BUILD_ONE_CMD)
+   @dir=fips; target=all; [ -z "$(FIPSCANLIB)" ] || $(MAKE_ONE)

 build_crypto:
if [ -n "$(FIPSCANLIB)" ]; then \
@@ -378,23 +378,23 @@ build_crypto:
else \
AS='$(CC) -c' ; \
fi ; export AS ; \
-   dir=crypto; target=fips; $(BUILD_ONE_CMD)
+   dir=crypto; target=fips; $(MAKE_ONE)
 build_ssl:
-   @dir=ssl; target=all; $(BUILD_ONE_CMD)
+   @dir=ssl; target=all; $(MAKE_ONE)
 build_engines:
-   @dir=engines; target=all; $(BUILD_ONE_CMD)
+   @dir=engines; target=all; $(MAKE_ONE)
 build_apps:
-   @dir=apps; target=all; $(BUILD_ONE_CMD)
+   @dir=apps; target=all; $(MAKE_ONE)
 build_tests:
-   @dir=test; target=fipsexe; $(BUILD_ONE_CMD)
+   @dir=test; target=fipsexe; $(MAKE_ONE)
 build_algvs:
-   @dir=test; target=fipsalgvs; $(BUILD_ONE_CMD)
+   @dir=test; target=fipsalgvs; $(MAKE_ONE)
 build_tools:
-   @dir=tools; target=all; $(BUILD_ONE_CMD)
+   @dir=tools; target=all; $(MAKE_ONE)

 all_testapps: build_libs build_testapps
 build_testapps:
-   @dir=crypto; target=testapps; $(BUILD_ONE_CMD)
+   @dir=crypto; target=testapps; $(MAKE_ONE)

 libcrypto$(SHLIB_EXT): libcrypto.a build_fips
@if [ "$(SHLIB_TARGET)" != "" ]; then \
@@ -503,11 +503,12 @@ libclean:

 clean: libclean
rm -f shlib/*.o *.o core a.out fluff testlog make.log cctest cctest.c
-   @set -e; target=clean; $(RECURSIVE_BUILD_CMD)
+   @set -e; target=clean; $(RECURSIVE_MAKE)
rm -f $(LIBS)
rm -f openssl.pc libssl.pc libcrypto.pc
rm -f speed.* .pure
rm -f $(TARFILE)
+   rm -rf *.bak include/openssl certs/.0
@set -e; for i in $(ONEDIRS) ;\
do \
rm -fr $$i/*; \
@@ -519,12 +520,12 @@ makefile.one: files

 files:
$(PERL) $(TOP)/util/files.pl Makefile > $(TOP)/MINFO
-   @set -e; target=files; $(RECURSIVE_BUILD_CMD)
+   @set -e; target=files; $(RECURSIVE_MAKE)

 links:
@$(PERL) $(TOP)/util/mkdir-p.pl include/openssl
@$(PERL) $(TOP)/util/mklink.pl include/openssl $(EXHEADER)
-   @set -e; dir=fips target=links; $(RECURSIVE_BUILD_CMD)
+   @set -e; dir=fips target=links; $(RECURSIVE_MAKE)
@(cd crypto ; SDIRS='$(LINKDIRS)' $(MAKE) -e links)

 gentests:
@@ -532,8 +533,7 @@ gentests:
$(CLEARENV) && $(MAKE) -e $(BUILDENV) TESTS='$(TESTS)' 
OPENSSL_DEBUG_MEMORY=on generate );

 dclean:
-  

RE: nameConstraints bypass bug

[Salz, Rich]

It'd be good to fix this.

Opening an RT (email to r...@openssl.org) is the simplest way. Thanks!

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

RE: [openssl.org #3505] rewrite c_rehash in C

[Salz, Rich]

> Find a C version (which I have written) of the utility at:
> http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c

That's pretty cool.  We'd need to modify it to not use the XXXat functions or 
fnmatch, but definitely something we should consider for a future release. 

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

RE: [openssl.org #3503] BUG: "make dclean" deletes the test/ directory, which results in duplicate symbols on subsequent make's

[Salz, Rich]

I changed the bug title, since the test directory isn't ever removed.  But yes, 
something strange is going on.

:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #3505] rewrite c_rehash in C

[Salz, Rich]

Don't rush.  It'll be a while until (or if) we switch over.  Neat job tho. 
Perhaps it should be merged into the openssl command?
(see https://github.com/akamai/openssl/tree/rsalz-monolith)
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

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

RE: [openssl.org #3505] rewrite c_rehash in C

[Salz, Rich]

BTW, as you work on this, also take a look at RT items 2272 and 2973 :)

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

RE: official repository vs forks, and fixes

[Salz, Rich]

Think of this as pre-release software.  The changes are too large to disrupt 
the 1.0.2 release, which is already in beta.

We haven’t yet figured out how to make early-access to branches available, so 
for now I just did it via Akamai.  At some point, I’d expect that branch to 
“move” over to openssl’s repo, but we’re not there yet.

Make sense?

/r$

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

RE: official repository vs forks, and fixes

[Salz, Rich]

> FWIW, most of us picking up 1.0.2 will be in it for the long haul, I wouldn't 
> expect many to shift from 1.0.2 again to 1.0.3 over the course of a year or 
> several.  It might be worth rethinking the 1.0.2 release plan to pick

I understand the concern.  But we have already declared that 1.0.2 is frozen 
except for fixes. And we have some other changes coming post-1.0.2 that we 
don't want to delay.  For example, I'd expect TLS1.3 to be in, well, 1.0.3 or 
whatever we call it.

/r$

:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: official repository vs forks, and fixes

[Salz, Rich]

> Would it be an idea to create branches in the official repo for (certain 
> classes of) bugfixes, which can be merged onto the respective branches at set 
> times ? For instance one for documentation fixes ? You could

Yes.  But we (the dev team) haven't figured out all of the details of our 
workflow yet.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich]

> i don't think that's really true.  else, why is autoconf & friends relying on 
> a
> shell and not perl ?  those see way more distribution than openssl.

Last I looked, autoconf doesn't use anything that really wasn't in Version 7 
Bourne shell.  In my comment, I deliberately used the term "posix shell"

But to my mind, the question is moot, since post-1.0.2 we'll almost definitely 
have c_rehash builtin to the openssl command.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich]

These all first appeared in ksh: functions, local, return, $((math))

> > But to my mind, the question is moot, since post-1.0.2 we'll almost
> > definitely have c_rehash builtin to the openssl command.
> 
> that would also work

:)

It will also be much much much faster, since it doesn't have to call 'openssl 
x509' all the time.

/r$

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

RE: [openssl.org #2451] [PATCH] Enhancement: Telnet START_TLS in s_client

[Salz, Rich]

Right, oops.  Thanks
; git show b56d251
commit b56d251ad332edae0d252816b7c21548c85a1007
Author: David Michael 
Date:   Sat Aug 30 09:43:06 2014 -0400

RT2451:

I switched the cascading if/else-if to a switch and missed a break
statement; David caught it.

diff --git a/apps/s_client.c b/apps/s_client.c
index 4b4b136..e05cd24 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1607,6 +1607,7 @@ SSL_set_tlsext_status_ids(con, ids);
goto shut;
mbuf[0] = 0;
}
+   break;
case PROTO_TELNET:
{
static const unsigned char tls_do[] = {
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #2990] Bug Report:openssl timezone issue

[Salz, Rich]

Not according to the PKIX RFC 5280
   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.
   Conforming applications MUST be able to process validity dates that
   are encoded in either UTCTime or GeneralizedTime.

Of course, you may not need IETF PKIX compliant certificates.  Apparently you 
can create them with openssl, but you can't display them.

What you probably want is a way to input data in any timezone and have it 
always made pkix-conformant in the certificate. That's an open item, part of 
larger work on times, offsets, durations, etc.  To be addressed in a future 
release.
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #2665] s_client support for starttls ldap

[Salz, Rich]

What about usoing stunnel?

RE: [openssl.org #3512] SSL_MODE_ENABLE_PARTIAL_WRITE does not work in DTLS

[Salz, Rich]

You can't use partial writes.

The size of your UDP packet depends on the MTU supported by everyone along the 
path.  (BTW, that's what heartbeat was created.)

I suggest you get your program working "properly" for your definition of what 
properly means, without DTLS.  Then add DTLS.

And have you read the paper I pointed you to?
/r$

RE: [openssl.org #2665] s_client support for starttls ldap

[Salz, Rich]

My point is that since stunnel has a different goal of wrapping almost any 
protocol, that might be a better place for it, rather than going down the 
slippery slope of putting a binary hack into s_client which wouldn't let you 
actually USE the protocol.

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

RE: openssl 1.0.1i ignores ciphers in cipherlist

[Salz, Rich]

If Frank doesn't want SSLv2 then he needs to disable it in the SSL_CTX first, 
no?

The mechanism to say what ciphers you want is orthogonal to the mechanism to 
say what protcols you want. That's unfortunate and a source of confusion, but 
is unlikely to change any time soon.


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

:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: apps/ts.c patch - engine support

[Salz, Rich]

> Of no less importance is to emphasise that it adds additional "keyform"
> parameter to functions defined in ts.c and utilized by "-reply" function, that
> will *break* compatibility with any previously existing code.

How does it break?  We don't care about source-level compatibility within the 
apps directory.  I skimmed the patch, so I don't see any issues.

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




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

RE: [openssl.org #3494] Possible sign bit bug in openssl 1.0.1i handling of 128-bit serial numbers

[Salz, Rich]

It is wrong because the 16 bytes wil be interpreted as a negative number and 
that's not allowed so you have to put a leading 0 byte there.

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

RE: [openssl.org #3494] Possible sign bit bug in openssl 1.0.1i handling of 128-bit serial numbers

[Salz, Rich]

> RFC 5280 requires that serial numbers MUST be positive, negative serial
> numbers do not conform with RFC (see 4.1.2.2).

Yes, thanks for the clarification.

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

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

RE: [openssl.org #3470] [BUG] DTLS abort

[Salz, Rich]

Partial writes do not work over UDP; by design.

As to whether or not you can use a packet as big as 16K, in depends on the 
"path MTU" -- what's the maximum transmission size between you and the 
destination, along the communication path.  You'll have to make your packets 
smaller then that.  This isn't, really, an openssl issue.

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

RE: apps/ts.c patch - engine support

[Salz, Rich]

> You are right - it should not break anything as the patch only affects the ts
> app.

I put this on my dev branch for post-1.0.2 release: 
https://github.com/akamai/openssl/tree/rsalz-monolith


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

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

RE: [openssl.org #3203] Normalize PFS key exchange labels

[Salz, Rich]

I think there's interest for 1.0.1 and beyond.

But I thought we already had a similar alias mechanism?

The no-stdio and NO_FP_API options

[Salz, Rich]

These configuration options do not build. I started to try and fix them, but 
after fixing the first few problems, things got really sticky.

We hear that OpenSSL on embedded devices is important. Is anyone using this, 
willing to share their fixes, and help maintain it?  If not, it will be removed 
post-1.0.2

Thanks.

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

RE: [openssl.org #839] Patch pk7_lib.c:PKCS7_get_recip_info()

[Salz, Rich]

> Does it mean that S/MIME ops will be deprecated?

No.  Just that this is an old bug and that CMS_xxx is the way forward.  At some 
point it'd be nice to have an SMIME3_xxx API, but I wouldn't hold my breath :)

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

RE: [openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

[Salz, Rich]

> Anyone?

This mail was sent one minute after your previous mail.  A little patience 
perhaps? :)


:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

Updating roadmap objectives: RT backlog

[Salz, Rich]

We've updated the roadmap, https://www.openssl.org/about/roadmap.html with 
information about our progress on the RT backlog:
Update (8th September 2014): we have made a great deal of progress on 
the backlog. A graph of ticket activity[1] is available, as is the raw data[2]  
for every bug showing when it was open, and resolved. We will update these 
files periodically.

[1] https://www.openssl.org/about/ticket-activity.png
[2] https://www.openssl.org/about/buglist.txt 

Thanks for your interest and support.

/r$

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


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

RE: [openssl.org #3520] [PATCH] 1.0.1e: Configure: Correctly Handle GCC/clang/LLVM -arch and -isysroot Options

[Salz, Rich]

Can we handle this like ticket 3521 and do -arch= ? And split that up into 
"-arch " ?


:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #2560] missing NULL pointer check in ocsp_req_find_signer

[Salz, Rich]

> It is from real world application. In some case the X509_find_by_subject
> (called from ocsp_req_find_signer) returned NULL, and the whole
> application halted.

Ah, I misunderstood the ticket.  Add "if (!signer) return 0;" after the call to 
X509_find_by_subject.

I'll submit that shortly.  Thanks!
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #3523] bug report: s_client writes to STDERR

[Salz, Rich]

Can you cut/paste the output you're getting?  I think this is fixed in the 
post-1.0.2 branch at least.

RE: Outstanding issues since 2014 09 09

[Salz, Rich]

> making install in engines/ccgost...

Fixed, sorry for the inconvenience.

OpenSSL_1_0_2-stable 3258429 RT3271 update; extra; semi-colon; confuses; some;
master   cb4bb56 RT3271 update; extra; semi-colon; confuses; some;

Author: Rich Salz 
Date:   Wed Sep 10 15:05:38 2014 -0400

RT3271 update; extra; semi-colon; confuses; some;

Reviewed-by: Kurt Roeckx 
;
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #3525] CRL tool doesn't show leading 0's in output

[Salz, Rich]

I think the bug is that we need to ouput a leading zero to avoid confusing the 
number as negative.

:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

Adding GET support to ocsp app

[Salz, Rich]

The attached diff adds GET support to ocsp.  I'd appreciate any feedback.


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



ocsp-get.patch
Description: ocsp-get.patch

RE: [openssl-dev] Adding GET support to ocsp app

[Salz, Rich]

> I don't see where the OCSP request is de-base64-ified, and URL-decoded.
> In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but it's 
> done directly on the HTTP request line for a GET.

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

Windows folks -- comment on this patch for RT 2301?

[Salz, Rich]

Any input from Windows folks on the attached?


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



rt2301.patch
Description: rt2301.patch

RE: [openssl.org #3530] Problems measuring openssl speed

[Salz, Rich]

Thanks for working on this.

I haven’t looked at the patch yet. Can we just put the constants in engine.h?


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

RE: Windows folks -- comment on this patch for RT 2301?

[Salz, Rich]

Great to hear it from the source, thanks!


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

From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On 
Behalf Of Gilles Khouzam
Sent: Tuesday, September 16, 2014 1:37 PM
To: openssl-dev@openssl.org
Subject: RE: Windows folks -- comment on this patch for RT 2301?

Hi Rich,

This looks good.

Thanks.

Gilles Khouzam
Senior Development Lead
Microsoft OSG

From: owner-openssl-...@openssl.org<mailto:owner-openssl-...@openssl.org> 
[mailto:owner-openssl-...@openssl.org] On Behalf Of Salz, Rich
Sent: Sunday, September 14, 2014 12:05
To: openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>
Subject: Windows folks -- comment on this patch for RT 2301?

Any input from Windows folks on the attached?


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

RE: [openssl.org #3534] When I build openssl-1.0.1i on Solaris 10, there are some error, please help to check what is the reason. Thanks.

[Salz, Rich]

> -DSHA512_ASM -DAES_ASM -DGHASH_ASM   -c -o md2test.o md2test.c
> md2test.c:1: error: syntax error before '.' token
> md2test.c:1:12: warning: no newline at end of file

Your copy of this file is corrupted.
; wc test/md2test.c
 48 148 955 test/md2test.c
;

RE: Integration of #2578

[Salz, Rich]

It's too late for 1.0.2, which is in feature-freeze and only getting bugfixes.  
But I'll put it in my branch on github for inclusion in the next release after.


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

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

RE: [openssl.org #3535] TS high-precision time malformation - demo

[Salz, Rich]

The default time comes from the gettimeofday() system call (see def_time_cb in 
ts_rsp_sign.c).
I don't see any openssl bug here.

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


> -Original Message-
> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org] On Behalf Of Michal Bozon via RT
> Sent: Thursday, September 18, 2014 7:55 AM
> Cc: openssl-dev@openssl.org
> Subject: [openssl.org #3535] TS high-precision time malformation - demo
> 
> Quick demonstration - doing a statistics on first decimal place digit of large
> number of time-stamps:
> 
> - sample output:
> ...
> ### BEFORE:
> 0: 0% <--- !
> 1:11%
> 2:11%
> 3:11%
> 4:10%
> 5:11%
> 6:11%
> 7:12%
> 8:12%
> 9:11%
> ### AFTER:
> 0:10%
> 1:10%
> 2:10%
> 3:10%
> 4:10%
> 5:10%
> 6:10%
> 7:10%
> 8:10%
> 9:10%
> 
> - script:
> #!/bin/sh
> 
> cp apps/openssl.cnf /tmp/ossl.cnf
> 
> cat <> /tmp/ossl.cnf
> [ tsa_test ]
> basicConstraints=CA:TRUE
> extendedKeyUsage=critical,timeStamping
> [ tsr_test ]
> clock_precision_digits  = 6
> serial = /tmp/serial
> default_policy = 2.999.0
> digests = sha1
> EOF
> 
> openssl req -x509 -newkey rsa:2048 -config /tmp/ossl.cnf -nodes -batch \
>   -extensions tsa_test -out /tmp/tsa_.pem -keyout /tmp/tsa_.pem
> 
> for ossl in openssl /usr/local/ssl/bin/openssl; do
>   [ $ossl = openssl ] && echo "### BEFORE:" || echo "### AFTER:"
>   for i in `seq 1 2000`; do
> $ossl ts -reply -config /tmp/ossl.cnf -queryfile /tmp/x.tsq \
>   -signer /tmp/tsa_.pem -inkey /tmp/tsa_.pem -section tsr_test \
>   | openssl ts -reply -in /dev/stdin -text \
>   | grep '^Time stamp'
>   done 2>/tmp/osslerr.out | perl -ne \
> '/\.(\d)/;$h{$1}++}{for(0..9){printf"%i:%2.f%%\n",$_,100*$h{$_}/$.}'
> done
> 
> 
> __
> 
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org

RE: [openssl.org #3535] TS high-precision time malformation - demo

[Salz, Rich]

Jeremy Farrell was kind enough off-list to provide me with a clue :) There is a 
bug in openssl formatting.

:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: TLS displayed as protocol when using SRP

[Salz, Rich]

I'm not sure what you're expecting, but no.  It's using TLS with an SRP crypto 
and that's what the output shows.

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

RE: [openssl.org #3539] x509 application supports additional fingerprint digests (sha2) not shown in help.

[Salz, Rich]

I understand your frustration. We've fixed bugs and added some features in 
1.0.2; 'git log apps' will show many entries.  Yes, not everything. We're also 
hoping to have more frequent releases so hopefully the wait won't be as long.  
And once we clean up some things, my branch will get merged into master, so it 
will be easier to pick up and use. And since's it's the command-line, and not 
the TLS implementation, hopefully it will be easier for folks to adopt just 
that.

This doesn't fully address your issue, but maybe it helps a bit.

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

RE: [openssl.org #3534] When I build openssl-1.0.1i on Solaris 10, there are some error, please help to check what is the reason. Thanks.

[Salz, Rich]

The error makes no sense.  The compiler is complaining about the include line?
Do "wc -l  md2test.c"
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

Platform removal

[Salz, Rich]

Starting with the next release after 1.0.2, we're planning on removing the 
following platforms from the codebase.
NeXT NEWS SUNOS
It looks like SUNOS can be handled by adding -Dssize_t=int as a compiler flag.

For your information, we have already removed BEOS, MWERKS and pre-OSx Mac 
support (__MWERKS__, MAC_OS_pre_X, MAC_OS_GUSI_SOURCE,  MAC_OS_pre_X, 
OPENSSL_SYS_MACINTOSH_CLASSIC, OPENSSL_SYS_MACOSX_RHAPSODY).  WIN16 is being 
actively removed; it never really worked.

If this will cause problems for anyone, and you are willing to maintain those 
platforms, please let me know. Again, these changes are planned for the next 
release after 1.0.2

For information about out platform strategy, please visit 
https://www.openssl.org/about/roadmap.html#platstrat 

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

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

RE: RE: [openssl.org #3534] When I build openssl-1.0.1i on Solaris 10, there are some error, please help to check what is the reason. Thanks.

[Salz, Rich]

Somehow the file that you have is corrupted.
It is not corrupted in the tar file.
It is a local error.
I do not know what the error is but mdtest.c on your disk is WRONG.

RE: [openssl-dev] Adding GET support to ocsp app

[Salz, Rich]

> I don't see where the OCSP request is de-base64-ified, and URL-decoded.
> In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but it's 
> done directly on the HTTP request line for a GET.

I forgot to post the updated patch.  Thanks Erwann.

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

diff --git a/apps/ocsp.c b/apps/ocsp.c
index fbc6b3f..073759f 100644
--- a/apps/ocsp.c
+++ b/apps/ocsp.c
@@ -1038,13 +1038,58 @@ static BIO *init_responder(const char *port)
return NULL;
}
 
+static int tohex(char c)
+   {
+   switch (c)
+   {
+   case '0': return 0;
+   case '1': return 1;
+   case '2': return 2;
+   case '3': return 3;
+   case '4': return 4;
+   case '5': return 5;
+   case '6': return 6;
+   case '7': return 7;
+   case '8': return 8;
+   case '9': return 9;
+   case 'A': case 'a': return 10;
+   case 'B': case 'b': return 11;
+   case 'C': case 'c': return 12;
+   case 'D': case 'd': return 13;
+   case 'E': case 'e': return 14;
+   case 'F': case 'f': return 15;
+   }
+   return 0;
+   }
+
+static char* urldecode(char* p)
+   {
+   unsigned char* out = (unsigned char *)p;
+   char* save = p;
+
+   for ( ; *p; p++)
+   {
+   if (*p == '+')
+   *out++ = ' ';
+   else if (*p != '%')
+   *out++ = *p;
+   else if (p[1] && p[2])
+   {
+   *out++ = (tohex(p[1]) << 4) | tohex(p[2]);
+   p += 2;
+   }
+   }
+   return save;
+   }
+
 static int do_responder(OCSP_REQUEST **preq, BIO **pcbio, BIO *acbio,
const char *port)
{
-   int have_post = 0, len;
+   int len;
OCSP_REQUEST *req = NULL;
-   char inbuf[1024];
-   BIO *cbio = NULL;
+   char inbuf[2048];
+   char *p, *q;
+   BIO *cbio = NULL, *getbio = NULL, *b64 = NULL;
 
if (BIO_do_accept(acbio) <= 0)
{
@@ -1056,29 +1101,53 @@ static int do_responder(OCSP_REQUEST **preq, BIO 
**pcbio, BIO *acbio,
cbio = BIO_pop(acbio);
*pcbio = cbio;
 
+   /* Read the request line. */
+   len = BIO_gets(cbio, inbuf, sizeof inbuf);
+   if (len <= 0)
+   return 1;
+   if (strncmp(inbuf, "GET", 3) == 0)
+   {
+   /* Expecting GET {sp} /URL {sp} HTTP/... */
+   for (p = inbuf + 3; *p == ' ' || *p == '\t'; ++p)
+   continue;
+   p++;
+   q = strchr(p, ' ');
+   if (q == NULL)
+   {
+   BIO_printf(bio_err, "Invalid request\n");
+   return 1;
+   }
+   /* URL decode? Really shouldn't be needed. */
+   if (strchr(p, '+') != NULL && strchr(p, '%') != NULL)
+   p = urldecode(p);
+   getbio = BIO_new_mem_buf(p, strlen(p));
+   b64 = BIO_new(BIO_f_base64());
+   BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL);
+   getbio = BIO_push(b64, getbio);
+   }
+   else if (!strncmp(inbuf, "POST", 4))
+   {
+   BIO_printf(bio_err, "Invalid request\n");
+   return 1;
+   }
for(;;)
{
len = BIO_gets(cbio, inbuf, sizeof inbuf);
if (len <= 0)
return 1;
-   /* Look for "POST" signalling start of query */
-   if (!have_post)
-   {
-   if(strncmp(inbuf, "POST", 4))
-   {
-   BIO_printf(bio_err, "Invalid request\n");
-   return 1;
-   }
-   have_post = 1;
-   }
/* Look for end of headers */
if ((inbuf[0] == '\r') || (inbuf[0] == '\n'))
break;
}
 
/* Try to read OCSP request */
-
-   req = d2i_OCSP_REQUEST_bio(cbio, NULL);
+   if (getbio)
+   {
+   req = d2i_OCSP_REQUEST_bio(getbio, NULL);
+   BIO_free_all(getbio);
+   }
+   else
+   req = d2i_OCSP_REQUEST_bio(cbio, NULL);
 
if (!req)
{

RE: Platform removal

[Salz, Rich]

> I just wanted to double check to make sure that SUNOS is the pre-5.X Solaris
> version and it doesn't include the currently supported Solaris release 
> (Solaris
> 8-11.2).

Yes, old SunOS, not Solaris.

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

RE: [openssl-dev] Adding GET support to ocsp app

[Salz, Rich]

> This code treats non-hex characters as zero, they should trigger an error.

"Be liberal in what you accept" :) If there's a problem with it, the base64 
decode or the DER parse will fail later.  If there's not a problem with it, 
then there.. is no problem.
 
> > +   if (strchr(p, '+') != NULL && strchr(p, '%') != NULL)
> > +   p = urldecode(p);
> 
> That '&&' should be '||'.  Is it OK to modify 'p' (aka inbuf) in place?

Ouch, you're right!  Yes, it's okay to modify it in-place
 
> > +   else if (!strncmp(inbuf, "POST", 4))
> 
> This and "GET" case above it should check for a space following "POST" or
> "GET".

The GET does do the checking because we have to parse the request line.  The 
POST doesn't bother because it's the message body that counts; the ocsp client 
code doesn't care about the request URI or version.  So I think it's okay 
as-is.  In theory someone could say "POSTER" and "fool" the code, but they'd 
only be fooling themselves. This isn't a general web server, it's only an OCSP 
responder, so if you don't send a valid OCSP request, it'll reject it anyway.


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

RE: [openssl-dev] Adding GET support to ocsp app

[Salz, Rich]

> You're doing "HTML-entity" decoding here. URL decoding uses only the
> "%xx" stuff. See RFC3986.
> 
> + else if (*p != '%')
> + *out++ = *p;

Yes, I was treating it as an HTML form, not just a strict URI encoding.

> + /* URL decode? Really shouldn't be needed. */
> + if (strchr(p, '+') != NULL && strchr(p, '%') != NULL)
> + p = urldecode(p);

The comment was misleading and the second test isn't needed (and the && was 
wrong). So:
/* URL decode? Might not be needed, so check first. */
if (strchr(p, '%') != NULL)
p = urldecode(p);
  

Thanks again.

So many bugs in such a small piece of code.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl-dev] Adding GET support to ocsp app

[Salz, Rich]

> The decoder does not correctly NUL terminate "p" when it shrinks by
> replacing '%xx' with the corresponding octet.

Arrgh.  Thanks.

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

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

RE: [openssl.org #3505] rewrite c_rehash in C

[Salz, Rich]

Great work!

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

RE: [openssl.org #3555] OCSP Stapling Enhancement (diff included)

[Salz, Rich]

This is cool, we should do it, but it's probably too late for 1.0.2.
Thanks!

RE: [openssl.org #3556] Problem building openssl 1.0.1i in debug mode

[Salz, Rich]

In crypto/bn/bn_ctx.c, line 161:
fprintf(stderr,"(%08x): ", (unsigned int)ctx);
change it to this
fprintf(stderr,"(%p): ", ctx);

and see if that fixes it.
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #3556] Problem building openssl 1.0.1i in debug mode

[Salz, Rich]

Did you take the (unsigned int) cast off?

Do sed –n –e 160,162p bn_ctx. 
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

We'll be at LinuxConf next week

[Salz, Rich]

Most of the OpenSSL development team will be at LinuxConf in Dusseldorf next 
week. We'll have some kind of BoF or public session. But feel free to also look 
for me (and probably others) directly.

We would like to thank the Linux Foundation for their generous financial 
support that made this historic first meeting possible.

/r$

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

RE: [PATCH] Suppress unused value warnings casue by HOST_cl2

[Salz, Rich]

Is there any time that the value of HOST_cl2 is used?  Could we just add the 
(void) cast to the macro definition?

--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [PATCH] Suppress unused value warnings casue by HOST_cl2

[Salz, Rich]

Let's fix it the right way. :)

--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #3557] -nameopt utf8 behaviour in openssl 1.0.1i

[Salz, Rich]

Look like a bug and a reasonable fix.  Thanks.

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

From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On 
Behalf Of Dmitry Belyavsky
Sent: Saturday, October 11, 2014 12:19 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #3557] -nameopt utf8 behaviour in openssl 1.0.1i

Hello Openssl team,

Any comments?

Thank you!

On Mon, Oct 6, 2014 at 12:07 AM, Dmitry Belyavsky via RT 
mailto:r...@openssl.org>> wrote:
Hello OpenSSL Team,

The x509 and req commands behave strangely when the nameopt utf8 is
specified.

beldmit@manul$ openssl x509 -text -noout -nameopt utf8 -in
./demos/cms/cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 14395258657826892692 (0xc7c63b7adda36b94)
Signature Algorithm: md5WithRSAEncryption
Issuer:

The output becomes correct when we specify -nameopt sep_comma_plus,utf8

The patch by Victor Wagner fixing this behaviour is attached.

Thank you!

--
SY, Dmitry Belyavsky

--- ../openssl-1.0.1i/crypto/asn1/a_strex.c 2014-07-22 23:41:23.0 
+0400
+++ crypto/asn1/a_strex.c   2014-10-05 19:45:32.790011154 +0400
@@ -414,6 +414,7 @@
sep_mv_len = 3;
break;

+   case 0:
case XN_FLAG_SEP_COMMA_PLUS:
sep_dn = ",";
sep_dn_len = 1;



--
SY, Dmitry Belyavsky

RE: Vuln in SSL 3.0

[Salz, Rich]

>I suppose it fixes both - client and server ?

The server-side is automatic: when it sees the SCSV fallback, it sends a fatal 
alert back to the client.

Clients that will do fallback must call a new API; see the changes file.

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


:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: Patch to mitigate CVE-2014-3566 ("POODLE")

[Salz, Rich]

> Note that the CVE identifier was assigned to the SSL 3.0 protocol issue
> related to CBC padding.  The new SCSV does not help with that at all.

What?  It prevents silently falling back to the broken protocol.

Perhaps we can keep this battle-thread just in the TLS WG mail?

/r$

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

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

RE: Patch to mitigate CVE-2014-3566 ("POODLE")

[Salz, Rich]

> Again, this is not related to the question whether the fallback SCSV is a good
> idea.  It is a procedural issue with CVE naming.

Then take it up with the CVE folks.  Not here. :)
 
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

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

RE: SSL_CTX_set_mode docs wrong for TLS_FALLBACK_SCSV

[Salz, Rich]

Yes, thanks.  We'll open a ticket in a day or two

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


> -Original Message-
> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org] On Behalf Of Brad House
> Sent: Thursday, October 16, 2014 3:20 PM
> To: openssl-dev@openssl.org
> Subject: SSL_CTX_set_mode docs wrong for TLS_FALLBACK_SCSV
> 
> 
> FYI:
> 
> https://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html
> That page documents SSL_MODE_FALLBACK_SCSV when the proper flag is
> SSL_MODE_SEND_FALLBACK_SCSV, at least in 1.0.1j.
> 
> -Brad
> __
> 
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org

RE: In the scope of a sub-subversion maintenance bump...

[Salz, Rich]

> [I'm all for mandating C99 - but not for switching prereqs of a 
> legacy/maintenance branch]

That was not our intent -- to do the switch -- and it's a bug we're working on. 
 Thanks for the report.
/r$
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

RE: RFC's 5280 and 5262

[Salz, Rich]

> I'm working on Network Time Security and the draft specification requires
> RFC-5280 and -5652 formatting (i.e. pkcs#9 and pkcs#7).

You're a bit confused. 5280 is the cert/crl profile.  Pkcs9, evolved into RFC 
2985 I think.

> How complete is OpenSSL's support for both of these standards?

Better than some, worse than others.  Nobody implements everything in those 
PKCS specifications (except maybe Peter Gutman).

> And if it's not complete, what's missing (i.e. how much effort would be
> needed to round it out)?

Without knowing anything about the NTP specifications, my educated guess is 
that OpenSSL has almost everything you need to implement them. For IETF 
protocols, it generally does.

/r$

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

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

RE: [PATCH] Suppress unused value warnings casue by HOST_cl2

[Salz, Rich]

It will go into master, post-1.0.2

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


> -Original Message-
> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
> d...@openssl.org] On Behalf Of Doug Kwan (???)
> Sent: Monday, October 20, 2014 8:50 PM
> To: openssl-dev@openssl.org
> Subject: Re: [PATCH] Suppress unused value warnings casue by HOST_cl2
> 
> ping?
> 
> On Mon, Oct 13, 2014 at 3:57 PM, Doug Kwan (關振德)
>  wrote:
> > On Fri, Oct 10, 2014 at 2:39 PM, Salz, Rich  wrote:
> >> Let's fix it the right way. :)
> >>
> >> --
> >> Principal Security Engineer, Akamai Technologies
> >> IM: rs...@jabber.me Twitter: RichSalz
> >
> > I changed the definitions of HOST_c2l on different platforms and
> > removed the unneeded void casts.  This is tested on Linux running on
> > x86_64, powerpc64le and aarch64.
> >
> > -Doug
> __
> 
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x

[Salz, Rich]

AES 128 is worth supporting.
I agree that AES 192 is not.

RE: [openssl.org #3576] [PATCH] Speed up AES-256 key expansion by 1.9x

[Salz, Rich]

> > AES 128 is worth supporting.
> 
> Not for me; doing this strictly for fun.

Sure, I understand that.

We're unlikely to incorporate the patch without "finishing" it and doing AES 
128.  Nobody said it had to be you :)

It will take awhile anyway, and it won't show up in 1.0.2

RE: [openssl.org #3576] [PATCH] Speed up AES-256 key expansion by 1.9x

[Salz, Rich]

> You might want to toggle off base64 encoding on your emails. Some mail
> clients choke on it as do list aggregators (e.g.
> http://marc.info/?l=openssl-dev&m=141387182603109&w=2).

The problem is that openssl is running really old mailing list software. It is 
going to be upgraded soon.  It's embarrassing.

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

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

RE: Proposal: environment variable to disable SSLv2/v3/TLSv1.0/etc individually

[Salz, Rich]

It's an interesting idea.  I'll chat with the Moz folks.  Best we could do is 
probably early patch to 1.0.2


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

RE: [openssl.org #3581] POODLE - Is there a way for a central ciphers configuration

[Salz, Rich]

> Is there a way to disable SSLv3 for ALL applications by a central OpenSSL
> configuration ?

No.

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