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 i
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 07ff5a786d6d0677
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 cri
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
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
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 'insta
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
Subj
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 se
-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
real
-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
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
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
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 mi
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.jdenke
14 matches
Mail list logo
