Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Steffen Nurpmeso]

Viktor Dukhovni  wrote:
 |> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
 |>> email clients are designed to handle hundreds to thousands of messages
 |>> a day, Github UI isn't
 |
 |Indeed email is best for informal ad-hoc back and forth threaded
 |discussion, while Github et. al. are for issue tracking.
 |
 |If there's a clear problem that requires tracking and resolution,
 |then the right forum is Github.  If there's a topic to discuss,
 |we have openssl-users.  Most openssl-dev threads were more
 |appropriate for openssl-users.

I see an overwhelming amount of posts on the new list which where
somehow missed on -dev, though.

As a general note that you might not know, from Germany at least
and over my internet account and being not a logged in user i find
that github very often fails to generate commit data or cuts
directory listings.  At least there are no advertisings which
consume multiple CPUs for who-knows-what.

 |So I'm not convinced we need two free-form discussion lists, but
 |concur that if it is discussion one wants, then email clearly
 |superior to Github issue tracking.  The key question is whether
 |openssl-users suffices to meet that need.

Oh, -dev was a terribly noisy list.  So: ch-ch-ch-ch-changes
(turn and face the strange).

Congratulations for the price you have won.  Especially so in
respect to, brave new world!, having to go over browser based
issue tracker interfaces.  I could not do that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Systemwide configurability of OpenSSL

[Steffen Nurpmeso]

Hello.

Tomas Mraz  wrote:
 |I would like to restart the discussion about possibilities of system-
 |wide configurability of OpenSSL and particularly libssl.
 |
 |Historically OpenSSL allowed only for configuration of the enabled
 |ciphersuites list if application called appropriate API call. This is
 |now enhanced with the SSL_CONF API and the applications can set thing
 |such as allowed signature algorithms or protocol versions via this API.

Now is the time to thank the OpenSSL for this improvement which
will change the world mid- or long term: thank you!

In my opinion it is a tremendous improvement that it is now
possible to configure OpenSSL via a central (or not) configuration
file if applications adhere to the rules!  Oh what a brilliant
brain must have hatched this idea.  (Just kidding.)
The MUA i maintain for example supports this since v14.9.4
released nine days ago, documented as

  ssl-config-module-USER@HOST, ssl-config-module-HOST, ssl-config-module
   [Option] If file based application-specific configuration
   via ssl-config-file is available, announced as ‘+ctx-config’
   by ssl-features, indicating availability of
   SSL_CTX_config(3), then, it becomes possible to use a
   central SSL/TLS configuration file for all programs,
   including steffensmua, e.g.:

 # Register a configuration section for steffensmua
 steffensmua = mailx_master
 # The top configuration section creates a relation
 # in between dynamic SSL configuration and an actual
 # program specific configuration section
 [mailx_master]
 ssl_conf = mailx_ssl_config
 # Well that actual program specific configuration section
 # now can map individual ssl-config-module names to sections,
 # e.g., ssl-config-module=account_xy
 [mailx_ssl_config]
 account_xy = mailx_account_xy
 account_yz = mailx_account_yz
 [mailx_account_xy]
 MinProtocol = TLSv1.2
 Curves=P-521
 [mailx_account_yz]
 CipherString = TLSv1.2:!aNULL:!eNULL:
 MinProtocol = TLSv1.1
 Options = Bugs

So obviously it took me a while to figure out how this works, the
documentation clearly has been written in a hurry by someone who
entirely penetrates OpenSSL intellectually, to say the least.
Nothing for the highly sensitive ones.  My implementation is
super simple, then:

if((cp = xok_vlook(ssl_config_module, urlp, OXM_ALL)) != NULL){
  # ifdef HAVE_XSSL_CTX_CONFIG
if(!(a_xssl_state & a_XSSL_S_CONF_LOAD)){
   n_err(_("*ssl-config-module*: no *ssl-config-file* "
  "loaded: %s\n"), n_shexp_quote_cp(cp, FAL0));
   goto jleave;
}else if(!SSL_CTX_config(ctxp, cp)){
   ssl_gen_err(_("*ssl-config-module*: load error for %s, "
  "section [%s]"), n_uagent, n_shexp_quote_cp(cp, FAL0));
   goto jleave;
}
  # else
n_err(_("*ssl-config-module*: set but not supported: %s\n"),
   n_shexp_quote_cp(cp, FAL0));
goto jleave;
  # endif
 }

 |However libssl currently does not have a way to apply some policy such
 |as using just protocol TLS1.2 or better system-wide with a possibility
 |for sysadmin to configure this via some configuration file. Of course
 |it would still be up to individual application configurations whether
 |they override such policy or not, but it would be useful for sysadmin
 |to be able to set such policy and depend on that setting if he does not
 |modify the settings in individual application configurations.
 |
 |How would openssl maintainers regard a patch that would add loading of
 |a system-wide SSL configuration file on startup and application of it

Having a global one and especially giving administrators the
possibility to provide an outer cramp that cannot be loosened any
further, though further restricted, would indeed be good.
And that being applied automatically just when SSL library is
initialized, without an explicit application-side
CONF_modules_load_file().  If i recall correctly that was the
original suggestion.

And is it actually possible to have a generic "super-section" that
is applied even if an application specific one has been chosen?
And unfortunately it is not possible to say MinProtocol=Latest,
like this users have to be aware, even if they are not.  With
MinProtocol=Latest they would only have to face this jungle of
non-understanding (be honest: Google/DuckDuckGo plus
copy-and-paste, isn't it) if something really fails.

 |on SSL_CTX initialization (or some other appropriate place)? Is this
 |approach the way to go forward or do you have some better way on mind?
 |
 |Such an effort was initially attempted at:
 |https://github.com/openssl/openssl/pull/192 and
 |https://github.com/openssl/openssl/pull/193 pull requests but given the
 |comments, we are exploring other options to achieve that goal. What do
 |you think could be a better way?
 |
 |Thanks for your 

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Steffen Nurpmeso]

"Blumenthal, Uri - 0553 - MITLL"  wrote:
 |>So I guess you want an interface that can both add things to the
 |>   "entropy" pool, and to the "additional data" pool? It shouldn't
 |>be that hard, I'll try to come up with some proposal soon.
 |  
 |I’d say the interface that  Rich Salz proposed would be good enough:
 |
 |> …  But I think a new API, RAND_add_ex() that took a flag that had \
 |> values like
 |> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
 |> RAND_LOCAL_PRIVATE indicating which to seed. Thoughts?
 |
 |It exposes what’s necessary, but nothing more. Another benefit – malicious \
 |input would not compromise the entropy pool.
 |
 |> We should think carefully about what API’s we are exposing, and might \
 |> want to wait for 1.1.2
 |
 |Nothing wrong with thinking about what API to expose, and how. Since \
 |1.1.1 is what’s currently being shaped – there’s no reason to postpone \
 |that thinking. Especially since the RNG/DRBG work is being done on \
 |1.1.1 now, and this is a part of it.

If you say it and continue like that then let me wonder why the
objects as such cannot be accessed like
RAND_object_get(SPECIAL_CONSTANT_OR_NULL), or
RAND_object_create(SPECIAL_CONSTANT_OR_NULL), plus
RAND_object_bytes() and RAND_object_add().  And all the current
could be macros or inline functions to the corresponding new
object based functions.
But i am not writing a multithreaded server with the need for
performance comparisons, RAND_bytes() is good enough for us.
(And since OpenSSL is optional we still have to do some searching
around to find a PRNG anyway, with a builtin arc4 fallback.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Steffen Nurpmeso]

"Salz, Rich"  wrote:
 |Is this new RNG object available to user programs, or do they need
 |to reinvent the wheel even though they definitely link against the
 |OpenSSL library?
 |
 |You don’t have to re-invent the wheel, but you might have to modify \
 |the source ☺  Did you read the blog posting?  What wasn’t clear?

Ok.
Yes, and the linked thread on the crypto ML.
Nothing, sir.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Steffen Nurpmeso]

"Salz, Rich via openssl-dev"  wrote:
 |➢ But I’d like the development team to comment on (and ideally – accept) \
 |my request to add RAND_add() method to the RNG that is used in generation \
 |of private keys.
 |
 |Well, I’ve been thinking about this for a bit, since you first raised \
 |it.  I am still not sure of the need.  And as the blog post says, we’re \
 |not convinced that the current DRBG arrangement is something that will \
 |never change.  But I think a new API, RAND_add_ex that took a flag \
 |that had values like RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, \
 |RAND_LOCAL_PRIVATE indicating which to seed. Thoughts?

Is this new RNG object available to user programs, or do they need
to reinvent the wheel even though they definitely link against the
OpenSSL library?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

Hello.

Richard Levitte  wrote:
 |I've added a change with documentation:
 |
 |https://github.com/openssl/openssl/pull/2818
 |
 |Please go in and comment, or if you don't have a github account, feel
 |free to comment here.

Thank you, i have added it to my makefile 1:1.
Ciao!

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

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

Hello.

Richard Levitte <levi...@openssl.org> wrote:
 |In message <20170301221703.tfwpu%stef...@sdaoden.eu> on Wed, 01 Mar \
 |2017 23:17:03 +0100, Steffen Nurpmeso <stef...@sdaoden.eu> said:
 |
 |steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere
 |steffen> (i think that would well be worth in entry in INSTALL), and
 |steffen> i really would have sworn that it worked in the past.
 |
 |I was actually surprised to find this undocumented.  I could have
 |sworn I'd done so, but apparently, I only did in a commit message:
 |
 |commit fad599f7f147ee71e5581211fb654c2c8c491cd8
 |Author: Richard Levitte <levi...@openssl.org>
 |Date:   Wed Oct 12 17:05:35 2016 +0200
 |
 |Remove automatic RPATH - add user rpath support
 |
 |Make Configure recognise -rpath and -R to support user added rpaths
 |for OSF1 and Solaris.  For convenience, add a variable LIBRPATH \
 |in the
 |Unix Makefile, which the users can use as follows:
 |
 |./config [options] -Wl,-rpath,\$(LIBRPATH)
 |
 |Reviewed-by: Rich Salz <rs...@openssl.org>
 |
 |I'll go add a note now...

Thank you very much.
Have a good time.

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

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

Hello,

Richard Levitte <levi...@openssl.org> wrote:
 |In message <20170301165032.8jhwg%stef...@sdaoden.eu> on Wed, 01 Mar \
 |2017 17:50:32 +0100, Steffen Nurpmeso <stef...@sdaoden.eu> said:
 |
 |steffen> "Salz, Rich" <rs...@akamai.com> wrote:
 |steffen>  |> This is new behaviour, until now the installation was \
 |always self-contain\
 |steffen>  |> ed
 |steffen>  |> when configured via
 |steffen>  |> 
 |steffen>  |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |steffen>  |
 |steffen>  |Did you install the libraries in a standard place?
 |steffen>  |
 |steffen>  |> I think this should at least be noted in CHANGES or so.
 |steffen>  |
 |steffen>  |I don't think so.  I think the libs weren't installed.
 |steffen> 
 |steffen> Yes, also in my opinion the old behaviour was much, much better.
 |
 |I very much disagree.  We have had bug reports as well as cases of our
 |own because a new compilation that you want to test picked up
 |previously installed versions of the libraries (usually an older
 |version).  The reason for doing so previously was because we installed
 |the libraries in non-standard locations by default.

That unpuzzles me a little bit -- this behaviour did exist.  Good.

 |Since OpenSSL 1.1.0 and on is installing in standard locations by
 |default, we don't have to use these mechanisms for a default build.
 |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they
 |are different) or whatever isn't really our decision to make, but the
 |decision of the packager or the individual user, so we've handed the
 |decision to you. 
 |
 |For the GNU toolchain, I'd recommend configuring with something like
 |this (from memory, I might be fuzzy in the details):
 |
 |-Wl,--enable-new-dtags -rpath '$(LIBRPATH)'
 |
 |LIBRPATH is a convenience Makefile variable that gets correctly set to
 |the configured shared library installation directory, meant for
 |exactly this sort of situation.

The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes,
when i reported the dynamic link test failures a while back i have
seen that and also added support for this new linker flag to my
software.  It is i think off-topic that now new environment
variables come up that makes me wonder why the LD_PRELOAD ..
DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared
deprecated.

LIBRPATH i did not know about yet, thanks for the pointer, i will
read about it.
Yes, i mean, i just didn't know this, it is not mentioned anywhere
(i think that would well be worth in entry in INSTALL), and
i really would have sworn that it worked in the past.

Thank you, and
Ciao!

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

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

[Steffen Nurpmeso]

Hello again,

Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
 |> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
 |> No, not that i know.  But this -- thanks -- lead me to the
 |> following, which is the KISS that you want?
 ...
 |> diff --git a/apps/apps.c b/apps/apps.c
 |> index 216bc797d..3afbbaef2 100644
 |> --- a/apps/apps.c
 |> +++ b/apps/apps.c
 |> @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, \
 |> const char *CApath, int noCAfile, i
 |> if (lookup == NULL)
 |> goto end;
 |> if (CApath) {
 |> -if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM))\
 |>  {
 |> +if (!app_isdir(CApath) ||
 |> +!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_P\
 |> EM)) {
 |> BIO_printf(bio_err, "Error loading directory %s\n", \
 |> CApath);
 |> goto end;
 |>}
 |
 |We may need to be careful.  With OpenSSL <= 1.0.2, one way to suppress the
 |built-in default CApath was to set "-CApath" to a non-existent directory.
 |Users may have scripts relying on this behaviour.  Now with 1.1.0 on some
 |platforms OpenSSL already rejects non-existent directories, and we also
 |provide a "-no-CAfile" option, but this change will extend the change to
 |what is likely our most popular platform.
 |
 |So it will at least deserve a comment in the "NEWS"/"CHANGES" files.  

I understand that this is a "lingering" configuration, which is
inspected on the fly as a last (or second last, if there is
SSL_CTX_set_default_verify_paths(3).  In fact i don't know, the
documentation is horrific!  E.g., just today i have implemented
some *{smime,ssl}-ca-flags*, mostly to be able to provide
X509_V_FLAG_PARTIAL_CHAIN, but you know you can't find just any
X509_STORE_set_flags(_not_ 3) at all, it is, again, _horrific_.
I for one, as someone unrelated, now that you have so many
sponsors, i really wonder why you don't spend a little bit of
money to some crypto nerd student(s) who really need(s) it in
order to improve it.  Really, and honestly.) resort.

But for an application that does a one-shot check i would at least
expect a message that leads into the right direction, at least
with -verbose.  I for one _of course_ looked for
X509_LOOKUP_add_dir() first, but i gave up after the second
indirection.  If you would ask me, i surely would add
a X509_FILETYPE_CHECK_OR_ERROR or similar flag to get the
synchronous checks.  But who am i.

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

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

Good evening.

Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
 |> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
 |> 
 |>  $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl
 |>  ...
 |>  libssl.so.1.1 => not found
 |>  libcrypto.so.1.1 => not found
 |> 
 |> This is new behaviour, until now the installation was always
 |> self-contained when configured via
 |> 
 |>  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |
 |I sure hope that "$()" was in fact "${}", the former only
 |works in Makefiles, and means something quite different
 |in POSIX shells.

