Re: [openssl-dev] [openssl.org #4607] improve quietness for s_client ... also documentation for s_client + s_server

[John Denker via RT]

On 07/05/2016 02:42 PM, Rich Salz via RT wrote:
> this is for 1.0.2, right?

:; openssl version
OpenSSL 1.1.0-pre6-dev

:; git log
commit c2d551c01930df54bce6517cfecd214db6e98e80
Date:   Wed Apr 27 14:47:45 2016 +0100


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4607
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 #4607] improve quietness for s_client ... also documentation for s_client + s_server

[John Denker via RT]

Hi --

Attached are four simple patches.
They make the apps more usable.
They should be pretty much self-explanatory.
Let me know if you have questions.

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

>From 07ff5a786d6d06774688404c2dedf86097d449d4 Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Tue, 5 Jul 2016 08:49:10 -0700
Subject: [PATCH 1/4] make s_client more quiet when -quiet is specified

---
 apps/s_client.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index e79cf7e..0391581 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -2331,7 +2331,7 @@ int s_client_main(int argc, char **argv)
 if (c_brief)
 BIO_puts(bio_err, "CONNECTION CLOSED BY SERVER\n");
 else
-BIO_printf(bio_err, "read:errno=%d\n", ret);
+if (ret || !c_quiet) BIO_printf(bio_err, "read:errno=%d\n", ret);
 goto shut;
 case SSL_ERROR_ZERO_RETURN:
 BIO_printf(bio_c_out, "closed\n");
@@ -2377,7 +2377,7 @@ int s_client_main(int argc, char **argv)
 at_eof = 1;
 
 if ((!c_ign_eof) && ((i <= 0) || (cbuf[0] == 'Q' && cmdletters))) {
-BIO_printf(bio_err, "DONE\n");
+if (!c_quiet) BIO_printf(bio_err, "DONE.\n");
 ret = 0;
 goto shut;
 }
-- 
2.7.4

>From e6d642aba8281fb57afd637a87b8dd982f27e988 Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Tue, 5 Jul 2016 08:50:58 -0700
Subject: [PATCH 2/4] when a write to stdout has failed, sending a message to
 stdout is pointless, so let's send it to stderr instead; also let's send a
 more informative message

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

diff --git a/apps/s_client.c b/apps/s_client.c
index 0391581..504e729 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -2269,7 +2269,9 @@ int s_client_main(int argc, char **argv)
 i = raw_write_stdout(&(sbuf[sbuf_off]), sbuf_len);
 
 if (i <= 0) {
-BIO_printf(bio_c_out, "DONE\n");
+/* typical failure is broken pipe */
+BIO_printf(bio_err, "s_client.c: write to stdout failed (%d): %s\n",
+i, strerror(errno));
 ret = 0;
 goto shut;
 /* goto end; */
-- 
2.7.4

>From 59272ed9b51263a165866637ff993382ad8d2bfc Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Tue, 5 Jul 2016 09:09:37 -0700
Subject: [PATCH 3/4] document the -verify_quiet option to s_client

---
 apps/s_client.c   |  6 --
 doc/apps/s_client.pod | 10 --
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 504e729..b0ad2a0 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -611,7 +611,8 @@ OPTIONS s_client_options[] = {
 {"nbio_test", OPT_NBIO_TEST, '-', "More ssl protocol testing"},
 {"state", OPT_STATE, '-', "Print the ssl states"},
 {"crlf", OPT_CRLF, '-', "Convert LF from terminal into CRLF"},
-{"quiet", OPT_QUIET, '-', "No s_client output"},
+{"quiet", OPT_QUIET, '-',
+  "Do not print session and certificate info.  See also -verify_quiet"},
 {"ign_eof", OPT_IGN_EOF, '-', "Ignore input eof (default when -quiet)"},
 {"no_ign_eof", OPT_NO_IGN_EOF, '-', "Don't ignore input eof"},
 {"starttls", OPT_STARTTLS, 's',
@@ -635,7 +636,8 @@ OPTIONS s_client_options[] = {
 {"CRLform", OPT_CRLFORM, 'F', "CRL format (PEM or DER) PEM is default"},
 {"verify_return_error", OPT_VERIFY_RET_ERROR, '-',
  "Close connection on verification error"},
-{"verify_quiet", OPT_VERIFY_QUIET, '-', "Restrict verify output to errors"},
+{"verify_quiet", OPT_VERIFY_QUIET, '-',
+  "Restrict verify output to errors.  See also -quiet"},
 {"brief", OPT_BRIEF, '-',
  "Restrict output to brief summary of connection parameters"},
 {"prexit", OPT_PREXIT, '-',
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 77668ea..205d057 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -63,6 +63,7 @@ B B
 [B<-ign_eof>]
 [B<-no_ign_eof>]
 [B<-quiet>]
+[B<-verify_quiet>]
 [B<-ssl3>]
 [B<-tls1>]
 [B<-tls1_1>]
@@ -298,8 +299,13 @@ input.
 
 =item B<-quiet>
 
-inhibit printing of session and certificate information.  This implicitly
-turns on B<-ign_eof> as well.
+inhibit printing (on stdout) of session and certificate information.  This
+implicitly turns on B<-ign_eof> as well.  See also B<-verify_quiet>.
+
+=item B<-verify_quiet>
+
+inhibit printing (on stderr) of information from low-level verify routines.
+See also B<-quiet>.
 
 =item B<-no_ign_eof>
 
-- 
2.7.4

>From 07852c4e65e99bdb501992c39a0a5f5f21549362 Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Tue, 5 Jul 2016 10:31:01 -0700
Subject: [PATCH 4/4] document the -verif

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[John Denker via RT]

Here's a set of obvious questions:
  -- What is the current design?
   Is there a concise-and-complete statement somewhere?
  -- What are the design constraints?
   What is it that openssl MUST do?
   What is it that openssl MUST NOT do?
  -- What information is available?
  -- What critical information is not available,
   and why not?

I mention this because I read things like "deprecated"
and "working as designed" ... referring to the same
features AFAICT.  Also I read "the best one can do,
absent additional information" and it makes me wonder.

In particular, at some point one could consider
changing the design to obtain additional info.  For
starters, one could imagine an interface that says
in effect:
  int isOK = this_site_sent_me_this_webPKI_cert(sitename, cert, ...);

The point is that when this interface is used, we don't
need to worry about CN="Joe Bloggs" s/mime issues.  We
know it's supposed to be a webPKI cert and anything else
MUST be rejected.
  -- For that matter, in this context, nowadays the CN 
   SHOULD be ignored completely in favor of SANs.
  -- Especially when there are nameConstraints or other
   v3 features in the cert, I would suggest the CN MUST
   be ignored in favor of SANs.
  ++ More generally, the interface should demand whatever
   information is needed in order to make an intelligent
   decision.

==

As a sidelight, not important but amusing, one might wonder:
What is it supposed to mean when a name-constrained CA issues
a CN="Joe Bloggs" certificate?  Why would anyone want to rely
on such a cert?  Before we decide this is working as designed,
it might be nice to take a close look at the design.

In any case, I would suggest that the s/mime tail should not
be allowed to wag the webPKI dog.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
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 #3502] nameConstraints bypass bug

[John Denker via RT]

On 05/30/2016 08:58 PM, Viktor Dukhovni wrote:

> Name constraints in the X.509v3 PKI have not worked well, and are
> rarely used.  The attack requires a issuing CA to be willing to
> issue certificates beyond its constraints, that would be quite
> noticeable and rather unwise.  So I think this is not a major
> problem.  We should probably make a reasonable effort to address
> this, but the urgency is I think low.

The priority may be higher than that, because of something
that has not yet been mentioned in this discussion:

  The nameConstraints protect the issuing CA, not just
  the relying parties.

Here's the scenario:  I persuade 1000 of my closest friends
to accept my mumble.com CA as a trusted root.  I offer them
the assurance that:
  The root cert is name-constrained, and therefore affects
  only their interactions with *.mumble.com, so it's
  not very dangerous. [1]

The first problem is that if openssl does not implement
nameConstraints properly, my assertion [1] is false.

This leads to a second problem:  My cert-issuing machine
becomes a much juicier target.  If anybody pwns my machine,
then /every/ cert-based activity of /every one/ of my friends
is compromised, via the nameConstraints bypass bug.

The problem does not revolve around me intentionally doing
something unwise;  it involves a bad guy stealing from me
and then doing something nasty.

So it seems the priority / prevalence argument is at best
circular:  People would use the feature a lot more if they
could trust it to do the right thing.

As Fred Smith once said, you don't judge the importance or
the optimal size of the proposed bridge according to the
number of people seen driving across the river before the
bridge is built.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
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 #3502] nameConstraints bypass bug

[John Denker via RT]

I'm glad to see some discussion of this issue.
Note that other implementations treated this as
a bug and fixed it a long time ago.

On 05/30/2016 11:56 AM, Rich Salz wrote:

> WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

Well, maybe that is the Right Answer™

I'm not sure what "deprecated" and "mandated" mean in
the openssl context.  If openssl actually de-implemented
CN-as-hostname and actually mandated SAN, that would
solve the nameConstraints bypass bug in grand style.

> Leaving this open because we might be able to do some hueristics/hacks to
> determine when the CN "should be" a DNS name.

How about this for a heuristic:  If nameConstraints are
in effect, then the validator MUST NOT accept the CN as
a DNS name.  This seems like the least the validator
could do, in light of the aforementioned deprecation.

This seems unlikely to generate false alarms, since any
issuer who uses nameConstraints should be savvy enough 
to not rely on CN-as-hostname to the exclusion of SANs.

  Optionally a CN that satisfies the nameConstraints could
  be tolerated, insofar as it is deprecated but harmless.

>  But the workaround is to use SAN.

That workaround is not specific enough to solve the 
security problem.  Note the contrast:
 -- As it stands, good guys are /allowed/ to use SAN.
 -- The problem is not solved until bad guys are
  /required/ to use SAN;
 ... or more to the point, required to not use anything
  but SAN;
 ... or even more to the point, required to not use
  anything that bypasses the nameConstraints.

The crucial word there is "required".


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
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 #3960] make install fails with --prefix=./relative-path

[John Denker via RT]

Scenario:
  :; git clone https://github.com/openssl/openssl openssl-temp
  :; cd openssl-temp
  :; ./config --prefix=./relpath
  :; make
  :; make install
  [spewage snipped]

  created directory `./relpath'
  Cannot create directory ./relpath/.: File exists
  Makefile:669: recipe for target 'install_docs' failed
  make: *** [install_docs] Error 17

Discussion:

It could be argued that an implicit relative path of the
form --prefix=usr is probably a user error, i.e. a typo
in lieu of --prefix=/usr.  However, if you think it 
should be treated as an error, it should be caught at 
./config time ... rather than waiting until the middle 
of the install process.  Also, there should be some
meaningful, helpful error message, rather than "file 
exists".

Furthermore, an explicit relative path (i.e. one with 
a leading "./" or "../" in it) is probably not a user
error.  The expected and desired behavior is that it
should just work.

  If for some reason this cannot work, it should be
  caught at ./config time.  A meaningful, helpful
  error message should be given.

___
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.org #3771] patch: bug: s_client loop at 100% cpu

[John Denker via RT]

Comment reformatted to comply with new OpenSSL coding style chapter 8
  https://www.openssl.org/about/codingstyle.txt

Functionality unchanged from previous patch.



>From 9e896a7a0f1ae28ab32c025ae2a5730aa7343c6a Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Sat, 4 Apr 2015 16:36:51 -0700
Subject: [PATCH] fix CPU-hogging loop; don't try to read when EoF already seen

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

diff --git a/apps/s_client.c b/apps/s_client.c
index ec11617..0d41318 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -729,6 +729,7 @@ int MAIN(int argc, char **argv)
 int crl_download = 0;
 STACK_OF(X509_CRL) *crls = NULL;
 int sdebug = 0;
+int tty_at_EoF = 0;
 
 meth = SSLv23_client_method();
 
@@ -1719,7 +1720,14 @@ int MAIN(int argc, char **argv)
 if (!ssl_pending) {
 #if !defined(OPENSSL_SYS_WINDOWS) && !defined(OPENSSL_SYS_MSDOS) && !defined(OPENSSL_SYS_NETWARE)
 if (tty_on) {
-if (read_tty)
+/*-
+ * Note that select() returns whenever a read _would not block_
+ * and being at EoF satisfies this criterion ...
+ * even though a read after EoF is not interesting to us
+ * and would cause a CPU-hogging loop.
+ * Hence the factor of tty_at_EoF here.
+ */
+if (read_tty && !tty_at_EoF)
 openssl_fdset(fileno(stdin), &readfds);
 if (write_tty)
 openssl_fdset(fileno(stdout), &writefds);
@@ -1977,6 +1985,8 @@ int MAIN(int argc, char **argv)
 } else
 i = raw_read_stdin(cbuf, BUFSIZZ);
 
+if (i == 0) tty_at_EoF = 1;
+
 if ((!c_ign_eof) && ((i <= 0) || (cbuf[0] == 'Q'))) {
 BIO_printf(bio_err, "DONE\n");
 ret = 0;
-- 
2.1.0

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

Re: [openssl-dev] [openssl.org #3771] patch: bug: s_client loop at 100% cpu

[John Denker via RT]

The attached patch makes the problem go away.

The method of solution is simple and obvious.


>From 92e824e2cfa02ecfc41b78e91acdd5ac0a845c17 Mon Sep 17 00:00:00 2001
From: John Denker 
Date: Sat, 4 Apr 2015 16:36:51 -0700
Subject: [PATCH] fix CPU-hogging loop; don't try to read when EoF already seen

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

diff --git a/apps/s_client.c b/apps/s_client.c
index ec11617..775420a 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -729,6 +729,7 @@ int MAIN(int argc, char **argv)
 int crl_download = 0;
 STACK_OF(X509_CRL) *crls = NULL;
 int sdebug = 0;
+int tty_at_EoF = 0;
 
 meth = SSLv23_client_method();
 
@@ -1719,7 +1720,12 @@ int MAIN(int argc, char **argv)
 if (!ssl_pending) {
 #if !defined(OPENSSL_SYS_WINDOWS) && !defined(OPENSSL_SYS_MSDOS) && !defined(OPENSSL_SYS_NETWARE)
 if (tty_on) {
-if (read_tty)
+/* Note that select() returns whenever a read _would not block_ */
+/* and being at EoF satisfies this criterion ...*/
+/* even though a read after EoF is not interesting to us*/
+/* and would cause a CPU-hogging loop.  */
+/* Hence the factor of tty_at_EoF here. */
+if (read_tty && !tty_at_EoF)
 openssl_fdset(fileno(stdin), &readfds);
 if (write_tty)
 openssl_fdset(fileno(stdout), &writefds);
@@ -1977,6 +1983,8 @@ int MAIN(int argc, char **argv)
 } else
 i = raw_read_stdin(cbuf, BUFSIZZ);
 
+if (i == 0) tty_at_EoF = 1;
+
 if ((!c_ign_eof) && ((i <= 0) || (cbuf[0] == 'Q'))) {
 BIO_printf(bio_err, "DONE\n");
 ret = 0;
-- 
2.1.0

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

[openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu

[John Denker via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Contrast the following two examples:

#1:
time : | openssl s_client -connect www.openssl.org:443  >& /dev/null

real0m0.545s
user0m0.000s
sys 0m0.000s

#2:
time : | openssl s_client -quiet -connect www.openssl.org:443  >& /dev/null

real0m21.255s
user0m9.500s
sys 0m11.180s

- ---

Note the numerology:   21.225 - 9.5 - 11.18 =  0.545
That means that if you discount the half second it takes to actually
fetch the certificate, s_client was using 100% of the cpu the whole
time ... for more than 20 seconds.

I cannot imagine why it loops when "-quiet" is specified and not
otherwise.  I cannot imagine why it loops for 20.5 seconds instead
of 20.5 minutes or 20.5 hours.

This is 100% reproducible chez moi, although the timings naturally
vary by a little bit.


(gdb) where
#0  0x77903653 in __select_nocancel () at 
../sysdeps/unix/syscall-template.S:81
#1  0x00434d73 in s_client_main (argc=0, argv=0x7fffe680) at 
s_client.c:1794
#2  0x004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffe660) 
at openssl.c:470
#3  0x004035b8 in main (Argc=4, Argv=0x7fffe660) at openssl.c:366


openssl version
OpenSSL 1.1.0-dev xx XXX   (latest github version)

Same symptoms observed in older versions:
openssl version
OpenSSL 1.0.1f 6 Jan 2014

uname -a
Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 
x86_64 GNU/Linux

=

Obvious workaround:  Don't specify the "-quiet" option.  There are
other ways of dealing with the unwanted prolixity.

Priority: low.  Compared to actual security problems such as the 
nameconstraints bypass bug [openssl.org #3502] this is nothing.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVRg/GPO9SFghczXtAQJfwxAAzbmfw1gCJYNCoxgI0kVX1davQ2tqq9Pv
eC5rVzyrh3+ii/PlvgojjOi9KR4o/nOUoy7CzVKTyidG5PTM1J8nNrCrl2H48vic
iv6fNVsLxcibPGs7+De2SqZkiJXl2JvgCZuLACljxq39SrKK0SpNKWqM8DyQrnes
3Mfim3vEcPMHj5lrFTWvVP/tT+/aslW1WGHLuh5kh9KHLBoQQCH2kenVD4Rrxz+F
pa5PjRVf7rPQEfaFWKBZ2WLwStelp1ZriJN1TxEXPqWqZsWlUnKwJUhZZaAnBdUt
z4Vj9MhgQDPMnyWDy8sVb/5BAyiMoTL6/DJfm949tn3rsef6UHtCu3iHg+GRDTVP
AQ6I8TmGnQMpXGTQnmLA5fyHrmGlSbcdmcSDQaIA1noKuWyORT4/CBNMftt+A5gV
MuWrSdZg4/l1Tkon4712v3yucg9r2WSMbz5hEGxw99MVd7Kk27OHfSYrDowYvjKC
vwBtABvXTmsR387pkcTDpuRU8Ayk/OXM1cbkuK7Vsadr2sfcwvi6iuL02NVDITwQ
XyksioIKPf76pXJt5aUOwjnVdRN0XN67LdHSSBZlmjEImUYQxswmZDuWZbdm/ECr
5Ahxeij8wkNZUKDCMCa2HScbQGlx9YveI+jDs2m5pB40lDcSWTqm+FmHtCVImi++
0atbpVOZanc=
=oaVD
-END PGP SIGNATURE-


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

Re: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch

[John Denker via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/31/2014 10:31 AM, Rich Salz via RT wrote:

> This patch from Steve Henson seems better

I am happy with the proposed patch.  I have looked at
the code, and also tested it operationally.

The semantics is reasonable.
 ++ This is what I was arguing for initially.
 ++ It is AFAICT consistent with Mozilla behavior.
 ++ It is more strict than pk11-kit (lynx) behavior;
  see below for details.

>  and a good candidate for 1.0.2 and master...

OK, good, the sooner the better.

This is a "security issue" in the sense that is a Type-II
error (disallowing good guys).  It affects thousands of 
sites and who-knows-how-many users.

  It is not a Type-I error (letting bad guys in) and it
  affects "only" thousands of sites, not millions, so it
  is not in the same category as heartbleed ... but still
  it is well worth fixing, the sooner the better.

*** It would make sense to fix the nameConstraints bypass bug
*** [openssl.org #3502] at the same time.
*** Otherwise the whole nameConstraints concept is pretty much
*** pointless.   http://rt.openssl.org/Ticket/Display.html?id=3502

- --

Test results:

The Henson patch does what it is supposed to:
   :| $newopenssl s_client -verify 10 -CAfile 
/usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
  -connect auth.edu.gr:443  |& egrep 'Verify'
Verify return code: 0 (ok)

For more detailed checks, we can use the following signing CA:

  wget http://www.av8n.com/pdq-root-ca-cert.pem
  echo 5d9f030c791bcace3580f38286a49c4f  /tmp/pdq-root-ca-cert.pem | md5sum -c -

Here is another example of the patch allowing stuff, as it should:
  :| $newopenssl s_client -verify 10 -CAfile pdq-root-ca-cert.pem  -connect 
www.pdq.av8n.com:1446 |& egrep 'Verify'
Verify return code: 0 (ok)

Here it is disallowing some things, as it should:
A rule with a leading dot does /not/ match a domain name without
a corresponding dot:
   :| $newopenssl s_client -verify 10 -CAfile pdq-root-ca-cert.pem  -connect 
pdq.av8n.com:1445 |& egrep 'Verify'
Verify return code: 47 (permitted subtree violation)

In contrast, note that pk11-kit is more tolerant, and totally ignores 
the leading dot:
  SSL_CERT_FILE=pdq-root-ca-cert.pem  lynx -source 
https://pdq.av8n.com:1445/cgi-bin/ipaddr

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVKV8H/O9SFghczXtAQIQIBAAiBsPoCiRqzKqZpE4hNmefyWaFlLagVQ0
Abhw5tBFCULwjGE5f4VlAil/1dNVro3Qlp7yvZ8qIXKkvJ3hk9gO6rUId6hP74Qy
xtAiBvs4az+IpxImQ91RRnw+ZYtf9IghKNSQyPkBDVpNMtlr7zr/OTe6ksgH0/h6
HhfKs7YuZ7RkCHmPjL7qDzFSfMxoFQSIXDguBFTrOrLmeOv7XG3O3ZvKnpcH/79M
DcxhUATvzzXyoYN9mtkbgw4W13Gcl0ds8S/zeFuencH2UvBVYPBZl/UTDf2stwya
wvizplcopgQikTd/p1D+5GnfaBUzRS2YopY77GQIokca0pLq/uO5XRBx/l8jQidX
i0KGvVWRsP1Oud0yJ/Ba8pMwunJwkzWpcvoV1kk1copm/KuZwZGb4k2PpQTLGBsG
czbRvHm5FbCRE7WDxGpO3GjtqcWZpY5kMlxUe8/yhnTvYQrcXgf7pUChBouS6Un9
GHq1uLGymIP6OtqzIpd0NSR2Fo1JU28mCGJs6gN+r7QtL5FoKpRo+16UrfHvBSt5
D1KuGjOCEb7JSxjsGIVaGK/lFQjMBksqG8MXj4xUR3UB7udj8tjBfxF1X3/rFk9M
fvkhMqw2zh8CvzzvIe3URy5t4rVooZ0Alwk7Q9imN4gI7tt8HrSadB5pwsTjfe0E
p3Sg79BLMM4=
=fbFv
-END PGP SIGNATURE-


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

[openssl.org #3562] leading dots in nameConstraints ... bug report and patch

[John Denker via RT]

This bug report and patch concern the way openssl responds to CA 
certificates that have leading dots in the nameConstraints lists.
Thousands of certificates of this type are in use, issued by the 
HARICA_2011 CA and perhaps others.  Given that both Mozilla and 
Ubuntu ship HARICA_2011 as a trusted root CA, this is not a trivial 
matter.

This issue applies to root CAs and intermediate CAs alike.

Point of comparison:  pk11-kit tolerates leading dots:
lynx -source -head https://www.auth.gr/ |& head -1
HTTP/1.1 200 OK

Similarly:  Mozilla NSS tolerates leading dots:
firefox https://www.auth.gr/

Furthermore, virtually all of the user-oriented instructions 
found on the web today call for the use of leading dots.  The 
instructions suggest the dots are mandatory, although in fact 
they are not;  both pk11-kit and Mozilla NSS tolerate the dotted 
and dotless forms equally.

Observed openssl behavior, alas:
wget  https://www.auth.gr/ -O /dev/null |& tail -2
  permitted subtree violation
To connect to www.auth.gr insecurely, use `--no-check-certificate'.

Similarly, alas:
curl https://www.auth.gr/ |& grep curl:
curl: (60) SSL certificate problem: permitted subtree violation

Similarly, alas:
:| openssl s_client -verify 10 -CApath /etc/ssl/certs -connect 
www.auth.gr:443 |&  grep Verify.return.code
Verify return code: 47 (permitted subtree violation)

Desired behavior:  Openssl should tolerate constraint items with
and without leading dots, just like NSS and pk11-kit do.
 :| fixed/openssl s_client -verify 10 -CApath /etc/ssl/certs -connect 
www.auth.gr:443 |&  grep Verify.return.code
Verify return code: 0 (ok)


Short of patching openssl, no reasonable workaround for this problem
has been found.  Less-than-reasonable options include:
 ☠ Re-issuing thousands of certificates.  This would be prohibitively
  disruptive and expensive.
 ☠ Rewriting all applications to use pk11-kit instead of openssl.

A patch is available:  https://www.av8n.com/openssl/leading-dot.diff
The patch applies to openssl-1.0.1i.

Priority:  The bug as it stands is a denial-of-service for anybody 
who wants to use openssl in connection with thousands of already-issued 
certs.

   There is probably not much point in fixing this unless we also
   fix the nameConstraints bypass bug, i.e. [openssl.org #3502]

The security risk associated with applying the patch is exceedingly
small.  It's a very minor change to the code.  It makes the code in
some ways better and in no ways worse.  The semantics of the leading-
dot form is not seriously open to question.

The counterargument that the RFC does not require us to tolerate
leading dots is bogus.  The way I read it, the RFC does require it.
  http://www.rfc-editor.org/rfc/rfc5280.txt   (page 40)
Furthermore, common sense requires it and certainly the RFC does
not forbid it.  Besides, RFCs are not gospel anyway.  This RFC
has already been patched to fix horrific errors.

At one point there was talk of treating the leading-dot forms
differently from the dotless forms, but this suggestion has
been withdrawn.

Additional info:  To test the dotless form, to make sure it 
continues to work:
wget http://www.av8n.com/av8n.com_Dotless_Root_CA.pem
echo 00453924426f1cbb69c0ea9b62d8f2fd  av8n.com_Dotless_Root_CA.pem | 
md5sum -c -
 :| openssl s_client -verify 10 -CAfile av8n.com_Dotless_Root_CA.pem  
-connect dotless.av8n.com:1443 |& grep Verify.return.code
Verify return code: 0 (ok)

Also: To see the structure of the HARICA-2011 CA certificate, 
including the leading dots:
openssl x509 -text -noout -in 
/usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt

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

Re: [openssl.org #3502] effective_names function --> smarter way to fix bypass bug

[John Denker via RT]

Hi Folks --

I figured out a smarter way to fix the bypass bug ...
and potentially make some other things better at the 
same time.

The idea is to create a structured reference that returns
a stack containing the relevant effective name(s) of a
given x509 certificate.  This means there's a lot of
code -- in various places -- that no longer needs
to know or care whether the name(s) come from the 
subjectAltName list or from the common name.

The new function is called from the code that checks
nameConstraints, but it could usefully be called from
elsewhere.  In particular, the 'curl' application has
about 100 lines of code that could almost all be
replaced by a call to the effective_names function.

A first draft of some code to do this can be found at
  https://www.av8n.com/openssl/effective-names.diff

Beware that I don't have much experience programming
in the openssl environment, so somebody should check
this code pretty carefully.  I'm calling functions
that aren't terribly well documented, so I had to do
a lot of reasoning by analogy.



There is an associated patch
  https://www.av8n.com/openssl/const-get-subject-name.diff
that adds a few 'const' declarations.

I reckon 'const' declarations can't hurt and might help.
 


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

Re: [openssl.org #3502] nameConstraints bypass bug: a fix, or some approximation thereto

[John Denker via RT]

On 08/22/2014 12:26 PM, Salz, Rich wrote:
> It'd be good to fix this.

Behold a patch that seems to fix it:
  https://www.av8n.com/openssl/bypass-bugfix.diff

The code seems pretty straightforward to me, but on the
other hand, I have very little experience coding in the
openssl environment, so I might be overlooking something.
Somebody should check this pretty closely.

A simple way to exhibit the bug (and the fix) as follows:

Desired behavior:
  openssl verify -CAfile av8n-root-ca-cert.pem bypass.jdenker.com-cert.pem
  bypass.jdenker.com-cert.pem: C = US, CN = bypass.jdenker.com
  error 47 at 0 depth lookup:permitted subtree violation

Observed (unfixed) behavior:
  openssl verify -CAfile av8n-root-ca-cert.pem bypass.jdenker.com-cert.pem
  bypass.jdenker.com-cert.pem: OK
which is a security lapse.

The demonstration certs can be found at:
  https://www.av8n.com/openssl/av8n-root-ca-cert.pem
  https://www.av8n.com/openssl/bypass.jdenker.com-cert.pem


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

[openssl.org #3502] nameConstraints bypass bug

[John Denker via RT]

At present, it is pathetically easy to trick openssl into
bypassing nameConstraints.  All you need to do is put 
some evil DNS name in the common name and not provide 
any subjectAltName list.

  I checked;  this bug is present in openssl-1.0.1i;
  openssl s_client happily connects to bypass.jdenker.com
  in defiance of my CA's nameConstraints.  This affects
  widely-used apps including curl, lynx, and wget, although
  I only checked them as of 1.0.1f.

  If you want a live demonstration, try the following:
   wget http://www.av8n.com/av8n.com_Root_CA.pem
   echo bde600da763f4105ceb64913d0ed5838 av8n.com_Root_CA.pem | md5sum -c -
   SSL_CERT_FILE=av8n.com_Root_CA.pem curl 
https://bypass.jdenker.com:444/hello.txt
  Observed behavior:  Command succeeds, prints "Hello, world!"
  Desired behavior:  Should fail, due to violation of nameConstraints.
  Similarly, the following succeeds, but should not:
:| openssl s_client -CAfile av8n-root-ca-cert.pem -connect 
bypass.jdenker.com:444
  Compare and contrast:  firefox properly complains; see below.
  Also compare:  The following succeeds, as it should:
SSL_CERT_FILE=av8n.com_Root_CA.pem curl https://cloud.av8n.com/hello.txt

  If anybody is interested, I can provide the config files
  that generate the certificates in question.

You can easily find additional discussion of this bug;
  https://www.google.com/search?q=x509+%22name+constraints%22+bypass
leads to
  http://www.openwall.com/lists/oss-security/2013/08/12/4



Note that in contrast, the bypass bug has been fixed in 
Mozilla NSS.
 https://bugzilla.mozilla.org/show_bug.cgi?id=394919

When I try the bypass trick on firefox 31.0, it throws 
an appropriate error.

>>> firefox https://bypass.jdenker.com:444/hello.txt

> Secure Connection Failed
>
> An error occurred during a connection to bypass.jdenker.com:444
> The Certifying Authority for this certificate is not permitted 
> to issue a certificate with this name.
>
> (Error code: sec_error_cert_not_in_name_space) 

The user is not even given the option of continuing past 
the error.  So evidently this is considered more serious 
than a run-of-the-mill problem with an unrecognized issuer.

===

Additional discussion of why this is important has already
been posted to the openssl-dev list; see
  http://marc.info/?l=openssl-dev&m=140873436313689&w=2

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