On Tue 2016-02-02 14:08:18 -0500, Rich Salz via RT wrote:
> any chance you can refresh your 1.0.2 patch? I'm interested in being able to
> accept the common names but not changing the output for compatibility..
I am too :)
it looks like it was already merged, though, as
On Mon 2016-02-01 18:46:20 -0500, Viktor Dukhovni wrote:
> On Mon, Feb 01, 2016 at 11:38:49PM +, Alex Rousskov via RT wrote:
>
>> On 02/01/2016 02:32 PM, openssl-dev@openssl.org via RT wrote:
>>
>> > Please be more explicit about what errors you feel were not reported.
>>
>> One specific
On Tue 2016-01-26 16:37:58 -0500, Salz, Rich wrote:
> TFO is interesting because it lets UDP-style attacks happen at the TCP
> level. Normally you can't do a TCP attack unless you have a valid
> client IP address.
>
> Imagine connecting once and then sending the syncookie to the botnet.
This
On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote:
> I am currently running Ubuntu with Mysql and am unable to connect via an ssl
> connection to the database getting following error.
>
> error 2026 (hy000): ssl connection error: protocol version mismatch
>
> My installation details are
A couple places in the OpenSSL documentation claims that SSL_foo()
takes an SSL_CTX* instead of an SSL*. i've corrected those here.
---
doc/ssl/SSL_CTX_set1_verify_cert_store.pod | 8
doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
The documentation asserts that BIO_new_mem_buf is forced to a
read-only state ("The BIO is set to a read only state and as a result
cannot be written to"), but it requires passing in a void*. This
makes it hard to use from a function that has a const buffer.
Presumably most code that tries to
On Tue 2015-05-26 14:56:10 -0400, Short, Todd via RT wrote:
This is a change that Akamai has made to its implementation of OpenSSL.
Version: master branch
Description: Add DISALLOW_RENEGOTIATION option
Add support to disallow renegotiation in openssl
The bit definition may need to change
On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote:
On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
Apologies if this is the incorrect forum for this question.
We’re
seeing error messages like SSL3_READ_BYTES and
SSL3_GET_SERVER_CERTIFICATE for some reason;
-
On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote:
OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test
certificate and its CA cert that illustrate the problem are attached, as well
as the patch/workaround).
Here’s how the problem manifests itself:
$
On 12/10/2014 12:59 PM, Salz, Rich via RT 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.
On Mon 2014-05-12 15:18:35 -0400, Daniel Kahn Gillmor via RT wrote:
I'm happy that the PFS key exchange normalization changesets have been
merged into master.
I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
stable branch to add similar aliasing for the library input
On 07/16/2014 03:39 AM, Tomas Mraz via RT wrote:
What about just supporting float number argument for -days (0.5 for 12
hours certificate validity)? That should be fairly simple. In the first
step. And add something like -notafter argument that would specify the
exact end datetime in the ISO
On 07/16/2014 09:40 AM, Salz, Rich wrote:
But then it has to be supported for, like ever. :)
do you realistically think we'll ever drop support for the -days
argument though? Dropping -days would break a million scripts.
Extending it to support a non-integer number of days seems like a
On 07/16/2014 11:24 AM, Salz, Rich wrote:
do you realistically think we'll ever drop support for the -days argument
though? Dropping -days would break a million scripts.
No, we'll never drop support for -days. But whether the code is atoi() or
atof() is a big difference and might cause
On 07/15/2014 07:58 AM, Salz, Rich via RT wrote:
The Globus syntax is strange. :)
We should support the ISO date/time standard, and use that throughout and not
invent yet another syntax, or yet another flag. It's fairly simple to parse,
and handles timezones, relative times, date/time
On 07/13/2014 06:33 PM, Matt Caswell via RT wrote:
I propose the following patch to deal with this ticket (for master, 1.0.2 and
1.0.1), i.e. disable XTS for the enc utility.
Any objections?
Matt
diff --git a/apps/enc.c b/apps/enc.c
index 928d16b..48f1f8b 100644
--- a/apps/enc.c
+++
On 06/30/2014 05:14 PM, Rich Salz via RT wrote:
It's not immediately obvious, but enforcement of the keyUsage and other
attributes is something the relying party has to do. Anything else means just
trusting the signer, and that is not secure; how do you konw the signer is not
cheating?
I
i'm just forwarding this followup message to the relevant bug report so
that it stays tracked with it.
--dkg
Reading at previous post of Mr. Seth Schoen about using 40 bits RC2 for
the smime utility, it comes to my mind that PKCS12_create() also default
to RC2, even when OpenSSl is
I'm happy that the PFS key exchange normalization changesets haveb been
merged into master.
I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
stable branch to add similar aliasing for the library input strings. This
provides forward compatibility with any documentation
defined(@array) is deprecated at ./util/mkerr.pl line 792.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at ./util/mkerr.pl line 800.
(Maybe you should just omit the defined()?)
---
util/mkerr.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This is a hard-coded patch to make OpenSSL clients reject connections
which use DHE handshakes with 1024 bits.
This patch has no compile-time or runtime configurability. If the
project wants something more nuanced, we need discussion about what
the right form(s) of configurability should be.
On 03/13/2014 05:52 PM, Stephen Henson via RT wrote:
I should've commented on this before, sorry. I'm currently working on a
framework where several security parameters can be configured at both compile
time and runtime, including DH parameter sizes. It's still under development
at
present
Hi Stephen--
On Thu 2014-01-02 16:36:39 -0500, Stephen Henson via RT wrote:
On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote:
I don't mean to be impatient -- if it's just a matter of playing catchup
over the close of the winter holiday, i can wait :)
Yes that's pretty much it. I'll
On 01/02/2014 03:32 PM, Ben Laurie wrote:
On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
On 01/01/2014 12:48 PM, Ben Laurie wrote:
Pull requests on Github are quite useful - that way they also get
tracked (so long as we remember to close them when applied, that
On 01/01/2014 12:48 PM, Ben Laurie wrote:
Pull requests on Github are quite useful - that way they also get
tracked (so long as we remember to close them when applied, that is!).
OK, i've rebased the series against the current master, and submitted a
github-specific pull request:
Hi Stephen--
On Fri 2013-12-20 13:51:06 -0500, Stephen Henson via RT wrote:
I've pulled the update now, thanks.
Any update on this change? I don't see the patches as having been
included in the master branch of https://github.com/openssl/openssl yet.
Is there any other information, review, or
The relevant RFCs and other implementations refer to Diffie-Hellman
ephemeral key exchange as DHE (and its elliptic curve variant as
ECDHE). OpenSSL uses this terminology in some places, but it also
uses EDH and EECDH in others. This confusion makes selecting
these key exchange mechanisms harder
On 12/20/2013 01:51 PM, Stephen Henson via RT wrote:
I've pulled the update now, thanks.
great!
Well I have to admit to being far from a git expert. For me it's best if it's
easy to get the patches with commit messages and authorship somewhere I can
review them. If I manually have to apply
Reject connections to TLS servers that select DH key exchange but
offer a weak DH group.
---
ssl/s3_clnt.c | 6 ++
ssl/ssl.h | 1 +
ssl/ssl_err.c | 1 +
3 files changed, 8 insertions(+)
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index bf1ef47..ef638c4 100644
--- a/ssl/s3_clnt.c
+++
Somehow, both SSL_R_NO_PEM_EXTENSIONS and
SSL_R_INVALID_SERVERINFO_DATA were assigned reason code 389.
This patch uses the next available number (393) for
SSL_R_NO_PEM_EXTENSIONS to disambiguate the two reason codes.
---
ssl/ssl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Without these changes, running util/mkerr.pl on modern perl (5.18.1)
produces the following deprecation warnings:
defined(@array) is deprecated at util/mkerr.pl line 792.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at util/mkerr.pl line 800.
(Maybe
The synopsis had the wrong parameter types and an extra (unused)
function pointer declaration.
The demo dhparam filenames should all end in .pem.
---
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
See on-list discussion starting with 20131029180341.ga31...@openssl.org
---
doc/ssl/SSL_CTX_add_extra_chain_cert.pod | 4
1 file changed, 4 insertions(+)
diff --git a/doc/ssl/SSL_CTX_add_extra_chain_cert.pod
b/doc/ssl/SSL_CTX_add_extra_chain_cert.pod
index 11b3b4b..7782623 100644
---
The current default openssl.cnf appears to have default_bits = 1024:
http://cvs.openssl.org/fileview?f=openssl/apps/openssl.cnfv=1.23.4.6
however, NIST has recommended avoiding reliance on 1024-bit RSA keys
after 2010.
See pages 63-66 of:
for openssl enc, -salt appears to be the default but the
documentation claims -nosalt is the default.
reading enc(1ssl):
-salt
use a salt in the key derivation routines. This option should
ALWAYS be used unless compatibility with previous versions of
OpenSSL or
35 matches
Mail list logo