No it is a snippet from a makefile, of course.

 |You need an "RPATH" setting in the linker flags for the shared
 |libraries to be found in in $PREFIX/lib.  Perhaps:

If my tortured ears finally hear, then.  You are saying this never
was standard behaviour?  Oh!?!  Well, then i am sorry, it could
indeed be that i never ran the binaries in there, but only use
this one for v1.1.0 link testing, and then, there, the linker path
is adjusted automatically (by my configuration script).

It may be a crappy comment, but if i ldd(1)
~/usr/opt/.ressl/bin/openssl then this just works, and the make
rule is almost identical:

  libressl:
  cd libressl.tar_bomb_git &&\
  if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
  ./configure --prefix=$(MYPREFIX) &&\
  make &&\
  make check &&\
  $(SUDO) make install;\
  { git clean -fxd; git reset --hard HEAD;\
  git checkout arena-manager-null; } >/dev/null

But thanks, i did not know that i can pass additional flags to
./config!  Thanks to Matt Caswell i think, if i recall correctly,
i now know about "make install_sw && make install_ssldirs", and
maybe in a not too distant future i get it right!

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

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

"Salz, Rich"  wrote:
 |> This is new behaviour, until now the installation was always self-contain\
 |> ed
 |> when configured via
 |> 
 |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |
 |Did you install the libraries in a standard place?
 |
 |> I think this should at least be noted in CHANGES or so.
 |
 |I don't think so.  I think the libs weren't installed.

Yes, also in my opinion the old behaviour was much, much better.

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

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

[Steffen Nurpmeso]

Sorry for the late reply, this really is a slow machine (and
i cleanup again completely anything once it is installed, _and_
the tests compile a long time even if not run)..

"Salz, Rich"  wrote:
 |> I am sorry, but i have no github account.  Maybe it is possible to \
 |> have some
 |> @bug address which creates issues automatically?
 |
 |Nah, too much spam will happen :(  Posting to openssl-dev is fine.

Ok, good.

 |>   ? openssl version
 |>   OpenSSL 1.0.2k  26 Jan 2017
 |>   ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version
 |>   OpenSSL 1.1.0  25 Aug 2016
 |
 |So this happens on both 1.0.2 and 1.1.0?
 |
 |Does the following patch fix it for 1.1.0?

No, not that i know.  But this -- thanks -- lead me to the
following, which is the KISS that you want?
Ciao!

diff --git a/apps/apps.c b/apps/apps.c
index 216bc797d..3afbbaef2 100644
--- a/apps/apps.c
+++ b/apps/apps.c
@@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char 
*CApath, int noCAfile, i
 if (lookup == NULL)
 goto end;
 if (CApath) {
-if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) {
+if (!app_isdir(CApath) ||
+!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) {
 BIO_printf(bio_err, "Error loading directory %s\n", CApath);
 goto end;
 }

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

[openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

[Steffen Nurpmeso]

Oh, hello again,

now i finally have updated (without "make tests?") and it seems
i now have to fill in $LD_LIBRARY_PATH to get running:

  $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl
  ...
  libssl.so.1.1 => not found
  libcrypto.so.1.1 => not found

This is new behaviour, until now the installation was always
self-contained when configured via

  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared

I think this should at least be noted in CHANGES or so.
Ciao,

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

[openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

[Steffen Nurpmeso]

Hello.

I am sorry, but i have no github account.  Maybe it is possible to
have some @bug address which creates issues automatically?
I see this on 

  ? openssl version
  OpenSSL 1.0.2k  26 Jan 2017
  ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version
   
  OpenSSL 1.1.0  25 Aug 2016
  ? openssl verify -verbose -CAfile SOME-FILE  SOME-CERT
  SOME-FILE: OK
  ? openssl verify -verbose -CApath SOME-FILE  SOME-CERT
  error 20 at 0 depth lookup:unable to get local issuer certificate

I look into apps/apps.c, but i cannot tell why this does not bail
out when the directory is found to be a file.
Ciao,

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

Re: [openssl-dev] OpenSSL version 1.1.0e published

[Steffen Nurpmeso]

FYI,

and because i don't have a github account, though this could be
related to ticket #1635, on a x86_64 GNU LibC based Linux via

  openssl:
  cd openssl.git &&\
  if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared &&\
  make &&\
  $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
  { git clean -fxd; git reset --hard HEAD;\
  git checkout arena-manager-null; } >/dev/null

and MYPREFIX=$HOME/usr/opt/.ssl-1.1.0 the shlibload tests fail

  ../test/recipes/90-test_shlibload.t  1/3
  #   Failed test 'running shlibloadtest -crypto_first'
  #   at ../test/recipes/90-test_shlibload.t line 30.
  ../test/recipes/90-test_shlibload.t  2/3
  #   Failed test 'running shlibloadtest -ssl_first'
  #   at ../test/recipes/90-test_shlibload.t line 32.

  #   Failed test 'running shlibloadtest -just_crypto'
  #   at ../test/recipes/90-test_shlibload.t line 34.
  # Looks like you failed 3 tests of 3.
  ../test/recipes/90-test_shlibload.t  Dubious, test returned 3 (wstat 
768, 0x300)
  Failed 3/3 subtests
  ../test/recipes/90-test_srp.t .. ok
  ../test/recipes/90-test_sslapi.t ... ok
  ../test/recipes/90-test_threads.t .. ok
  ../test/recipes/90-test_v3name.t ... ok

  Test Summary Report
  ---
  ../test/recipes/90-test_shlibload.t  (Wstat: 768 Tests: 3 Failed: 3)
Failed tests:  1-3
Non-zero exit status: 3
...
  Failed 1/91 test programs. 3/489 subtests failed.

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

Re: [openssl-dev] [openssl.org beetle 4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso]

"Salz, Rich"  wrote:
 |> Maybe you like it.  I haven't tried it, but see no reason why it
 |> shouldn't work.  It also adjusts headline tags in secpolicy.html, \
 |> which don't
 |> comply to the rest of the site yet.
 |
 |It's good enough.  None of us our web developers.  I just pushed the \
 |updated repo to https://github.com/openssl/web

A 42 KB patch, and you and i both have seen it.

 |If you have improvements, plelase make a PR :o)

I think less professionalism is better much often than not.  (Just
take these assembly lines of death for supermarket etc. meat.)
As a natural born german i hate missing end tags etc. nonetheless.
That must be said.  Then again, browsers are used to swallow ...
Ciao.

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

Re: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso]

Rich Salz via RT  wrote:
 |The title now has the URL. Closing. Fixed as it's gonna get :)

Not on Github, but i have really cloned the repository from
openssl.org (not promoted, but present) and had a short run on top
what you have committed.  Maybe you like it.  I haven't tried it,
but see no reason why it shouldn't work.  It also adjusts
headline tags in secpolicy.html, which don't comply to the rest of
the site yet.

Have a nice weekend, and ciao!

--steffen
diff --git a/bin/mk-manpages b/bin/mk-manpages
index 3884a6a..ac39cae 100755
--- a/bin/mk-manpages
+++ b/bin/mk-manpages
@@ -224,6 +224,7 @@ sub process_options {
 sub htmlHeader {
 my ( $class, $title ) = @_;
 return <

Re: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files

[Steffen Nurpmeso via RT]

Richard Levitte via RT  wrote:
 |On Thu Sep 01 13:18:44 2016, stef...@sdaoden.eu wrote:
 |> From the documentation i cannot tell what is wrong with the
 |> following:
 |>
 |> echo abc > a; echo def > b; echo ghi > c
 |> openssl genpkey -algorithm RSA -out k.prv
 |> openssl pkey -in k.prv -pubout -out k.pub
 |> openssl dgst -sha512 -sign k.prv -out .sig a b c
 |> openssl dgst -sha512 -verify k.pub -signature .sig a b c
 |> rm k.prv k.pub a b c
 |
 |The manual for dgst has this little note
 |
 |The signing and verify options should only be used if a single file \
 |is being
 |signed or verified.
 |In other words, don't do that.

I really haven't seen that.  It is the second last sentence.  Hm.

 |While I can understand the desire to do multiple files in one swoop, the
 |signature file (.sig in this case) isn't formatted in any special way, it's
 |litterally just a stream of bytes. So it does contain all the signatures, \
 |but
 |in an unstructured format. Verification will read that file and use \
 |the first n
 |bytes from it when verifying each file you give it. That's why you \
 |get correct
 |verification on the first file but not the others.
 |
 |The solution to this is to enhance dgst so it loudly refuses to sign \
 |or verify
 |more than one file.

If that is your way.  I haven't actually tried it, but the
following should do what you want?!
Ciao,

--- dgst.c.orig 2016-09-02 15:06:08.952110179 +0200
+++ dgst.c  2016-09-02 15:13:57.592904667 +0200
@@ -369,6 +369,14 @@ int dgst_main(int argc, char **argv)
 if (md)
 md_name = EVP_MD_name(md);
 }
+
+if (argc > 1 && (sigbuf != NULL || sigkey != NULL)){
+BIO_printf(bio_err, "Signing and verifying cannot be used with 
"
+   "multiple files\n");
+ret = 1;
+goto end;
+}
+
 ret = 0;
 for (i = 0; i < argc; i++) {
 int r;

--steffen


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

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

Re: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files

[Steffen Nurpmeso]

Richard Levitte via RT  wrote:
 |On Thu Sep 01 13:18:44 2016, stef...@sdaoden.eu wrote:
 |> From the documentation i cannot tell what is wrong with the
 |> following:
 |>
 |> echo abc > a; echo def > b; echo ghi > c
 |> openssl genpkey -algorithm RSA -out k.prv
 |> openssl pkey -in k.prv -pubout -out k.pub
 |> openssl dgst -sha512 -sign k.prv -out .sig a b c
 |> openssl dgst -sha512 -verify k.pub -signature .sig a b c
 |> rm k.prv k.pub a b c
 |
 |The manual for dgst has this little note
 |
 |The signing and verify options should only be used if a single file \
 |is being
 |signed or verified.
 |In other words, don't do that.

I really haven't seen that.  It is the second last sentence.  Hm.

 |While I can understand the desire to do multiple files in one swoop, the
 |signature file (.sig in this case) isn't formatted in any special way, it's
 |litterally just a stream of bytes. So it does contain all the signatures, \
 |but
 |in an unstructured format. Verification will read that file and use \
 |the first n
 |bytes from it when verifying each file you give it. That's why you \
 |get correct
 |verification on the first file but not the others.
 |
 |The solution to this is to enhance dgst so it loudly refuses to sign \
 |or verify
 |more than one file.

If that is your way.  I haven't actually tried it, but the
following should do what you want?!
Ciao,

--- dgst.c.orig 2016-09-02 15:06:08.952110179 +0200
+++ dgst.c  2016-09-02 15:13:57.592904667 +0200
@@ -369,6 +369,14 @@ int dgst_main(int argc, char **argv)
 if (md)
 md_name = EVP_MD_name(md);
 }
+
+if (argc > 1 && (sigbuf != NULL || sigkey != NULL)){
+BIO_printf(bio_err, "Signing and verifying cannot be used with 
"
+   "multiple files\n");
+ret = 1;
+goto end;
+}
+
 ret = 0;
 for (i = 0; i < argc; i++) {
 int r;

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

Re: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso via RT]

Richard Levitte via RT  wrote:
 |On Thu Sep 01 13:13:44 2016, stef...@sdaoden.eu wrote:
 |> Before sending the last message i looked around on the website (it
 |> has become particularly complicated to find the bug tracker), and
 |> looking at the "go-back" list i saw dozens of "OpenSSL" entries,
 |> rather than rt, "Getting started as a contributor", etc.
 |
 |Not sure what you're on about... I just had a look through the whole set of
 |files, and there's only one page that has that string. This one:
 |https://www.openssl.org/community/getting-started.html
 |
 |As for page titles, all our pages have the title 'OpenSSL'

My name is Hare and i know nothing.
I don't have a Github account (they don't accept hard cash), but
i have found a repository there which seems to be this web page.
The makefile etc. seem to follow security-by-obscurity, but it
seems that you use SSI to generate some load.
If that is really true, the pages could very well be changed to
have a

  

that is repeated in the  further down via

  

I must admit that i don't know whether that is working, the last
time i have used SSI was, i think, and if i recall correctly, with
the Xitami webserver, and before 1999?  Can this be correct?  I am
not lying this, anyway.

 |To sum it up, I don't think we have a problem here. Closing this ticket.

I could place this on my (pretty long) TODO and adjust the web
pages as above at some later time.  Because i think you are
mistaken: to me it seems to be bad style and impolite; the latter
not so much because of the filenames, but these you don't see in
the browser navigation buttons of my graphical browser, only in
the history.
Just my one penny.  Ciao.

--steffen


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

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

Re: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso]

Richard Levitte via RT  wrote:
 |On Thu Sep 01 13:13:44 2016, stef...@sdaoden.eu wrote:
 |> Before sending the last message i looked around on the website (it
 |> has become particularly complicated to find the bug tracker), and
 |> looking at the "go-back" list i saw dozens of "OpenSSL" entries,
 |> rather than rt, "Getting started as a contributor", etc.
 |
 |Not sure what you're on about... I just had a look through the whole set of
 |files, and there's only one page that has that string. This one:
 |https://www.openssl.org/community/getting-started.html
 |
 |As for page titles, all our pages have the title 'OpenSSL'

My name is Hare and i know nothing.
I don't have a Github account (they don't accept hard cash), but
i have found a repository there which seems to be this web page.
The makefile etc. seem to follow security-by-obscurity, but it
seems that you use SSI to generate some load.
If that is really true, the pages could very well be changed to
have a

  

that is repeated in the  further down via

  

I must admit that i don't know whether that is working, the last
time i have used SSI was, i think, and if i recall correctly, with
the Xitami webserver, and before 1999?  Can this be correct?  I am
not lying this, anyway.

 |To sum it up, I don't think we have a problem here. Closing this ticket.

I could place this on my (pretty long) TODO and adjust the web
pages as above at some later time.  Because i think you are
mistaken: to me it seems to be bad style and impolite; the latter
not so much because of the filenames, but these you don't see in
the browser navigation buttons of my graphical browser, only in
the history.
Just my one penny.  Ciao.

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

Re: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso via RT]

"Salz, Rich"  wrote:
  ..
 |for and fix?  (I'm kinda slow sometimes)

Do you know the story of the couple that had been married for
decades when suddenly, at a Sunday morning breakfast, it has been
revealed that she, who was given the upper half of the bread rolls
for so long -- because he thought that was what she likes --,
would much rather have eaten the lower half, but didn't say
a word, because she thought it would have hurt him if she would
have done so?

This story is one of my childhood Traumatas, by the way. ^_^

--steffen


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

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

[openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files

[Steffen Nurpmeso via RT]

Hello.

>From the documentation i cannot tell what is wrong with the
following:

  echo abc > a; echo def > b; echo ghi > c
  openssl genpkey -algorithm RSA -out k.prv
  openssl pkey -in k.prv -pubout -out k.pub
  openssl dgst -sha512 -sign k.prv -out .sig a b c
  openssl dgst -sha512 -verify k.pub -signature .sig a b c
  rm k.prv k.pub a b c

It gives me

  ?0[steffen@wales bin]$ sh /tmp/t.sh
  ..++
  ...++
  Verified OK
  Verification Failure
  Verification Failure

And being able to produce textual output would be great.
Thanks.

--steffen


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

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

[openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso via RT]

Before sending the last message i looked around on the website (it
has become particularly complicated to find the bug tracker), and
looking at the "go-back" list i saw dozens of "OpenSSL" entries,
rather than rt, "Getting started as a contributor", etc.

--steffen


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

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

Re: [openssl-dev] OpenSSL version 1.1.0 published

[Steffen Nurpmeso]

Matt Caswell <m...@openssl.org> wrote:
 |> Matt Caswell <m...@openssl.org> wrote:
 |>|On 25/08/16 22:14, Steffen Nurpmeso wrote:
 |>|> OpenSSL <open...@openssl.org> wrote:
 |>|>|   OpenSSL version 1.1.0 released
 |>|> 
 |>|> A bit distressing that it is me again, as if i would have
 |>|> something to do with that..., but: the tag is missing.
 |>|
 |>|Really? I seem to be able to see it in both the primary openssl repo and
 |>|the github repo.

 |>   ?0[steffen@wales code.arena]$ cd openssl.git/
 |>   ?0[steffen@wales openssl.git]$ git describe master
 |>   OpenSSL_1_1_0-pre6-297-gbbf73f8
 |> 
 |> No, no, not that i know.

 |I'm not sure what you're trying to show me there. What does this give you:
 |
 |git ls-remote --tags origin | grep OpenSSL_1_1_0

Yes, thank you.  You have created a new branch for this tag,
i didn't think about that first, because all the pre- were on
plain [master].  Now have it.
Ciao.

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

Re: [openssl-dev] OpenSSL version 1.1.0 published

[Steffen Nurpmeso]

 |N'morning UK. (^.^)

Ok i'm awake, you've created a new branch for that.
Thanks.

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

Re: [openssl-dev] OpenSSL version 1.1.0 published

[Steffen Nurpmeso]

N'morning UK. (^.^)

Matt Caswell <m...@openssl.org> wrote:
 |On 25/08/16 22:14, Steffen Nurpmeso wrote:
 |> OpenSSL <open...@openssl.org> wrote:
 |>|   OpenSSL version 1.1.0 released
 |> 
 |> A bit distressing that it is me again, as if i would have
 |> something to do with that..., but: the tag is missing.
 |
 |Really? I seem to be able to see it in both the primary openssl repo and
 |the github repo.

Hmmm.

  ?130[steffen@wales code.arena]$ ./.arena-manager.sh autoup openssl.git/
  /home/steffen/usr/bin/arena-manager: script startup, mode autoup
  Checking how likely it is an update would succeed
openssl.git: looks good

  
  openssl.git: performing autoup: update
  Looking up git.openssl.org ... done.
  Connecting to git.openssl.org (port 9418) ... 194.97.150.234 done.
  remote: warning: unable to access '/root/.config/git/attributes': Permission 
denied
  From git://git.openssl.org/openssl
 156e34f..bbf73f8  master -> origin/master
 1027ad4..3953bf5  OpenSSL_1_0_2-stable -> origin/OpenSSL_1_0_2-stable
   = [up to date]  OpenSSL_1_0_1-stable -> origin/OpenSSL_1_0_1-stable
  ... {at least "master" and "remotes/origin/master" differ, marking for autogc}
  ... ok: openssl.git
  

  
  openssl.git: performing autoup: automerge

  ... Performing automerge from origin/master to master
  Updating 156e34f..bbf73f8
  Fast-forward
   CHANGES | 4 
   1 file changed, 4 deletions(-)
  ... ok: openssl.git
  
  Turned over to mode gc

  
  openssl.git: performing gc

  real0m10.079s
  user0m6.830s
  sys 0m1.703s
  ... ok: openssl.git
  
  
  
  All seems fine around here, ciao
  ?0[steffen@wales code.arena]$ cd openssl.git/
  ?0[steffen@wales openssl.git]$ git describe master
  OpenSSL_1_1_0-pre6-297-gbbf73f8

No, no, not that i know.
Ciao.

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

Re: [openssl-dev] OpenSSL version 1.1.0 published

[Steffen Nurpmeso]

Good evening.

OpenSSL  wrote:
 |   OpenSSL version 1.1.0 released

A bit distressing that it is me again, as if i would have
something to do with that..., but: the tag is missing.

 |https://www.openssl.org/news/openssl-1.1.0-notes.html

Looks good in Lynx!
Anyway, it must be a huge relief to finally be rid of all those
lines of development, with a [master] that is several thousand
commits ahead, so: Congratulations!
Ciao.

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

[openssl-dev] [openssl.org #4627] Doc patch: fix constant names

[Steffen Nurpmeso via RT]

Against [80f397e]

diff --git a/doc/ssl/SSL_CONF_cmd.pod b/doc/ssl/SSL_CONF_cmd.pod
index fb39f94..7b38489 100644
--- a/doc/ssl/SSL_CONF_cmd.pod
+++ b/doc/ssl/SSL_CONF_cmd.pod
@@ -124,8 +124,8 @@ than the deprecated alternative commands below.
 =item B<-no_ssl3>, B<-no_tls1>, B<-no_tls1_1>, B<-no_tls1_2>
 
 Disables protocol support for SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 by setting the
-corresponding options B, B, B
-and B respectively.
+corresponding options B, B, 
B
+and B respectively.
 These options are deprecated, instead use B<-min_protocol> and 
B<-max_protocol>.
 
 =item B<-bugs>

--steffen


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

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

Re: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process

[Steffen Nurpmeso]

I hope i don't "open" this one!

Richard Levitte via RT  wrote:
 |On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
 |> I have never seen something like this:
 |>
 |> Parser.c: loadable library and perl binaries are mismatched (got
 |> handshake key 0xdb00080, needed 0xdb80080)

I should have added that is happened during HTML creation
/ installation at first, sorry for that!

  install ./doc/ssl/SSL_set_verify_result.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_set_verify_result.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)
  install ./doc/ssl/SSL_shutdown.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_shutdown.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)
  install ./doc/ssl/SSL_state_string.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_state_string.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)

 |> This is v5.24 on a Linux system, and it flawless afaik.
 |
 |Are you sure that you don't have perl modules that you installed separately
 |with an earlier perl version? You may need to update those.

An incredible amount thereof!  You are using HTML::Parser?

  HTML::Parser  3.7100  3.7200

 |Either way, this is not an OpenSSL issue, it's a perl one. Closing th\
 |is ticket.

Sorry for the noise!
Please don't mind.
Ciao.

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

Re: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process

[Steffen Nurpmeso via RT]

I hope i don't "open" this one!

Richard Levitte via RT  wrote:
 |On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
 |> I have never seen something like this:
 |>
 |> Parser.c: loadable library and perl binaries are mismatched (got
 |> handshake key 0xdb00080, needed 0xdb80080)

I should have added that is happened during HTML creation
/ installation at first, sorry for that!

  install ./doc/ssl/SSL_set_verify_result.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_set_verify_result.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)
  install ./doc/ssl/SSL_shutdown.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_shutdown.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)
  install ./doc/ssl/SSL_state_string.pod -> 
/home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_state_string.html
  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)

 |> This is v5.24 on a Linux system, and it flawless afaik.
 |
 |Are you sure that you don't have perl modules that you installed separately
 |with an earlier perl version? You may need to update those.

An incredible amount thereof!  You are using HTML::Parser?

  HTML::Parser  3.7100  3.7200

 |Either way, this is not an OpenSSL issue, it's a perl one. Closing th\
 |is ticket.

Sorry for the noise!
Please don't mind.
Ciao.

--steffen


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

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

[openssl-dev] [openssl.org #4557] Nit: temporary files left over after [master:8d054a5] installation process

[Steffen Nurpmeso via RT]

Yep:

  -rw---  1 steffen steffen  1848 Jun  2 14:46 VhXl383LiQ
  -rw---  1 steffen steffen  1612 Jun  2 14:46 F1RkvxEZi0
  -rw---  1 steffen steffen  1848 Jun  2 14:46 qg_wML0XIF
  -rw---  1 steffen steffen  1848 Jun  2 14:46 4MUN7KIs69
  -rw---  1 steffen steffen  1840 Jun  2 14:46 fU_zMQI7Wb
  -rw---  1 steffen steffen  1848 Jun  2 14:46 gbNE7UjUAJ
  -rw---  1 steffen steffen  1848 Jun  2 14:46 P2Vff7Duiz
  -rw---  1 steffen steffen  1840 Jun  2 14:46 3E_oztoePh

;do head -n 1 $i; done:

  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-
  -BEGIN SSL SESSION PARAMETERS-

--steffen


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

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

[openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals

[Steffen Nurpmeso via RT]

Oh yes, please!

--steffen


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

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

[openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process

[Steffen Nurpmeso via RT]

Hello.

I have never seen something like this:

  Parser.c: loadable library and perl binaries are mismatched (got handshake 
key 0xdb00080, needed 0xdb80080)

This is v5.24 on a Linux system, and it flawless afaik.
Thanks.

--steffen


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556
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] simplifying rand_egd API

[Steffen Nurpmeso]

"Salz, Rich"  wrote:
 |There are currently three functions related to the EGD:   
 |int RAND_egd(const char *path);
 |int RAND_egd_bytes(const char *path, int bytes);
 |int RAND_query_egd_bytes(const char *path, unsigned char *buf\
 |, int bytes);
 |
 |I would like to just have a single function
 | Int RAND_add_egd(const char* path)
 |
 |Does anyone use those three functions?

For obvious reasons preprocessor conditionalized i do maintain the
first.  Yes i think that is a sane one to have.  (Whereas
i personally don't have a strong opinion on that topic at all i do
think that having an easy way to use a random source of choice may
be interesting for, e.g., students or researchers.  So i truly
think that saying "please keep this interface" isn't backed by
noone, wether they speak up or not today.)

P.S.: i like the new website; i had Matt Caswell's message laying
around for many weeks but a reply never made it.  Not that it
matters, anyway.

Ciao,

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

[openssl-dev] [openssl.org #3954] Enhancement suggestion: extend x509(1) with -key-fingerprint

[Steffen Nurpmeso via RT]

Hello,

for certificates which get renewed -- mine do twice a year, for
example -- the fingerprint changes

  ?0[tmp]$ openssl x509 -fingerprint -noout  cert.old
  SHA1 Fingerprint=00:10:F0:2C:EA:50:1F:11:FE:8D:CC:A0:A9:40:91:A2:D0:4D:65:4E
  ?0[tmp]$ openssl x509 -fingerprint -noout  cert.crt
  SHA1 Fingerprint=77:E3:10:F0:3B:D9:1E:1F:29:B0:83:74:50:29:67:E4:04:B2:53:B1

Of course if you have the CA's certificate you can verify the
validity of the above, but if i change the CA you need to get that
one etc.  I may also change to a self-signed CA.  Imagine i need
to renew my certificate, switch the CA and use sk_X509_push() to
include the new root certificate that signed my updated
certificate with my .p7s.  The receiver will (possibly) get
a verification failure, but if there would be an easy possibility
to verify the fingerprint of the public key he or she would be
able to verify that only the certificate changed, not the key:

  ?0[tmp]$ openssl x509 -pubkey -noout  cert.old|
   openssl rsa -pubin -outform der|
   openssl sha1
  writing RSA key
  (stdin)= 0e349338a3baf9f1edf176dd02151939a31ebb79
  ?0[tmp]$ openssl x509 -pubkey -noout  cert.crt|
   openssl rsa -pubin -outform der|
   openssl sha1
  writing RSA key
  (stdin)= 0e349338a3baf9f1edf176dd02151939a31ebb79

In the end the key is an authority by itself, no?

--steffen

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #3949] Bug: PKCS_final.7 not installed

[Steffen Nurpmeso via RT]

And on [1] (at least) the link Please see the list of new or open
bugs and requests. leads to nowhere.
Ciao,

  [1] http://openssl.org/support/rt.html

--steffen

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] OpenSSL Security Advisory

[Steffen Nurpmeso]

Huhu!!

 |Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx

I just want to mention these «UTF-8 re-encoded as UTF-8» issues,
which may be acceptable for names of males, but, but
*particularly* with respect to the natural beauty of the affected
person…  On the other hand i always knew engineers have the
etiquettes of construction workers.
The good news: it seems to be a long way to Boko Haram.  Still.


Also it is a real pity that it seems to be too hard to copy and
paste the NEWS.  And now it didn't even help to point one of those
HTML monsters to the cesspool.
Wait.  I haven't said there is a coincidence.


(^_^)/

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

Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Matt Caswell m...@openssl.org wrote:
 |On 19/05/15 17:40, Kurt Roeckx wrote:
 | I think that we should just provide the SSLv23_client_method define
 | without the need to enable something, and I guess I missed
 | something during the review in that case.
 |
 |The reason you need to enable something is that SSLv23_client_method is
 |now deprecated. If you want it to just work then you would need to
 |un-deprecate it. That's ok but it has the disadvantage that the old name
 |will then stick around indefinitely and quite probably will be used even
 |for new code.

It seems to me you should introduce a multiple-step deprecation
scheme.
But this function series in particular is documented as
effectively the way to go in a very famous book that is so old
that it now can be downloaded for free, and i'd expect that almost
all software projects use it: turning it off overnight seems to be
a bad decision to me.

While here, so let me add my opinion, and that is that it would
possibly be better to allow NULL or (maybe better) (a) special
(*)-1(,2,3) constant(s) arguments to SSL_CTX_new() instead of
replacing SSLv23_(client_)?method() with a different
protocol-multiplexer.  E.g,, SSL_CTX_new(SSL_METHOD_ANY) or the
like.  I'd expect that the actual protocol limitation is done via
_set_options() or SSL_CONF_CTX_cmd() later on anyway, just as
documented.

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

Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Kurt Roeckx k...@roeckx.be wrote:
 |On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote:
 | Steffen Nurpmeso sdao...@yandex.com wrote:
 ||Kurt Roeckx k...@roeckx.be wrote:
 |||I think that we should just provide the SSLv23_client_method define
 |||without the need to enable something, and I guess I missed
 |||something during the review in that case.
 ||
 ||Thanks for the clarification.
 | 
 | Ehm, one more nit: in order to be able to compile [master] i need
 | this patch (tests like it fwiw):
 |
 |It builds fine for me.  Can you give the error where it fails to
 |build?

I never claimed the patch was correct, i still got

  c_zlib.c:113:5: warning: excess elements in struct initializer
  NULL,
^~~~

But understandably i wanted to adjust for upcoming 1.1.0 changes
asap (you seem to encourage people using [master] for this purpose
if i recall correctly) and then there was (i say «Ciao!» here)

c_zlib.c:113:5: warning: excess elements in struct initializer
NULL,
^~~~
/usr/include/stdio.h:84:14: note: expanded from macro 'NULL'
#define NULL __DARWIN_NULL
 ^
/usr/include/sys/_types.h:91:23: note: expanded from macro '__DARWIN_NULL'
#define __DARWIN_NULL ((void *)0)
  ^~~
c_zlib.c:203:57: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_new_ex_data(CRYPTO_EX_INDEX_COMP, ctx, ctx-ex_data);
   ~~~  ^
c_zlib.c:204:30: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_set_ex_data(ctx-ex_data, zlib_stateful_ex_idx, state);
~~~  ^
c_zlib.c:214:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(ctx-ex_data,
 ~~~  ^
c_zlib.c:219:58: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_free_ex_data(CRYPTO_EX_INDEX_COMP, ctx, ctx-ex_data);
~~~  ^
c_zlib.c:228:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(ctx-ex_data,
 ~~~  ^
c_zlib.c:257:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(ctx-ex_data,
 ~~~  ^
1 warning and 6 errors generated.
make[2]: *** [c_zlib.o] Error 1
make[1]: *** [subdirs] Error 1
make: *** [build_crypto] Error 1
?2[steffen@sherwood openssl.git]$ gl1

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

Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Salz, Rich rs...@akamai.com wrote:
 |   c_zlib.c:113:5: warning: excess elements in struct initializer
 |   NULL,
 | ^~~~
 |
 |Are you sure you have an accurate copy of master?
 |
 |The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 \
 |as part of making the COMP structures opaque.

That was the commit i had blamed as the culprit, yes. :)

¡Hasta la victoria siempre!

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

[openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Hello,
i've just read on the Lynx list about compilation error because of
a missing SSLv23_method() and indeed [1] says it is deprecated and
a new TLS_client_method() is to be used instead.  Now i've
searched on Gmane but i couldn't find just any word.  (Let's just
hope that there will be TLS v1.4, .5...)  So well, now i've
updated [master] and see indeed commit [32ec415] stating

  Also, SSLv23_method and SSLv23_server_method have been replaced
  with TLS_method and TLS_server_method respectively. The old
  SSLv23* names still exist as macros pointing at the new name,
  although they are deprecated.

Looking at the diff it seems that OPENSSL_USE_DEPRECATED is
required to get the names.

  [1] https://www.openssl.org/docs/ssl/SSL_CTX_new.html

Since my last v1.1.0 compile check was against an installation
(got and) made on March 19th with OPENSSL_VERSION_NUMBER EQ
0x1010L i would like to know how i can code my software to be
(also future) compatible with OpenSSL.
I would ask on @users but are no longer subscribed there.  (Also
i think this is such a drastic change that it is worth a note
here.)
Can someone please shed any light on this, please?
Thank you!

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

Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Kurt Roeckx k...@roeckx.be wrote:
 |I think that we should just provide the SSLv23_client_method define
 |without the need to enable something, and I guess I missed
 |something during the review in that case.

Thanks for the clarification.

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

Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Steffen Nurpmeso]

Steffen Nurpmeso sdao...@yandex.com wrote:
 |Kurt Roeckx k...@roeckx.be wrote:
 ||I think that we should just provide the SSLv23_client_method define
 ||without the need to enable something, and I guess I missed
 ||something during the review in that case.
 |
 |Thanks for the clarification.

Ehm, one more nit: in order to be able to compile [master] i need
this patch (tests like it fwiw):

diff --git a/crypto/comp/comp_lcl.h b/crypto/comp/comp_lcl.h
index f1ec8d5..1360f56 100644
--- a/crypto/comp/comp_lcl.h
+++ b/crypto/comp/comp_lcl.h
@@ -71,4 +71,5 @@ struct comp_ctx_st {
 unsigned long compress_out;
 unsigned long expand_in;
 unsigned long expand_out;
+CRYPTO_EX_DATA ex_data;
 };
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Steffen Nurpmeso]

Hello,

Dr. Stephen Henson st...@openssl.org wrote:
 |On Fri, Feb 13, 2015, Viktor Dukhovni wrote:
 | On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote:
 | Some time ago, I had submitted a patch which allows administrators, but
 | most importantly OS distributors to set their own strings \
 | in the configuration

 | And my intent is to pull this into master pretty soon.

 | We may not need a patch for this, I thought we were about to deprecate
 | OpenSSL_config() with its void return status and encourage folks

 |Just clarification. The initialisation we're recommending I normally refer
 |to as config modules. NCONF is a more general API for configuration files.

I think an interesting question would be wether that configuration
API will eventually obsolete the direct function interface?

 |Config modules were intended to be used for application setup so would
 |be a good place to add a system cipher string instead of a \
 |whole new mechanism.
 |The only problem is that it would only work with application that supported
 |config modules.

So break API compatibility and extend the mandatory
SSL_library_init() to incorporate the functionality of
CONF_modules_load_file(), introducing a SSL_library_free()
counterpart?
Or don't break compatibility and let SSL_library_init() internally
do OPENSSL_config() unless OPENSSL_INIT_DONT_LOAD_CONF is defined?
Or ditto but introduce a new SSL_library_init_with_conf() with an
SSL_library_free_with_conf(), too.
It will be very interesting to see how you will overcome that
deadlocked situation.
Have a nice weekend.

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

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Steffen Nurpmeso]

Hello,

Nikos Mavrogiannopoulos n...@redhat.com wrote:
 |On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote:

 | And i want to point to OPENSSL_config(3) which states for a longer
 | time duration:
 | 
 |It is strongly recommended that all new applications call
 |OPENSSL_config() or the more sophisticated functions such as
 |CONF_modules_load() during initialization (that is \
 |before starting any

 |   # /etc/openssl.rc
 |   [ciphers]
 |   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
 |   !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
 | 
 | so that a user could do
 | 
 |   # ~/.openssl.rc
 |   [ciphers]
 |   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384
 |
 |Some time ago, I had submitted a patch which allows administrators, but
 |most importantly OS distributors to set their own strings in the
 |configuration file, which software can then rely on, to provide a
 |consistent security level: https://github.com/openssl/openssl/pull/192

sorry, i haven't seen that yet.  Of course, definining their very
own profile in a special namespace is i think also a great option
for users.

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

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Steffen Nurpmeso]

Oh, this thread is about the OpenSSL configuration package that
Rich Salz promised!..

Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 |On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
 | Note that for most applications the correct approach to configuring
 | ciphersuites should be to start with DEFAULT and subtract what they don't
 | want.  The library is then responsible for a generally \
 | sensible default order
 | and default exclusions.
 |
 | I strongly disagree.  Most applications should explicitly list the
 | ciphers they DO want.  That is the only way an application can be sure
 | of what it is getting, without consulting external parties or
 | configuration.  Otherwise, when the next Crime or Poodle or
 | NameOfTheWeek comes out, you have no idea if you are vulnerable or not
 | unless you look at something like the OpenSSL source code.
 |
 | For what it's worth, I believe that security levels make this
 | problem much worse.
 |
 |I disagree with you here, Rich.  There is ongoing evolution of our

I do, too.

 |understanding of TLS best practices, including standards, cryptanalysis,
 |and interoperability.  This dynamic situation seems unlikely to be come
 |static at any point in the future (changes in standards, cryptanalysis,
 |and the state of the network will continue to occur).  Even those of us
 |who spend a lot of time thinking about these matters have a hard time
 |keeping up.
 |
 |As a larger ecosystem, we have maybe three main options to manage this
 |dynamism:
 |
 |  0) every adminstrator of every TLS-using network service and every
 | user of every TLS-using client needs to fiddle with TLS parameter
 | selection as changes happen.
 |
 |  1) every developer of every TLS-using tool (client or server) needs to
 | fiddle with TLS parameter selection as changes happen.
 |
 |  2) every library that implements TLS needs to fiddle with TLS
 | parameter selection as changes happen.
 |
 |Situation (0) is clearly untenable (it's also what we are valiantly
 |attempting today, e.g. https://bettercrypto.org/, because the other
 |things haven't happened effectively).
 |
 |And situation (1) is just plain unlikely to happen.  Most software
 |developers *want* TLS to be magic sauce that they can sprinkle on and
 |have it Just Work.  They do not want to keep track of which parameters
 |are considered a bad idea this month, and they certainly don't want to
 |release new versions of their software just because someone says hey,
 |you need to update your cipherstring.
 |
 |On the other hand, the people who are experts in this situation and who
 |understand the dynamics best are going to be the folks tapped for the
 |work in (2).  This is why these kinds of things should be done by
 |default in the TLS implementations.

I absolutely support all statements of Daniel Kahn Gillmore, but
especially that dynamism must be handled at a place that can be
adjusted without the necessity for any recompilation.
And i want to point to OPENSSL_config(3) which states for a longer
time duration:

   It is strongly recommended that all new applications call
   OPENSSL_config() or the more sophisticated functions such as
   CONF_modules_load() during initialization (that is before starting any
   threads). By doing this an application does not need to keep track of
   all configuration options and some new functionality can be supported
   automatically.

and so this finally appears to me as a natural place for such
things.  (The next version of the MUA i maintain will, also
finally, add support for this, for example.)

I think it was a bug report (sigh; btw., is the new EVP test still
broken regarding evp_test(33743) malloc: pointer being freed was
not allocated?) where i've expressed my own personal feelings
about that topic, in that i think the best would be if the
configuration file would be extended to offer the necessary
possibilities, yet i would dramatically change the current
semantics, for example regarding $OPENSSL_CONF, but there also
should be an option to enable the usual Unix configuration file
chain way of doing things (global configuration file, $HOME
configuration file), and an administrator should have the option
to fixate some settings, possibly via a new ! prefix to
a variable option, as in

  # /etc/openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
  !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384

so that a user could do

  # ~/.openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384

but not

  # ~/.openssl.rc
  [ciphers]
  ALL=ECDHE-RSA-AES256-GCM-SHA384

because the administrator cramped the possibilities.
The good thing about that approach is definitely that necessary
changes after revealed protocol or cipher insecurities could be
applied immediately by anybody after reading an announcement mail,
without the need for any recompilation or even a library release.
Of course OpenSSL could provide a 

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Steffen Nurpmeso]

Hello,

Thanks for OpenSSL first.
And again when you can read this.

Matt Caswell m...@openssl.org wrote:
 |On 22/01/15 22:34, Steffen Nurpmeso wrote:
 | Since noone else seems to say a word.
 | I personally didn't understand at all why v1.0.2 when its
 | end-of-life is in sight already.
 |
 |From my personal point of view I would like all our releases to have
 |defined up front lifetimes, so that it is clear how long you can expect
 |to receive support for.  With respect to 1.0.2 we're not actually quite
 |there as we've only said:
 |Version 1.0.2 will be supported until at least 2016-12-31.

My bad!  I would have sworn that i had read 2015-12-31 as EOL for
v1.0.2 in some message, but apparantly no such statement was
posted to @announce, @devel nor @user at all.

 |Note the at least. There is a good chance that it will be supported
 |for significantly longer than that. The reasons for that are discussed
 |in my recent blog post:
 |https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/

I personally would prefer such a posting on -dev@, but great that
lynx(1) can be used to read this blog, that's not self-evident.

 |  Now you have to continue to
 | track three active branches.  But this is your problem of course.
 |
 |Actually its four :-( - 0.9.8, 1.0.0, 1.0.1 and 1.0.2 (and of course we
 |have master as well). Again see my blog post for a discussion on the
 |thinking that went into it. As ever these decisions are a compromise
 |between many competing pressures.

Sympathy!
After all you are now more with some support by the vcs.

 [.]
 | So why that hastiness, now that OpenSSL gains enough money to pay
 [.]

 |Well 1.0.2 was in beta for nearly a year, so I'm not sure I would

Of course.  Of course.
And i think we are all looking forward to see what the future
brings.  (Myself even starves for documentation [coverage]
improvements.)

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

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Steffen Nurpmeso]

Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 |On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:

 | brings.  (Myself even starves for documentation [coverage]
 | improvements.)
 |
 |fwiw, OpenSSL documentation is pretty easy to read and to edit.  If you
 |notice that things are missing, you can edit the docs, and submit
 |patches either on this mailing list, on the rt bugtracker at
 |https://rt.openssl.org/, or as a pull request via github:
 |
 | https://github.com/openssl/openssl

And fwiw :) i don't have a github account -- i had one but wanted
to pay (also because they paid a developer for git(1)
development), yet they didn't accept cash.  And i *completely*
decline using credit cards.

--steffen
---BeginMessage---
On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:

 And i think we are all looking forward to see what the future
 brings.  (Myself even starves for documentation [coverage]
 improvements.)

fwiw, OpenSSL documentation is pretty easy to read and to edit.  If you
notice that things are missing, you can edit the docs, and submit
patches either on this mailing list, on the rt bugtracker at
https://rt.openssl.org/, or as a pull request via github:

 https://github.com/openssl/openssl

the main documentation is in the doc/ directory, either under
doc/crypto/ (for libcrypto documentation) or doc/ssl/ (for libssl
documentation).  It is in pod format, which is pretty easy to read and
get the hang of if you've used other markup languages.

If you have a proposed change but you aren't sure that you've got the
syntax right, go ahead and post the change anyway (in any of the three
forums i mentioned above) and indicate that you'd like an extra
double-check on the syntax.

Contributions to improve documentation are important contributions, and
it's a great way to give back to the project.

  --dkg

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

Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released

[Steffen Nurpmeso]

Since noone else seems to say a word.
I personally didn't understand at all why v1.0.2 when its
end-of-life is in sight already.  Now you have to continue to
track three active branches.  But this is your problem of course.

What i _really_ don't understand is why 1.0.2 is delivered with
false documentation (not only int SSL_CONF_finish(SSL_CONF_CTX
*cctx);) etc., especially given that there are bug reports.
Documentation is a vivid part of a software, especially when
a completely new interface is introduced.  From only the
documentation you won't be able to get that stuff going.
Is ALPN, a prominent member of the NEWS entry (you find it on the
website), at all documented?  Where can i find a word about it??

So why that hastiness, now that OpenSSL gains enough money to pay
the bread of not only one, but indeed multiple fulltime
developers.  And then the sponsors seem to accept spending time
for tree re-evaluation?  Is the OpenSSL project at the Wall Street
and needs to produce hyper-hyper quarterly reports?
That is really strange.
Ciao,

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

[openssl-dev] There is no SSL_CTX_get_ciphers() (and .._get_cipher_list())

[Steffen Nurpmeso]

I wonder about this interface oddity.
There is

  int SSL_CTX_set_cipher_list(SSL_CTX *ctx, const char *str);
  int SSL_set_cipher_list(SSL *ssl, const char *str);

but only

  STACK_OF(SSL_CIPHER) *SSL_get_ciphers(const SSL *ssl);
  const char *SSL_get_cipher_list(const SSL *ssl, int priority);

Since practically all other functions exist in two version (for
SSL_CTX*, for SSL*) this looks odd.
Shall i post an enhancement request?

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

Re: [openssl-dev] [openssl.org #3633] Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE

[Steffen Nurpmeso via RT]

Stephen Henson via RT r...@openssl.org wrote:

All i can parse from your answer is that the statement that is
long in OpenSSL documentation and was referred to by Rich Salz
(unless i'm mistaken) in a different #issue, namely the following
paragraph from OPENSSL_config(3):

  It is strongly recommended that all new applications call
  OPENSSL_config() or the more sophisticated functions such as
  CONF_modules_load() during initialization (that is before starting any
  threads). By doing this an application does not need to keep track of
  all configuration options and some new functionality can be supported
  automatically.

 |On Fri Dec 12 17:52:22 2014, sdao...@yandex.com wrote:
 | Hello,
 |
 | while following Rich Salz's suggestion to make use of
 | CONF_modules_load_file() i stumbled personally over the
 | restriction that only a global openssl.cnf seems to be supported.
 | There is no support for automatic loading of a $HOME/.openssl.cnf
 | on top of the global version.
 |
 | And whereas setting of $OPENSSL_CONF could be used and
 | communicated to users to achieve the desire, doing so actually
 | replaces inclusion of the global openssl.cnf, which likely not
 | results in the wanted effect!?!
 | While here, it doesn't seem possible to _forbid_ use of
 | $OPENSSL_CONF (from reading the manual)?
 | If that is true then i would ask for an additional
 | CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too.
 |
 |
 |While that could be done it would be a while before the new \
 |feature appeared in
 |released versions of OpenSSL. You can get finger control over \
 |the configuration
 |using existing APIs with current versions of OpenSSL.

 |With CONF_modules_load_file() if the passed filename is not NULL then that
 |value is used only. You only get the use of a local or system openssl.cnf if
 |the filename passed is NULL. So if you pass the path to a \
 |system openssl.cnf
 |it cannot be overridden by the OPENSSL_CONF environment variable.

How do i get a notion of the actual path in order to prevent that?
I'd like the openssl-conf package provided openssl.cnf with the
newest global protocol and cipher specifications, and i don't want
noone to mess that up.

Except that i want that a user may add something on top.
Btw. i also once had a failed attempt with resource files, along
the lines

*   [!/immutable/group]
*   [#10#/group/with/limit]

*   !immutable_entry=some value
*   (int)refresh_time=60

i.e., with things that were fixateable on a global level, even if
a user provided his own ~/.xyrc.
(With compiled-in default configs etc., it became much too bloated
and never sprung into existence.  But only a `!' prefix may be
worthwile for something security related as OpenSSL is.)

 |The function CONF_modules_load can be passed the CONF structure \
 |to use directly
 |which doesn't need to come from a file at all. It could be \
 |from multiple files,
 |hard coded data or something strange like the Window registry (if the
 |appropriate code was written to add the data to the CONF structure).

Wise words spoken.  (Could.)

--steffen


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

[openssl-dev] [openssl.org #3632] Enhancement request: CONF_modules_load_file(): please include filename in error message

[Steffen Nurpmeso via RT]

So i follow Rich Salz and am adding support for
SSL_CONF_modules_load_file() (but i'm still wondering a bit why
i do that) and while testing (with v1.0.2 beta4) i see messages
like

  error:02001002:system library:fopen:No such file or directory
  error:0200100D:system library:fopen:Permission denied

Which file are we talking about?
(Hint: it is /usr/local/ssl/openssl.cnf.)

--steffen


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

[openssl-dev] [openssl.org #3633] Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE

[Steffen Nurpmeso via RT]

Hello,

while following Rich Salz's suggestion to make use of
CONF_modules_load_file() i stumbled personally over the
restriction that only a global openssl.cnf seems to be supported.
There is no support for automatic loading of a $HOME/.openssl.cnf
on top of the global version.

And whereas setting of $OPENSSL_CONF could be used and
communicated to users to achieve the desire, doing so actually
replaces inclusion of the global openssl.cnf, which likely not
results in the wanted effect!?!
While here, it doesn't seem possible to _forbid_ use of
$OPENSSL_CONF (from reading the manual)?
If that is true then i would ask for an additional
CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too.

--steffen


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

[openssl-dev] [openssl.org #3634] Docfix: doc/apps/enc.pod says aes-[128|192|256] but means aes[..]

[Steffen Nurpmeso via RT]

..so that even after OpenSSL_add_all_algorithms(3)
EVP_get_cipherbyname(3) fails to load aes-128 as an alias for
aes-128-cbc.

--steffen

diff --git a/doc/apps/enc.pod b/doc/apps/enc.pod
index 41791ad..88e8b79 100644
--- a/doc/apps/enc.pod
+++ b/doc/apps/enc.pod
@@ -282,7 +282,7 @@ authentication tag.
  rc5-ofbRC5 cipher in OFB mode
 
  aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode
- aes-[128|192|256] Alias for aes-[128|192|256]-cbc
+ aes[128|192|256]  Alias for aes-[128|192|256]-cbc
  aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode
  aes-[128|192|256]-cfb1128/192/256 bit AES in 1 bit CFB mode
  aes-[128|192|256]-cfb8128/192/256 bit AES in 8 bit CFB mode


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

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso via RT]

Hello,

Stephen Henson via RT r...@openssl.org wrote:
 |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote:

 | If people start using SSL_CONF_CTX as they are supposed to with
 | v1.0.2, then it can be expected that users start using strings
 | like, e.g. (from my thing),
 |
 | set ssl-protocol=ALL,-SSLv2

 |If you print out the additional error data it should also indicate which
 |command and value it is objecting to, though it will only \
 |say it doesn't like
 |the whole string and not the specific part of it it is rejecting.

Oh i'm not complaining on that, error handling is always weird,
and i think strings like

  error:140D00CF:SSL routines:SSL_write:protocol is shutdown

are hard (not only to parse) for users but there is a lot of
information for good in very few bytes; sad is

  Received SIGPIPE during IMAP operation
  IMAP write error: error::lib(0):func(0):reason(0)

but as i think for most (Open)SSL related problems this is all my
/ our fault, users should not be bothered with that.
Strings are intransparent for application programmers, but myriads
of error enumerations can be too.  Whatever.

Regarding #3625: i think no user (that made it so far at first
glance, which maybe even required buying a book and reading
a lot!) would expect an error for saying -SSLv2.
But since it was an accidental oversight and the _OP_NO_SSLv2 is
still defined (what i didn't even look for after reading the
commit message) i think it'll be ok anyway once committed and this
can be closed?
Ciao,

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Salz, Rich via RT r...@openssl.org wrote:
 | Personally i am willing to put enough trust in the OpenSSL team *even
 | insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE'
 | and leave the task of deciding what is VULNERABLE up to you.
 |
 |That is not a responsibility we want.  No how, no way.  It \
 |is enough to be responsible for the code.
 |
 |There are better alternatives, including bettercrypto.org \
 |and another proposal from RedHat to have site/distro-specific 'profiles' 

Sorry but i simply fail to understand your point of view.
I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as
MIN/MAX/SECURE (bring, but.. understandable).

But i really missed (and still miss) the possibility on the
_OP_NO_ level, and being able to completely bypass my own thing
and give the user a direct hook into OpenSSL via _CONF_ is a great
thing to have.  That is what is actual fact in normal user space
applications, if you want to replace that by some
installation-wide policy then this is a nice idea, but it'll take
decades until it reaches the last (maintained) application.

Many programs support multiple TLS/SSL implementations and need to
be able to configure the one which the user actually chooses to
use / is available on the box.  So your proposal needs to be
adhered to by other TLS/SSL providers too in order to release
applications from their compatibility problem.

Of course i need an application internal compatibility layer for
those implementations which don't support a direct _CONF_ hook as
OpenSSL will start to support with v1.0.2 (though reducing my own
thing to only support OpenSSL was one of the first steps i did,
yet support for others will be readded later again).  And for
those i need to know relationships, what is secure etc.  But
i also need to know actual protocol names anyway, so whatever
i do, without active maintainership things will rot.  This is why
i would be very happy if there would be NEWEST, because even
a rotted codebase would be automatically secure -- should the
NEWEST protocol be secure.  And if NEWEST is not supported by some
counterpart server, then the user can still fine-tune and lower as
far as necessary.  I think this is the much better way 'round.

Giving a user an option to actively deselect what is known not to
be secure for a library release that still needs to support old
protocols due to compatibility reasons can't be wrong.
Of course users are capable to understand that a library update is
necessary to overcome a newly detected insecurity.
The maintenance burden of the OpenSSL library seems to be pretty
drastic; regarding these strings those could be placed into ssl.h,
maybe encapsulated in some library-built-time preprocessor toggle.

Surely my own thing can be enhanced a lot, with more configuration
options for users, with adhering to system wide defaults, but i am
only one and that needs more time.
I neither have the time nor the will (i am an elder man in the
end) to spend time on rat racing some stylish internet pages.  If
i want communication i listen to good interprets of classical
music.  Thanks for your consideration.

Ciao,

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Yoav Nir ynir.i...@gmail.com wrote:
 | On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org \
 | wrote:
 | Salz, Rich rs...@akamai.com wrote:
 ||I think magic names -- shorthands -- are a very bad idea. \
 | 
 | I _completely_ disagree.
 | 
 || They are point-in-time statements whose meaning evolves, \
 ||if not erodes, over time.
 | 
 | Because i don't think that a normal user, or even normal
 | administrators and programmers is and are willing or even capable
 | to understand what they are doing.

 |decision than most administrators. Nevertheless, if upgrading \
 |OpenSSL from version X to version Y causes a ciphersuite (or \
 |TLS version) to be dropped into VULNERABLE, there are going \
 |to be angry phone calls from users whose browser or application \
 |has stopped working. It is the administrator who is going \

Applications don't need to use -VULNERABLE/+SECURE.
Heck, the monster ones have become so intransparent that i have to
place such an enormous trust into them that i only use one,
Firefox, but that does terrible things and there is no knob that
i can toggle wheresoever.  (I've used Opera for over a decade and
am very new to Firefox: i'm pretty sure there is some kind of
registry that experienced users can tweak.  But still: certainly
neither in the Advanced nor the Security Tab.)

_How_ i would appreciate being able to enter -VULNERABLE in some
text field.  And have a nicer and easier exception handling, too.
Can be imagined.

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Salz, Rich via RT r...@openssl.org wrote:

 | Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE,

 |I am more concerned about the case where a common crypto type \
 |is broken, and zillions (a technical term :) of websites are \
 |now at-risk because there wasn't an immediate OpenSSL update \
 |that added the broken crypto  to the VULNERABLE list, and \
 |everyone didn't update immediately.
 |
 |Policy and configuration should be on a separate, arguably \
 |faster, distribution pattern than code.   Which is why I favor \
 |a profile mechanism in openssl.conf and not hardwired magic \
 |keywords embedded in code.

So you want a separate openssl-conf package.  Fine, then provide
it and give an easy mechanism for applications to hook into it.
And for users to be able to overwrite system defaults.
But this has not that much to do with #3627.

 |

 |Perhaps modesty prevented you from posting the link, but it \
 |won't stop me (we're both in the acknowledgements section :)
 | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07

I have to look into OCSP.  (But it has nothing to do with #3627.)

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Salz, Rich via RT r...@openssl.org wrote:
 | I'd love to see a version of bettercrypto.org that only \
 | has to say to configure
 | OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE
 |
 |That can happen but not by embedding magic strings into code.  See

But isn't TLSv1.2 also a magic string?
I mean i hope we come to an end with this soon...
But doesn't a OpenSSL library installation _as such_ represent
such an immense combination of magic, regarding the internal
configuration settings..?
I wouldn't have a problem if you would add even more VULNERABLE,
also to other _CONF_ settings.  But i'm simple minded and as of
today Protocol is just about anything that my thing is concerned
of.  :-)

--steffen


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

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso]

Hello,

Stephen Henson via RT r...@openssl.org wrote:
 |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote:

 | If people start using SSL_CONF_CTX as they are supposed to with
 | v1.0.2, then it can be expected that users start using strings
 | like, e.g. (from my thing),
 |
 | set ssl-protocol=ALL,-SSLv2

 |If you print out the additional error data it should also indicate which
 |command and value it is objecting to, though it will only \
 |say it doesn't like
 |the whole string and not the specific part of it it is rejecting.

Oh i'm not complaining on that, error handling is always weird,
and i think strings like

  error:140D00CF:SSL routines:SSL_write:protocol is shutdown

are hard (not only to parse) for users but there is a lot of
information for good in very few bytes; sad is

  Received SIGPIPE during IMAP operation
  IMAP write error: error::lib(0):func(0):reason(0)

but as i think for most (Open)SSL related problems this is all my
/ our fault, users should not be bothered with that.
Strings are intransparent for application programmers, but myriads
of error enumerations can be too.  Whatever.

Regarding #3625: i think no user (that made it so far at first
glance, which maybe even required buying a book and reading
a lot!) would expect an error for saying -SSLv2.
But since it was an accidental oversight and the _OP_NO_SSLv2 is
still defined (what i didn't even look for after reading the
commit message) i think it'll be ok anyway once committed and this
can be closed?
Ciao,

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Hi.

Richard Moore richmoor...@gmail.com wrote:
 | Programs which use the OpenSSL library generally just want to flip a
 | switch and know that they've turned on security, instead of trying to

 |My experience suggests that while that might be what some developers want,
 |that's not what users want. They expect that if it works in the browser it
 |should work everywhere - even when the browser is jumping through hoops
 |like fetching missing intermediate certificates, downgrading security etc.

But now that it is christmas they can at least donate some dollars
to some charitable aid organisation.

 |If the world were perfect and the browsers didn't do this then life would
 |be a lot easier.

Ah, come on.  No.

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Salz, Rich via RT r...@openssl.org wrote:
 | Personally i am willing to put enough trust in the OpenSSL team *even
 | insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE'
 | and leave the task of deciding what is VULNERABLE up to you.
 |
 |That is not a responsibility we want.  No how, no way.  It \
 |is enough to be responsible for the code.
 |
 |There are better alternatives, including bettercrypto.org \
 |and another proposal from RedHat to have site/distro-specific 'profiles' 

Sorry but i simply fail to understand your point of view.
I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as
MIN/MAX/SECURE (bring, but.. understandable).

But i really missed (and still miss) the possibility on the
_OP_NO_ level, and being able to completely bypass my own thing
and give the user a direct hook into OpenSSL via _CONF_ is a great
thing to have.  That is what is actual fact in normal user space
applications, if you want to replace that by some
installation-wide policy then this is a nice idea, but it'll take
decades until it reaches the last (maintained) application.

Many programs support multiple TLS/SSL implementations and need to
be able to configure the one which the user actually chooses to
use / is available on the box.  So your proposal needs to be
adhered to by other TLS/SSL providers too in order to release
applications from their compatibility problem.

Of course i need an application internal compatibility layer for
those implementations which don't support a direct _CONF_ hook as
OpenSSL will start to support with v1.0.2 (though reducing my own
thing to only support OpenSSL was one of the first steps i did,
yet support for others will be readded later again).  And for
those i need to know relationships, what is secure etc.  But
i also need to know actual protocol names anyway, so whatever
i do, without active maintainership things will rot.  This is why
i would be very happy if there would be NEWEST, because even
a rotted codebase would be automatically secure -- should the
NEWEST protocol be secure.  And if NEWEST is not supported by some
counterpart server, then the user can still fine-tune and lower as
far as necessary.  I think this is the much better way 'round.

Giving a user an option to actively deselect what is known not to
be secure for a library release that still needs to support old
protocols due to compatibility reasons can't be wrong.
Of course users are capable to understand that a library update is
necessary to overcome a newly detected insecurity.
The maintenance burden of the OpenSSL library seems to be pretty
drastic; regarding these strings those could be placed into ssl.h,
maybe encapsulated in some library-built-time preprocessor toggle.

Surely my own thing can be enhanced a lot, with more configuration
options for users, with adhering to system wide defaults, but i am
only one and that needs more time.
I neither have the time nor the will (i am an elder man in the
end) to spend time on rat racing some stylish internet pages.  If
i want communication i listen to good interprets of classical
music.  Thanks for your consideration.

Ciao,

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Yoav Nir ynir.i...@gmail.com wrote:
 | On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org \
 | wrote:
 | Salz, Rich rs...@akamai.com wrote:
 ||I think magic names -- shorthands -- are a very bad idea. \
 | 
 | I _completely_ disagree.
 | 
 || They are point-in-time statements whose meaning evolves, \
 ||if not erodes, over time.
 | 
 | Because i don't think that a normal user, or even normal
 | administrators and programmers is and are willing or even capable
 | to understand what they are doing.

 |decision than most administrators. Nevertheless, if upgrading \
 |OpenSSL from version X to version Y causes a ciphersuite (or \
 |TLS version) to be dropped into VULNERABLE, there are going \
 |to be angry phone calls from users whose browser or application \
 |has stopped working. It is the administrator who is going \

Applications don't need to use -VULNERABLE/+SECURE.
Heck, the monster ones have become so intransparent that i have to
place such an enormous trust into them that i only use one,
Firefox, but that does terrible things and there is no knob that
i can toggle wheresoever.  (I've used Opera for over a decade and
am very new to Firefox: i'm pretty sure there is some kind of
registry that experienced users can tweak.  But still: certainly
neither in the Advanced nor the Security Tab.)

_How_ i would appreciate being able to enter -VULNERABLE in some
text field.  And have a nicer and easier exception handling, too.
Can be imagined.

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Salz, Rich via RT r...@openssl.org wrote:

 | Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE,

 |I am more concerned about the case where a common crypto type \
 |is broken, and zillions (a technical term :) of websites are \
 |now at-risk because there wasn't an immediate OpenSSL update \
 |that added the broken crypto  to the VULNERABLE list, and \
 |everyone didn't update immediately.
 |
 |Policy and configuration should be on a separate, arguably \
 |faster, distribution pattern than code.   Which is why I favor \
 |a profile mechanism in openssl.conf and not hardwired magic \
 |keywords embedded in code.

So you want a separate openssl-conf package.  Fine, then provide
it and give an easy mechanism for applications to hook into it.
And for users to be able to overwrite system defaults.
But this has not that much to do with #3627.

 |

 |Perhaps modesty prevented you from posting the link, but it \
 |won't stop me (we're both in the acknowledgements section :)
 | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07

I have to look into OCSP.  (But it has nothing to do with #3627.)

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Salz, Rich via RT r...@openssl.org wrote:
 | I'd love to see a version of bettercrypto.org that only \
 | has to say to configure
 | OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE
 |
 |That can happen but not by embedding magic strings into code.  See

But isn't TLSv1.2 also a magic string?
I mean i hope we come to an end with this soon...
But doesn't a OpenSSL library installation _as such_ represent
such an immense combination of magic, regarding the internal
configuration settings..?
I wouldn't have a problem if you would add even more VULNERABLE,
also to other _CONF_ settings.  But i'm simple minded and as of
today Protocol is just about anything that my thing is concerned
of.  :-)

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Hi.

Richard Moore richmoor...@gmail.com wrote:
 | Programs which use the OpenSSL library generally just want to flip a
 | switch and know that they've turned on security, instead of trying to

 |My experience suggests that while that might be what some developers want,
 |that's not what users want. They expect that if it works in the browser it
 |should work everywhere - even when the browser is jumping through hoops
 |like fetching missing intermediate certificates, downgrading security etc.

But now that it is christmas they can at least donate some dollars
to some charitable aid organisation.

 |If the world were perfect and the browsers didn't do this then life would
 |be a lot easier.

Ah, come on.  No.

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Salz, Rich via RT r...@openssl.org wrote:
 | So you want a separate openssl-conf package.  Fine, then provide it and
 | give an easy mechanism for applications to hook into it.
 | And for users to be able to overwrite system defaults.
 | But this has not that much to do with #3627.
 |
 |Yes it does.  :)  A newer simpler API that does what you want \
 |seems exactly the way forward.  Go for it.

You sound pretty good and done here..  Gratulations.  [Laughter]

Regarding the interface: back in 2011 i have started (only) writing
a Python (grr) script, which had a really simple way of doing
_any_ socket connection via

  class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator

The basic concept was that all you can do is

  def create_connection(serv, cafile=None, all_fingerprints=False):

where serv is a class Service,

  class Service(Config.Section):

that directly maps to a configuration type (shortened by doc)

[service]
uid = UID
url = NAME
proto = proto
port = NUMBER
upgrade-secure = BOOLEAN
fetch-folders = mailbox, another-mailbox, ...
options = protocol-dependend (comma separated list of options)

So wether TLS or not you simply

(err, conn) = SaSo.create_connection(serv)
if err:
return (intro +  'connect failure: ' + err, ESTAT_CONNECTION)
print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT)

_maximally_ extended by (for non-initially secured transport)

# Shall we try to upgrade to TLS (RFC 2595)?
if self.service.upgrade_secure:
resp = self._single('STLS')
if not resp:
self.error_append('\nServer does not seem to support secure ' +
'transport.\nYou need to disable the *upgrade-secure* ' +
'configuration setting.')
return
resp = SaSo.wrap_connection(self.conn)
if resp is not None:
self.error = 'failed to perform *upgrade-secure*: ' + resp
return

Cool, eh?  S-postman.py was that thing.
_That_ is in essence what i mean -- just think about the current
Python urllib is it CVE-2014-9365: not even programmers that know
do it the right way, how can you expect administrators and normal
users to do so, even _if_ the software allows the necessary
configuration.  Nono.

 |I've said that adding new magic keywords is not something \
 |we're going to do, and I've tried to explain the reasoning. \
 | I am sorry that you don't like it.

Despite that i continue to disagree _completely_.
The other way around would be the right way to go for
configuration, and if that doesn't work then the _library_ had to
be adjusted.  E.g. by splitting off a small config update package
that updates cipher lists and whatever (i am really not an expert.
Nor do i plan to become one) without the need to recompile
OpenSSL.  Cool.  But you are not there yet, are you?  :-)
So please please, give us MIN and MAX.
Ciao,


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

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso via RT]

Dr. Stephen Henson st...@openssl.org wrote:
 |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote:
 | are hard (not only to parse) for users but there is a lot of
 | information for good in very few bytes; sad is
 | 
 |   Received SIGPIPE during IMAP operation
 |   IMAP write error: error::lib(0):func(0):reason(0)
 |
 |OpenSSL itself should never generate that error through (for example)
 |ERR_print_errors(): if anyone can do that I'd like details and it will be
 |fixed. If ERR_get_error() returns zero it indicates there is no error in

Ok.  I really have a lot of work to do with my thing...

 |the error queue if an application doesn't check for that value
 |and attempts to interpret it as an error code you get the result above...

Sigh.  And then these old codebases that jump around like grazy
from the middle of nowhere.  Amazing how stable all that is with
all the, also thread-safe, third party libaries linked into it,
just like OpenSSL.  But that is not your problem, of course.
Thank you.

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Salz, Rich via RT r...@openssl.org wrote:
 | So you want a separate openssl-conf package.  Fine, then provide it and
 | give an easy mechanism for applications to hook into it.
 | And for users to be able to overwrite system defaults.
 | But this has not that much to do with #3627.
 |
 |Yes it does.  :)  A newer simpler API that does what you want \
 |seems exactly the way forward.  Go for it.

You sound pretty good and done here..  Gratulations.  [Laughter]

Regarding the interface: back in 2011 i have started (only) writing
a Python (grr) script, which had a really simple way of doing
_any_ socket connection via

  class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator

The basic concept was that all you can do is

  def create_connection(serv, cafile=None, all_fingerprints=False):

where serv is a class Service,

  class Service(Config.Section):

that directly maps to a configuration type (shortened by doc)

[service]
uid = UID
url = NAME
proto = proto
port = NUMBER
upgrade-secure = BOOLEAN
fetch-folders = mailbox, another-mailbox, ...
options = protocol-dependend (comma separated list of options)

So wether TLS or not you simply

(err, conn) = SaSo.create_connection(serv)
if err:
return (intro +  'connect failure: ' + err, ESTAT_CONNECTION)
print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT)

_maximally_ extended by (for non-initially secured transport)

# Shall we try to upgrade to TLS (RFC 2595)?
if self.service.upgrade_secure:
resp = self._single('STLS')
if not resp:
self.error_append('\nServer does not seem to support secure ' +
'transport.\nYou need to disable the *upgrade-secure* ' +
'configuration setting.')
return
resp = SaSo.wrap_connection(self.conn)
if resp is not None:
self.error = 'failed to perform *upgrade-secure*: ' + resp
return

Cool, eh?  S-postman.py was that thing.
_That_ is in essence what i mean -- just think about the current
Python urllib is it CVE-2014-9365: not even programmers that know
do it the right way, how can you expect administrators and normal
users to do so, even _if_ the software allows the necessary
configuration.  Nono.

 |I've said that adding new magic keywords is not something \
 |we're going to do, and I've tried to explain the reasoning. \
 | I am sorry that you don't like it.

Despite that i continue to disagree _completely_.
The other way around would be the right way to go for
configuration, and if that doesn't work then the _library_ had to
be adjusted.  E.g. by splitting off a small config update package
that updates cipher lists and whatever (i am really not an expert.
Nor do i plan to become one) without the need to recompile
OpenSSL.  Cool.  But you are not there yet, are you?  :-)
So please please, give us MIN and MAX.
Ciao,
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso]

Dr. Stephen Henson st...@openssl.org wrote:
 |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote:
 | are hard (not only to parse) for users but there is a lot of
 | information for good in very few bytes; sad is
 | 
 |   Received SIGPIPE during IMAP operation
 |   IMAP write error: error::lib(0):func(0):reason(0)
 |
 |OpenSSL itself should never generate that error through (for example)
 |ERR_print_errors(): if anyone can do that I'd like details and it will be
 |fixed. If ERR_get_error() returns zero it indicates there is no error in

Ok.  I really have a lot of work to do with my thing...

 |the error queue if an application doesn't check for that value
 |and attempts to interpret it as an error code you get the result above...

Sigh.  And then these old codebases that jump around like grazy
from the middle of nowhere.  Amazing how stable all that is with
all the, also thread-safe, third party libaries linked into it,
just like OpenSSL.  But that is not your problem, of course.
Thank you.

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Stephen Henson via RT r...@openssl.org wrote:
 |On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote:
 | and finally i propose three new values for the Protocol slot of
 | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 |
 |Just to add my 2p to this thread which seems to have veered into rather
 |different territory...

Please.  Oh yes, i think i have digressed a lot by now.

 |I don't think it's appropriate to have a VULNERABLE option as a protocol
 |selection value partly because vulnerability rarely affects a whole protocol
 |version, just aspects of it. You can (for example) restrict yourself to TLS
 |v1.2 and still do insecure things such as talk to servers \
 |with 512 bit RSA keys
 |or using 256 bit DH parameters.
 |
 |Your request seems closer to the security levels code which \
 |is currently only
 |in the OpenSSL master branch. It will by default reject many \
 |things: including
 |the RSA, DH examples above. An application can increase the \
 |security level to
 |make things stricter (but this will fail for many existing \
 |servers so it isn't
 |the default), disable it completely and handle everything \
 |themselves (which is
 |what previous versions of OpenSSL do) or have finer control using an
 |application specific callback.

Ok, i've never ment to go that much into the details, what i've
also said in the other responses.  Yours is the view of someone
who deeply penetrates the problem for i think way over a decade,
mine is rather restricted to a well-known book, what you hear here
and there plus some manual reading, no more and no less.

On this level SSLv2 is very insecure and so for a very long
time, SSLv3 was insecure and now has made it to the same level
as is predecessor.  After reading the draft linked in a message
of this thread and following some references it seems that i drive
very well with restricting myself (and recommend users that ask)
to TLSv1.2, which i do for well over a year, when i can.  I just
_never_ played with any other setting regarding TLS/SSL, though i
have to admit that i once adjusted a MACs SSH configuration
setting (to be able to connect).

That is all i know -- and _my_ opinion is that if that is not
sufficient, something is wrong.  Because _i_ will _never_
accomplish an intellectual penetration of -- short -- anything
involved to get at a permanently secured encrypted transport.
Just never.  And, when that far, i'm a buddhist, actually i'm even
disgusted of secure transport as such.  Here is all about
reflection, canalisation and transformation, but now i think i'm
really off-topic.  So if that doesn't clash a desire to
intellectually penetrate secure transport then i don't know.  :-)
I'm still hoping for at least (OLDEST/MIN and) NEWEST/MAX.
Ciao,

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Richard Moore richmoor...@gmail.com wrote:
 |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote:
 | and finally i propose three new values for the Protocol slot of
 | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 |
 |In Qt we've added an enum value for TLS versions that is SecureProtocols so
 |that we could remove versions as required without requiring apps to be
 |updated. It's an open question which is more likely to get updated - Qt or
 |the apps of course. For Qt 5.4 which is due out this week we've removed
 |SSL3 from this enum so apps will silently get updated to drop support for
 |it.

I see.  And i think this is the most impressive or, lesser
enthusiastic, important feature of the slow _CONF_ interface: that
users can use strings and that those are directly swallowed by the
OpenSSL library, so that neither recompilation nor understanding
is necessary on the program side in order to upgrade to a new
level of security.
(As a side note: SecureProtocols is such a Volvo wording...
Doesn't vulnerable energises a deeper feeling of insecurity?
I think Hitchcock would have used the naked and bare vulnerable.)
Ciao,

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Richard Moore richmoor...@gmail.com wrote:
 |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote:
 | Richard Moore richmoor...@gmail.com wrote:
 ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org
 | wrote:
 || and finally i propose three new values for the Protocol slot of
 || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 ||
 ||In Qt we've added an enum value for TLS versions that is SecureProtocols
 | so
 ||that we could remove versions as required without requiring apps to be
 ||updated. It's an open question which is more likely to get updated - Qt
 | or
 ||the apps of course. For Qt 5.4 which is due out this week we've removed
 ||SSL3 from this enum so apps will silently get updated to drop support for
 ||it.
 |
 | I see.  And i think this is the most impressive or, lesser
 | enthusiastic, important feature of the slow _CONF_ interface: that
 | users can use strings and that those are directly swallowed by the
 | OpenSSL library, so that neither recompilation nor understanding
 | is necessary on the program side in order to upgrade to a new
 | level of security.
 |
 |The API we offer in Qt isn't tied to openssl so we can't do that. We also
 |support a Windows RT backend and a SecureTransport backend is under
 |development too.

Well, of course.  Implementing a simple fixed-string wrapper isn't
hard to do shall there be desire, however, i've done the mine in
about two hours in 43 lines plus the mapping array and some
testing (a n_strsep() already existed).  And it can be hoped that
other libraries follow with their interfaces, functions like
SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption
SocketProtectionLevel constants are really inflexible and hard to
use.  And result in ugly mail paragraph formatting.  And do
i think most of the time not really describe what is desired (a
secure transport, or SecureProtocols in your QT world).
But not that i wouldn't prefer compile-checks in favour of
intransparent strings.
That makes me think that some prodding by you could possibly get
the ball rolling.  It needn't be _that_ flexible..

 | (As a side note: SecureProtocols is such a Volvo wording...
 | Doesn't vulnerable energises a deeper feeling of insecurity?
 | I think Hitchcock would have used the naked and bare vulnerable.)
 |
 |
 |That's partly due to the API naming conventions for enums. :-)

Yet that only describes the lesser part :)

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Kurt Roeckx via RT r...@openssl.org wrote:
 |On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote:
 | and finally i propose three new values for the Protocol slot of
 | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 |
 |I actually find the option unfortunate and I think it should have
 |been one that sets the minimum and maximum version.  But I think
 |we're too late 1.0.2 process to still change this.

A good benefit for a three line patch.
Being able to say -ALL,=TLSv1.1 etc. is surely on the list of
many, and much more complicated to implement than that.

--steffen


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

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso via RT]

Kurt Roeckx via RT r...@openssl.org wrote:
 |On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
 |   set ssl-protocol=ALL,-SSLv2
 | 
 | This results in the obvious problem that when they (get)
 | upgrade(d) their OpenSSL library they will see a completely
 | intransparent error message that no normal user will understand:
 |
 |It was actually my intention to keep supporting that, but I seem
 |to have removed that line.  I think the following patch should fix
 |that:
 |--- a/ssl/ssl_conf.c
 |+++ b/ssl/ssl_conf.c
 |@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
 |const char *value)
 |static const ssl_flag_tbl ssl_protocol_list[] =
 |{
 |SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
 |+   SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
 |SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
 |SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
 |SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),

Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.

--steffen


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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

 |Kurt Roeckx via RT r...@openssl.org wrote:
 ||been one that sets the minimum and maximum version.  But I think
 ||we're too late 1.0.2 process to still change this.

Attached a git format-patch MBOX for 1.0.2 (on top of [6806b69]).
It boils anything down into two changesets (SSL_CONF_CTX and
pseudo protocols).  Remarks:

  - I've adjusted anything for SSLv2 (in the PODs, as OLDEST, in
VULNERABLE).

  - s_client.pod and s_server.pod did not yet state that they
support the SSL_CONF_CTX arguments, so i've added that (which
s_cb.c seems to support already).

  - make  make test work, rest yet just installed.

Let me know if you want the same for [master] again.
I really hope you do that,
and Ciao from Germany

--steffen



ossl-1_0_2.mbox
Description: application/mbox
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Salz, Rich rs...@akamai.com wrote:
 |I think magic names -- shorthands -- are a very bad idea. \

I _completely_ disagree.

 | They are point-in-time statements whose meaning evolves, \
 |if not erodes, over time.

Because i don't think that a normal user, or even normal
administrators and programmers is and are willing or even capable
to understand what they are doing.
How many people have read all the RFCs that are involved?
And how many people have sufficient knowledge to _really_
understand the mathematical concepts and actual algorithms?

Personally i am willing to put enough trust in the OpenSSL team
*even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE'
and leave the task of deciding what is VULNERABLE up to you.
Imagine that.
I have already implemented the necessary _CONF_ wrapper for
OpenSSL v1.0.1 and it'll gave you a hand (shall the list receive
this message).

--steffen


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

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Steffen Nurpmeso]

Kurt Roeckx via RT r...@openssl.org wrote:
 |On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
 |   set ssl-protocol=ALL,-SSLv2
 | 
 | This results in the obvious problem that when they (get)
 | upgrade(d) their OpenSSL library they will see a completely
 | intransparent error message that no normal user will understand:
 |
 |It was actually my intention to keep supporting that, but I seem
 |to have removed that line.  I think the following patch should fix
 |that:
 |--- a/ssl/ssl_conf.c
 |+++ b/ssl/ssl_conf.c
 |@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
 |const char *value)
 |static const ssl_flag_tbl ssl_protocol_list[] =
 |{
 |SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
 |+   SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
 |SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
 |SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
 |SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),

Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Richard Moore richmoor...@gmail.com wrote:
 |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote:
 | and finally i propose three new values for the Protocol slot of
 | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 |
 |In Qt we've added an enum value for TLS versions that is SecureProtocols so
 |that we could remove versions as required without requiring apps to be
 |updated. It's an open question which is more likely to get updated - Qt or
 |the apps of course. For Qt 5.4 which is due out this week we've removed
 |SSL3 from this enum so apps will silently get updated to drop support for
 |it.

I see.  And i think this is the most impressive or, lesser
enthusiastic, important feature of the slow _CONF_ interface: that
users can use strings and that those are directly swallowed by the
OpenSSL library, so that neither recompilation nor understanding
is necessary on the program side in order to upgrade to a new
level of security.
(As a side note: SecureProtocols is such a Volvo wording...
Doesn't vulnerable energises a deeper feeling of insecurity?
I think Hitchcock would have used the naked and bare vulnerable.)
Ciao,

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

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso]

Richard Moore richmoor...@gmail.com wrote:
 |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote:
 | Richard Moore richmoor...@gmail.com wrote:
 ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org
 | wrote:
 || and finally i propose three new values for the Protocol slot of
 || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.
 ||
 ||In Qt we've added an enum value for TLS versions that is SecureProtocols
 | so
 ||that we could remove versions as required without requiring apps to be
 ||updated. It's an open question which is more likely to get updated - Qt
 | or
 ||the apps of course. For Qt 5.4 which is due out this week we've removed
 ||SSL3 from this enum so apps will silently get updated to drop support for
 ||it.
 |
 | I see.  And i think this is the most impressive or, lesser
 | enthusiastic, important feature of the slow _CONF_ interface: that
 | users can use strings and that those are directly swallowed by the
 | OpenSSL library, so that neither recompilation nor understanding
 | is necessary on the program side in order to upgrade to a new
 | level of security.
 |
 |The API we offer in Qt isn't tied to openssl so we can't do that. We also
 |support a Windows RT backend and a SecureTransport backend is under
 |development too.

Well, of course.  Implementing a simple fixed-string wrapper isn't
hard to do shall there be desire, however, i've done the mine in
about two hours in 43 lines plus the mapping array and some
testing (a n_strsep() already existed).  And it can be hoped that
other libraries follow with their interfaces, functions like
SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption
SocketProtectionLevel constants are really inflexible and hard to
use.  And result in ugly mail paragraph formatting.  And do
i think most of the time not really describe what is desired (a
secure transport, or SecureProtocols in your QT world).
But not that i wouldn't prefer compile-checks in favour of
intransparent strings.
That makes me think that some prodding by you could possibly get
the ball rolling.  It needn't be _that_ flexible..

 | (As a side note: SecureProtocols is such a Volvo wording...
 | Doesn't vulnerable energises a deeper feeling of insecurity?
 | I think Hitchcock would have used the naked and bare vulnerable.)
 |
 |
 |That's partly due to the API naming conventions for enums. :-)

Yet that only describes the lesser part :)

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

[openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]

[Steffen Nurpmeso via RT]

Does:

- Fixes a typo in s_client.pod (2x in the).

- Changes .pod to reflect reality: it is SSL_CONF_CTX_finish(),
  not SSL_CONF_finish().

- While here it seems best to change the remaining SSL_CONF_cmd(),
  SSL_CONF_cmd_argv() and SSL_CONF_cmd_value_type() to have
  a SSL_CONF_CTX_ prefix, too.
  PODs renamed accordingly.

- Adjusts all places where git grep -i matches against the former.

It compiles etc.
It's ugly to have SSL_CONF_CTX_ as a prefix, but isn't it better
to have a unique interface instead of special-treating the _cmd*
stuff?  Would be really nice like that.
- 

--steffen

diff --git a/apps/s_cb.c b/apps/s_cb.c
index f3892f9..7b111fd 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -1553,7 +1553,7 @@ int args_ssl(char ***pargs, int *pargc, SSL_CONF_CTX *cctx,
 	int rv;
 
 	/* Attempt to run SSL configuration command */
-	rv = SSL_CONF_cmd_argv(cctx, pargc, pargs);
+	rv = SSL_CONF_CTX_cmd_argv(cctx, pargc, pargs);
 	/* If parameter not recognised just return */
 	if (rv == 0)
 		return 0;
@@ -1613,7 +1613,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 			return 0;
 			}
 #endif
-		if (SSL_CONF_cmd(cctx, param, value) = 0)
+		if (SSL_CONF_CTX_cmd(cctx, param, value) = 0)
 			{
 			BIO_printf(err, Error with command: \%s %s\\n,
 		param, value ? value : );
@@ -1627,7 +1627,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 	 */
 	if (!no_ecdhe)
 		{
-		if (SSL_CONF_cmd(cctx, -named_curve, P-256) = 0)
+		if (SSL_CONF_CTX_cmd(cctx, -named_curve, P-256) = 0)
 			{
 			BIO_puts(err, Error setting EC curve\n);
 			ERR_print_errors(err);
@@ -1637,7 +1637,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
 #ifndef OPENSSL_NO_JPAKE
 	if (!no_jpake)
 		{
-		if (SSL_CONF_cmd(cctx, -cipher, PSK) = 0)
+		if (SSL_CONF_CTX_cmd(cctx, -cipher, PSK) = 0)
 			{
 			BIO_puts(err, Error setting cipher to PSK\n);
 			ERR_print_errors(err);
diff --git a/demos/bio/client-arg.c b/demos/bio/client-arg.c
index cca7a1e..34035f5 100644
--- a/demos/bio/client-arg.c
+++ b/demos/bio/client-arg.c
@@ -25,7 +25,7 @@ int main(int argc, char **argv)
 		{
 		int rv;
 		/* Parse standard arguments */
-		rv = SSL_CONF_cmd_argv(cctx, nargs, args);
+		rv = SSL_CONF_CTX_cmd_argv(cctx, nargs, args);
 		if (rv == -3)
 			{
 			fprintf(stderr, Missing argument for %s\n, *args);
diff --git a/demos/bio/client-conf.c b/demos/bio/client-conf.c
index 191615a..aec3c7b 100644
--- a/demos/bio/client-conf.c
+++ b/demos/bio/client-conf.c
@@ -47,7 +47,7 @@ int main(int argc, char **argv)
 	for (i = 0; i  sk_CONF_VALUE_num(sect); i++)
 		{
 		cnf = sk_CONF_VALUE_value(sect, i);
-		rv = SSL_CONF_cmd(cctx, cnf-name, cnf-value);
+		rv = SSL_CONF_CTX_cmd(cctx, cnf-name, cnf-value);
 		if (rv  0)
 			continue;
 		if (rv != -2)
diff --git a/demos/bio/server-arg.c b/demos/bio/server-arg.c
index 0d432a4..6ba5cc4 100644
--- a/demos/bio/server-arg.c
+++ b/demos/bio/server-arg.c
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
 		{
 		int rv;
 		/* Parse standard arguments */
-		rv = SSL_CONF_cmd_argv(cctx, nargs, args);
+		rv = SSL_CONF_CTX_cmd_argv(cctx, nargs, args);
 		if (rv == -3)
 			{
 			fprintf(stderr, Missing argument for %s\n, *args);
diff --git a/demos/bio/server-conf.c b/demos/bio/server-conf.c
index 0d940f0..f19b5b8 100644
--- a/demos/bio/server-conf.c
+++ b/demos/bio/server-conf.c
@@ -62,7 +62,7 @@ int main(int argc, char *argv[])
 		{
 		int rv;
 		cnf = sk_CONF_VALUE_value(sect, i);
-		rv = SSL_CONF_cmd(cctx, cnf-name, cnf-value);
+		rv = SSL_CONF_CTX_cmd(cctx, cnf-name, cnf-value);
 		if (rv  0)
 			continue;
 		if (rv != -2)
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 17308b4..ff61825 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -90,7 +90,7 @@ SSL servers.
 
 In addition to the options below the Bs_client utility also supports the
 common and client only options documented in the
-in the LSSL_CONF_cmd(3)|SSL_CONF_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
+LSSL_CONF_CTX_cmd(3)|SSL_CONF_CTX_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
 manual page.
 
 =over 4
diff --git a/doc/apps/s_server.pod b/doc/apps/s_server.pod
index 1cc965f..616de1d 100644
--- a/doc/apps/s_server.pod
+++ b/doc/apps/s_server.pod
@@ -98,8 +98,8 @@ for connections on a given port using SSL/TLS.
 
 In addition to the options below the Bs_server utility also supports the
 common and server only options documented in the
-LSSL_CONF_cmd(3)|SSL_CONF_cmd(3)/SUPPORTED COMMAND LINE COMMANDS manual
-page.
+LSSL_CONF_CTX_cmd(3)|SSL_CONF_CTX_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
+manual page.
 
 =over 4
 
diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
new file mode 100644
index 000..ccc3dd5
--- /dev/null
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -0,0 +1,442 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_cmd - send configuration command
+
+=head1 SYNOPSIS
+
+ #include openssl/ssl.h
+
+ int SSL_CONF_CTX_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value);
+ int 

Re: [openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]

[Steffen Nurpmeso via RT]

Oh yes: and on top of that former patch there really where also
dangling SSL_CTX_cmd() use cases in .pod files, which are thus and
finally changed to SSL_CONF_CTX_cmd via the attached patch, too.
Thank you.

--steffen

diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
index ccc3dd5..b6aa600 100644
--- a/doc/ssl/SSL_CONF_CTX_cmd.pod
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -351,26 +351,26 @@ however the call sequence is:
 SSLv2 is Balways disabled and attempt to override this by the user are
 ignored.
 
-By checking the return code of SSL_CTX_cmd() it is possible to query if a
-given Bcmd is recognised, this is useful is SSL_CTX_cmd() values are
+By checking the return code of SSL_CONF_CTX_cmd() it is possible to query if
+a given Bcmd is recognised, this is useful is SSL_CONF_CTX_cmd() values are
 mixed with additional application specific operations.
 
-For example an application might call SSL_CTX_cmd() and if it returns
+For example an application might call SSL_CONF_CTX_cmd() and if it returns
 -2 (unrecognised command) continue with processing of application specific
 commands.
 
-Applications can also use SSL_CTX_cmd() to process command lines though the
-utility function SSL_CTX_cmd_argv() is normally used instead. One way
-to do this is to set the prefix to an appropriate value using
+Applications can also use SSL_CONF_CTX_cmd() to process command lines though
+the utility function SSL_CONF_CTX_cmd_argv() is normally used instead.
+One way to do this is to set the prefix to an appropriate value using
 SSL_CONF_CTX_set1_prefix(), pass the current argument to Bcmd and the
 following argument to Bvalue (which may be NULL).
 
 In this case if the return value is positive then it is used to skip that
-number of arguments as they have been processed by SSL_CTX_cmd(). If -2 is
-returned then Bcmd is not recognised and application specific arguments
-can be checked instead. If -3 is returned a required argument is missing
-and an error is indicated. If 0 is returned some other error occurred and
-this can be reported back to the user.
+number of arguments as they have been processed by SSL_CONF_CTX_cmd().
+If -2 is returned then Bcmd is not recognised and application specific
+arguments can be checked instead. If -3 is returned a required argument is
+missing and an error is indicated. If 0 is returned some other error occurred
+and this can be reported back to the user.
 
 The function SSL_CONF_CTX_cmd_value_type() can be used by applications to 
 check for the existence of a command or to perform additional syntax
diff --git a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
index cdd952e..2e9c728 100644
--- a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
+++ b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod
@@ -17,7 +17,7 @@ to Bprefix. If Bprefix is BNULL it is restored to the default value.
 
 =head1 NOTES
 
-Command prefixes alter the commands recognised by subsequent SSL_CTX_cmd()
+Command prefixes alter the commands recognised by subsequent SSL_CONF_CTX_cmd()
 calls. For example for files, if the prefix SSL is set then command names
 such as SSLProtocol, SSLOptions etc. are recognised instead of Protocol
 and Options. Similarly for command lines if the prefix is --ssl- then 
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX

[Steffen Nurpmeso via RT]

Hello,

and finally i propose three new values for the Protocol slot of
SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE.

I included OLDEST for completeness sake, NEWEST is in effect what
i've always forced for my thing whenever possible, and encouraged
users to use themselve, but of course it was pretty inflexible
before the advent of NEWEST.  :)

I think VULNERABLE is a good thing to have despite it's
humiliating name, because it could be used to automatically secure
users by simply updating the OpenSSL library, effectively giving
the option to obsolete insecure protocols faster than what was
possible in the past, and of course: only possibly so.
But anyway: in my opinion it would be a real security improvement
if users could either use -ALL,NEWEST, or, shall that not be
possible, ALL,-VULNERABLE, rather in the spirit configure once
and forget, but stay secure.  Or something along these lines.

Find attached a patch that does this and can be applied on top of
the other two patches i've send regarding SSL_CONF_CTX.
Notes:

  - Readds a dummy SSLv2 value (thus includes a patch for the
other issue i've opened).

  - Fixes some whitespace-at-eol issues of the .pod.

Thanks and ciao.

P.S.: i plan to release a new minor of my thing before the
christian christmas feast, it would be _really_ great to know what
the OpenSSL thinks regarding the function renaming and these new
values, since i'm switching over to the new SSL_CONF_CTX interface
and am implementing a wrapper unless HAVE_OPENSSL_CONF_CTX becomes
omnipresent.
Thank you.

--steffen

diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
index b6aa600..4e8b67c 100644
--- a/doc/ssl/SSL_CONF_CTX_cmd.pod
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -74,7 +74,7 @@ Bprime256v1). Curve names are case sensitive.
 
 =item B-named_curve
 
-This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+This sets the temporary curve used for ephemeral ECDH modes. Only used by
 servers
 
 The Bvalue argument is a curve name or the special value Bauto which
@@ -85,7 +85,7 @@ can be either the BNIST name (e.g. BP-256) or an OpenSSL OID name
 =item B-cipher
 
 Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is
-currently not performed unless a BSSL or BSSL_CTX structure is 
+currently not performed unless a BSSL or BSSL_CTX structure is
 associated with Bcctx.
 
 =item B-cert
@@ -111,7 +111,7 @@ operations are permitted.
 
 =item B-no_ssl3, B-no_tls1, B-no_tls1_1, B-no_tls1_2
 
-Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 
+Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2
 by setting the corresponding options BSSL_OP_NO_SSL3,
 BSSL_OP_NO_TLS1, BSSL_OP_NO_TLS1_1 and BSSL_OP_NO_TLS1_2 respectively.
 
@@ -177,7 +177,7 @@ Note: the command prefix (if set) alters the recognised Bcmd values.
 =item BCipherString
 
 Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is
-currently not performed unless an BSSL or BSSL_CTX structure is 
+currently not performed unless an BSSL or BSSL_CTX structure is
 associated with Bcctx.
 
 =item BCertificate
@@ -244,7 +244,7 @@ Bprime256v1). Curve names are case sensitive.
 
 =item BECDHParameters
 
-This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+This sets the temporary curve used for ephemeral ECDH modes. Only used by
 servers
 
 The Bvalue argument is a curve name or the special value BAutomatic which
@@ -259,9 +259,17 @@ The supported versions of the SSL or TLS protocol.
 The Bvalue argument is a comma separated list of supported protocols to
 enable or disable. If an protocol is preceded by B- that version is disabled.
 All versions are enabled by default, though applications may choose to
-explicitly disable some. Currently supported protocol values are 
-BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2. The special value BALL refers
-to all supported versions.
+explicitly disable some.
+Currently supported protocol values are
+BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2.
+
+Some special values are understood:
+BALL refers to all supported versions,
+BNEWEST will always refer to the newest of the supported protocols,
+currently BTLSv1.2,
+BOLDEST refers to the oldest supported protocol, currently BSSLv3,
+and BVULNERABLE includes all protocols which have known vulnerabilities
+(in the default configuration).
 
 =item BOptions
 
@@ -339,16 +347,16 @@ The value is a directory name.
 The order of operations is significant. This can be used to set either defaults
 or values which cannot be overridden. For example if an application calls:
 
- SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv2);
+ SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv3);
  SSL_CONF_CTX_cmd(ctx, userparam, uservalue);
 
-it will disable SSLv2 support by default but the user can override it. If 
+it will disable SSLv3 support by default but the user can override it. If
 however the call sequence is:
 
  SSL_CONF_CTX_cmd(ctx, userparam, uservalue);
- SSL_CONF_CTX_cmd(ctx, 

Re: [PATCH] Add API to set minimum and maximum protocol version.

[Steffen Nurpmeso]

 |What is the SECLEVEL you refer to?  I had a quick look at SSL_CONF API
 |pointed out by Stephen.[.]

 |

I did too.  Attached a doc patch (against 1.0.2) to match code
reality.  Fixes linking for me.

--steffen
diff --git a/doc/ssl/SSL_CONF_cmd.pod b/doc/ssl/SSL_CONF_cmd.pod
index 6d073cb..67ab043 100644
--- a/doc/ssl/SSL_CONF_cmd.pod
+++ b/doc/ssl/SSL_CONF_cmd.pod
@@ -10,7 +10,7 @@ SSL_CONF_cmd - send configuration command
 
  int SSL_CONF_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value);
  int SSL_CONF_cmd_value_type(SSL_CONF_CTX *cctx, const char *cmd);
- int SSL_CONF_finish(SSL_CONF_CTX *cctx);
+ int SSL_CONF_CTX_finish(SSL_CONF_CTX *cctx);
 
 =head1 DESCRIPTION
 
@@ -21,7 +21,7 @@ framework for command line options or configuration files.
 
 SSL_CONF_cmd_value_type() returns the type of value that Bcmd refers to.
 
-The function SSL_CONF_finish() must be called after all configuration
+The function SSL_CONF_CTX_finish() must be called after all configuration
 operations have been completed. It is used to finalise any operations
 or to process defaults.
 
@@ -416,7 +416,7 @@ error occurred attempting to perform the operation: for example due to an
 error in the syntax of Bvalue in this case the error queue may provide
 additional information.
 
-SSL_CONF_finish() returns 1 for success and 0 for failure.
+SSL_CONF_CTX_finish() returns 1 for success and 0 for failure.
 
 =head1 SEE ALSO
 

Re: [PATCH] Add API to set minimum and maximum protocol version.

[Steffen Nurpmeso]

Hello,

Dr. Stephen Henson st...@openssl.org wrote:
 |On Thu, Dec 04, 2014, Tomas Hoger wrote:
 | On Wed, 3 Dec 2014 22:55:06 +0100 Kurt Roeckx wrote:
 | Maybe applications may benefit from an API where they can pass string
 | set by the end user and let OpenSSL parse version number from that.
 | If mod_ssl had configuration directives as SSLProtocolMin and
 | SSLProtocolMax, it could e.g. use the following while used with OpenSSL
 | 1.0.0:

 | 

 |This can already be done in the SSL_CONF API for OpenSSL 1.0.2+. Apache
 |httpd (and hopefully other applicacations at some point) includes support
 |so we'd just need to add a new command value.

Until now programs use SSL_CTX_set_options() to perform necessary
adjustments.  And as far as i know OpenSSL doesn't support a way
to extend the following from my thing so that i could offer users
the possibility to say newest, e.g.,
a SSL_OP_NO_NOTHING_BUT_NEWEST:

 {auto, SSL_OP_NO_SSLv2},
  #ifndef OPENSSL_NO_TLS1
  # ifdef TLS1_2_VERSION
 {tls1.2, SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1 |
SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
  # endif
  # ifdef TLS1_1_VERSION
 {tls1.1, SSL_OP_NO_TLSv1 | SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
  # endif
 {tls1, SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
  #endif
  #ifndef OPENSSL_NO_SSL3
 {ssl3, SSL_OP_NO_SSLv2},
  #endif
  #ifndef OPENSSL_NO_SSL2
 {ssl2, 0},
  #endif

so that they only would need to update their OpenSSL library
and restart the application in order to automatically restrict
themselve to the newest protocol only?
Btw. i just recently changed this table from

   static struct ssl_method const   _ssl_methods[] = {
  -   {auto, SSLv23_client_method},
  -#define _SSL_DEFAULT_METHOD  SSLv23_client_method
  +   {auto, SSL_OP_NO_SSLv2},
   #ifndef OPENSSL_NO_TLS1
   # ifdef TLS1_2_VERSION
  -   {tls1.2, TLSv1_2_client_method},
  +   {tls1.2, SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1 |
  +  SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
   # endif
   # ifdef TLS1_1_VERSION
  -   {tls1.1, TLSv1_1_client_method},
  +   {tls1.1, SSL_OP_NO_TLSv1 | SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
   # endif
  -   {tls1, TLSv1_client_method},
  +   {tls1, SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2},
   #endif
   #ifndef OPENSSL_NO_SSL3
  -   {ssl3, SSLv3_client_method},
  +   {ssl3, SSL_OP_NO_SSLv2},
   #endif
   #ifndef OPENSSL_NO_SSL2
  -   {ssl2, SSLv2_client_method}
  +   {ssl2, 0},
   #endif
   };

which i think changed its semantics, so great that something in
this area happens.  But a dynamic approach would be really great
(like also, say, only the newest or the one before that but only
if that has no known security traps in the meanwhile, naively
spoken).

(Btw., i hope that TLS v1.2 is still secure, Google disclassifies
applications which connect via this protocol so that lesssecure
has to be chosen from their web interface.)

Thanks a lot again, and ciao from Germany,

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

Re: Could ASN1_TIME_print() become documented?

[Steffen Nurpmeso]

i wrote:
 |until now when i printed certificate chains (in verbose mode)
 |i used a brute simple hand driven function that dealt with
 |ASN1_UTCTIME.  Today i connected to a server where one of the
 |certificates in the chain used ASN1_GENERALIZEDTIME, which
 |resulted in the -- faulty -- message:
 |
 |  notBefore = 2020-09-03 03:12:54 GMT
 |  notAfter = Bogus certificate date: 20240303125425Z

this btw. not only affects my little MUA btw. (it at least prints
something useful then).

 |So i gave up on this and am now using the undocumented (at least
 |in regular documentation) ASN1_TIME_print(), which (sic) goes
 |through a BIO:

Since the function was in it since 0.9.1c that should be ok?
Like the thing that is attached.
And if you would be really kind then you could also get the simple
script which does extract and expand it.  I.e., i remember the
thread on improving the doc -- storing the documentation nearby
the functions which implement a functionality (or their prototypes,
but that is not an option for OpenSSL) is surely a step into the
right direction.

--steffen
diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c
index 111ea5a..ef4b1d8 100644
--- a/crypto/asn1/t_x509.c
+++ b/crypto/asn1/t_x509.c
@@ -386,6 +386,26 @@ int ASN1_STRING_print(BIO *bp, const ASN1_STRING *v)
 	return(1);
 	}
 
+/*@=
+ * @man ASN1_TIME_print.3ssl
+ * @group NAME ASN1_TIME_print -- ASN1 time output routine
+ *
+ * @group SYNOPSIS
+ *
+ * @syn #include openssl/asn1.h
+ * @sp
+ * @fun int ASN1_TIME_print(BIO *bp, const ASN1_TIME *tm);
+ *
+ * @group DESCRIPTION
+ *
+ * This function prints the BASN1_TIME structure Bbp to the BBIO Btm,
+ * or Bad time value if Btm is not a valid, or does not represent a valid
+ * BASN1_TIME.
+ *
+ * @group RETURN VALUES
+ *
+ * Upon success the value B1 is returned, B0 otherwise.
+ */
 int ASN1_TIME_print(BIO *bp, const ASN1_TIME *tm)
 {
 	if(tm-type == V_ASN1_UTCTIME) return ASN1_UTCTIME_print(bp, tm);

Re: Could ASN1_TIME_print() become documented?

[Steffen Nurpmeso]

Salz, Rich rs...@akamai.com wrote:
 |Please send this to r...@openssl.org so it doesn't get lost.

Nah, that is quite ridiculuous, is it; i read this as it is fine
to use the function, though.
Thanks,

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

Could ASN1_TIME_print() become documented?

[Steffen Nurpmeso]

Hello,

until now when i printed certificate chains (in verbose mode)
i used a brute simple hand driven function that dealt with
ASN1_UTCTIME.  Today i connected to a server where one of the
certificates in the chain used ASN1_GENERALIZEDTIME, which
resulted in the -- faulty -- message:

  notBefore = 2020-09-03 03:12:54 GMT
  notAfter = Bogus certificate date: 20240303125425Z

So i gave up on this and am now using the undocumented (at least
in regular documentation) ASN1_TIME_print(), which (sic) goes
through a BIO:

  notBefore = Mar  3 12:54:25 2009 GMT
  notAfter = Mar  3 12:54:25 2024 GMT

I'd prefer ISO 8601, but.. here we go.
And what would be so wrong with making asn1_XX_to_tm() public?
Thanks,

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

Re: OpenSSL version 1.0.1g released

[Steffen Nurpmeso]

OpenSSL open...@openssl.org wrote:
 |   OpenSSL version 1.0.1g released
 |   ===

Forgot to git(1) tag OpenSSL_1_0_1g?

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