Re: [openssl-dev] Speck Cipher Integration with OpenSSL

On Tue 2018-01-09 18:41:25 -0800, William Bathurst wrote: > [ dkg wrote: ] >> My understanding is that the algorithm designers and primary advocates >> have not been particularly forthcoming with their design goals, and >> their reputation is mixed, at best. > > Simon and Speck has been in the

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

Hi Bill-- On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote: > We have open sourced our work in regards to integrating the Speck Cipher > with OpenSSL. Basic information about this cipher can be found here. > > https://en.wikipedia.org/wiki/Speck_(cipher) >

Re: [openssl-dev] X509_cmp_time (possible) bug

On Mon 2017-09-11 14:16:11 +, Short, Todd via openssl-dev wrote: > Yes, it’s annoying, but it’s historic. I looked into changing this at one > point. I think Dimitry's point was that the documentation doesn't match the implementation because of the flexibility of strcmp's defined return

Re: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch

On Wed 2016-06-15 09:51:37 -0400, Salz, Rich wrote: > I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed. > Matt and I disagree :) Isn't the existence of SSLv2 a bug? ;) --dkg -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Out-of-tree build?

On Fri 2016-06-10 06:27:30 -0400, Richard Levitte wrote: > 'make clean' doesn't remove everything (it doesn't remove stuff > produced by Configure), 'git clean -dfx' removes the last vestiges. > > It's possible that we'd do well with a 'make distclean' yes, please! For systems that build from

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

On Fri 2016-02-26 18:04:43 +0100, Viktor Dukhovni wrote: > I'd like to propose a policy of no bug fixes to undocumented public > interfaces. If the interface is useful enough to fix, it has to be > documented. fwiw, i agree with Viktor on this proposal. Clear, sane

Re: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

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

Re: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE

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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

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

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

On Mon 2016-01-25 13:51:11 -0500, Viktor Dukhovni wrote: > On Mon, Jan 25, 2016 at 06:42:02PM +, Kurt Roeckx via RT wrote: > >> On Mon, Jan 25, 2016 at 06:24:55PM +, Sara Dickinson via RT wrote: >> > I would like to request that support be added to OpenSSL to enable >> > client

Re: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection.

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

Re: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection.

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

[openssl-dev] [openssl.org #4192] [PATCH] differentiate SSL_* from from SSL_CTX_* in documentation

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(-)

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: > The simplest approach is to remove ciphersuites from the SSL/TLS > code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), > but leave the underlying crypto in the library. > > Similarly, one might remove algorithms from

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote: > This is very difficult, because most applications use libcrypto > algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname() > and so on. So the code will link, but there'll be runtime errors > due to missing ciphers or

[openssl-dev] [openssl.org #4129] [PATCH] Can BIO_new_mem_buf take a const void* instead of a void* ?

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

Re: [openssl-dev] State machine rewrite

On Fri 2015-09-11 11:07:27 -0400, John Foley wrote: > It's great to see improvements in the state machine along with > consolidated handlers for TLS/DTLS. Agreed. Thanks for the work on this, Matt! > Having said that, have you considered using a state transition table > instead of long switch

Re: [openssl-dev] Mailman version used by OpenSSL is misconfigured and/or broken in relation to DKIM

On Wed 2015-08-05 17:04:30 -0400, Jonas Maebe wrote: On 05/08/15 23:00, mancha wrote: OpenSSL is certainly not alone in its practice of mangling headers and adding body footers so I'd be curious to hear how other lists handle domains such as yahoo.com. We warn people that DKIM-using domains

Re: [openssl-dev] ssl_sess.c : compilation error

On Sun 2015-06-07 16:16:24 -0400, Kurt Roeckx wrote: You can set a callback on the creation of a new session. See the SSL_CTX_sess_set_new_cb() manpage. The SSL_CTX_sess_get_new_cb() get function returns that callback function back. There are no internal users in OpenSSL as far as I can

Re: [openssl-dev] F5 termination of TCP connection

On Mon 2015-06-01 07:36:01 -0400, Krzysztof Kwiatkowski wrote: Yes, that's exactly what we do in our configuration. We have 24 servers with rather high workload. SSL is offloaded on F5 load balancer and servers behind load balancers receive decrypted traffic. I'm not aware of any

Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found

On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Do not complain if config file not found Remove warning when OpenSSL config file can't be found Github link:

Re: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option

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

Re: [openssl-dev] Using TLSv1.2

On Tue 2015-03-24 10:47:57 -0400, Андрей Даровских wrote: I use the openssl library in the project and use client certificate verification. When using protocol TLSv1.2 I have a problem with data encryption, using the private key of the client certificate. This is due to the fact that the

Re: [openssl-dev] removing compression?

On Fri 2015-04-03 15:53:59 -0400, Salz, Rich wrote: I am thinking about removing compression and would like to know what the community thinks. At a minimum, I am going to remove the ability to add compression at run-time. This was never really documented. Moving forward, if someone wants to

[openssl-dev] .txt files on https://openssl.org/ need Content-Type: text/plain; charset=utf-8

Thanks for the release today! This is a trivial bug report, but i figure I noticed that the advisory uses UTF-8, but it is being served with an unadorned Content-Type: text/plain header: $ (wget -O- -q -S https://openssl.org/news/secadv_20150319.txt | file -) 21 | egrep 'stdin|Content-Type'

Re: [openssl-dev] [openssl.org #3728] Question: does sslv3 in log mean we're using SSLv3?

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; -

Re: [openssl-dev] [openssl.org #3728] Question: does sslv3 in log mean we're using SSLv3?

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; -

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

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

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

On Tue 2015-02-10 19:22:44 -0500, Salz, Rich wrote: currently, this is an error: 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER bash: !NO-SUCH-CIPHER: event not found 0 dkg@alice:~$ Yeah, but that's coming from bash, not openssl :) ; openssl ciphers -v ALL | wc 111 675

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

On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW yes, please! Anything that was

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote: On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote: On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote: On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote: On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(),

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

On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote: 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

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

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

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

On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote: 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

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

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: $

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

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: $

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

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.

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

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.

Re: [PATCH] User can choose the public exponent in genrsa

On 11/14/2014 07:47 AM, Quentin Gouchet wrote: The user can call RSA key generation and specify the public exponent exp in a hexadecimal format. Example: openssl genrsa -choose 72bdf -out key.pem 4096 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com This is an

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

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

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

On 09/02/2014 03:34 PM, Salz, Rich wrote: I think there's interest for 1.0.1 and beyond. But I thought we already had a similar alias mechanism? With the version of openssl 1.0.1i that i have in front of me, openssl ciphers EDH succeeds, but openssl ciphers DHE fails. So i don't think the

Re: openssl 1.0.1i ignores ciphers in cipherlist

On 08/29/2014 08:16 AM, Tomas Mraz wrote: On Pá, 2014-08-29 at 16:19 +0200, Frank Meier wrote: While testing different ciphersuites I found a quite drastic change in the behavior between openssl version 1.0.1h to 1.0.1i. While using a cipherlist like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h

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

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

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

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

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

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

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

On 07/17/2014 12:03 AM, Viktor Dukhovni wrote: You've declared -days to take only positive numbers, it should allow negative numbers. why? Or at least: why accept these generally unacceptable options by default? I can understand wanting to be able to create perverse certificates to test

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

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

Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

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 +++

Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve

On 07/11/2014 09:22 AM, balaji marisetti wrote: @Kyle Hamilton So should all the new programs stick to the idiom or check for -1 return code? If you care about the functionality of your program, you should always check return codes (this is not an OpenSSL specific answer). for functions that

Re: [openssl.org #1210] Bug: CRL and Certificates

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

Re: Using same SSL certificat​e for Apache and socketio web server for same applicatio​n

On 05/28/2014 01:08 AM, Deepak wrote: I am writing an in house application where my main web server is apache web server hosting the main web portal which is being accessed by HTTPS. On one of the webpage I am establishing the connection to the socketio based server using HTTPS again but

Re: Using same SSL certificat​e for Apache and socketio web server for same applicatio​n

On 05/28/2014 11:47 AM, Deepak wrote: Thanks for looking in. There are no issues with permission or path. This is starting to look like it might be an issue for socketio or python stdlib folks (which provides the python ssl module), not OpenSSL. but looking a bit deeper:

[openssl.org #3357] Fwd: PKCS12_create() default to RC2 even if compiled with -no-rc2

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

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

On 05/12/2014 03:18 PM, Daniel Kahn Gillmor via RT wrote: 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

naming inconsistency between 3DES-EDE-CBC and DES-CBC3 [Fwd: Re: [TLS] The risk of misconfiguration]

Hi OpenSSL folks-- In the message below, James Cloos points out that the OpenSSL ciphersuite string labels are not consistent with the grouping shorthand for DES and 3DES. This seems similar to the situation for DHE (EDH) and ECDHE (EECDH), which were known with incompatible/inconsistent terms

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

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

Re: [RFC PATCH] s_client/s_server: support unix domain sockets

On 05/06/2014 10:34 PM, Geoff Thorpe wrote: The -unix path argument allows s_server and s_client to use a unix domain socket in the filesystem instead of IPv4 (-connect, -port, -accept, etc). If s_server exits gracefully, such as when -naccept is used and the requested number of SSL/TLS

Re: Start Contributing

On 04/23/2014 04:52 PM, Matt Caswell wrote: I am actively seeking people to help out on the OpenSSL Wiki. Documentation is an area where OpenSSL has frequently been criticized in the past and is an area where we can do something about it NOW. fwiw, i actually don't think that a wiki is going

Re: Improving OpenSSL documentation

On 04/23/2014 09:50 PM, Viktor Dukhovni wrote: On Wed, Apr 23, 2014 at 07:21:23PM -0400, Daniel Kahn Gillmor wrote: A serious way to fix this is to have the documentation produced *from* the code, so that it gets upgraded in sync. For example, neither x509(1ssl) nor openssl x509 -help ever

Re: SSL vs. SSH in the context of CVE 2014-0160

On 04/08/2014 11:08 PM, Chris Hill wrote: SSH and SSL/TLS are simply different protocols (doh). They may share some similar underlying crypto implementations, but as of their respective RFCs, they are just different protocols. The TLS Heartbeat TLS extension would not apply to SSH. The above

Re: [openssl.org #3288] openssl 1.1 - X509_check_host is wrong and insufficient

On 03/30/2014 03:39 PM, Viktor Dukhovni wrote: On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote: - probably useful: while no RFC currently forbids something like *.com you have a check to disallow wildcards in the two rightmost suffixes. I think it makes sense to

[openssl.org #3280] [PATCH] avoid perl deprecation warnings when updating error codes

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(-)

[PATCH] [openssl.org #3120] Reject DHE groups with 1024-bits

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.

Re: Filter short DH key sizes?

04b8b7fbc84d1a28a43a86288d5216d794110a5e Author: Daniel Kahn Gillmor d...@fifthhorseman.net Date: Thu Mar 13 13:23:50 2014 -0400 Reject DHE groups with 1024-bits This is a hard-coded patch without any compile-time or runtime configurability. If the project wants something more nuanced, we need discussion

Re: Filter short DH key sizes?

On 03/13/2014 04:05 PM, Kurt Roeckx wrote: On Thu, Mar 13, 2014 at 03:13:01PM -0400, Daniel Kahn Gillmor wrote: In theory, users of OpenSSL as a TLS client are already able to query the size of the DH key exchange for any given connection, and can choose to terminate it if they object

Re: [openssl.org #3120] Minimum size of DH

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

Re: Diffie Hellman question

On 02/11/2014 09:19 AM, Leon Brits wrote: In a test I have three DH key pairs generated from the IKE groups 14,15 and 16 paramters. [...] It seems the private key must be the same or larger to succeed. Is this correct: Can the public key not be larger than the private key? There shouldn't

Re: Requirements/Steps to add serpent to openssl

On 02/10/2014 08:35 AM, Dmitry Belyavsky wrote: Could you explain what is serpent and what do you want from addition serpent to openssl? I suspect that Shady is asking for the Serpent block cipher, which was one of the AES finalists: https://en.wikipedia.org/wiki/Serpent_%28cipher%29 You

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

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

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

On 01/19/2014 11:40 AM, Dr. Stephen Henson wrote: On Sun, Jan 19, 2014, Daniel Kahn Gillmor via RT wrote: This is a ping to see if there is anything holding up the patchsets for normalizing PFS key exchange labels on the master branch. If there's anything that seems wrong with the series

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

me know what next steps would be most helpful. Regards, --dkg From 3bb46e4bd4fa718131ad994bfad001626a5f79f2 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor d...@fifthhorseman.net Date: Thu, 19 Dec 2013 13:18:30 -0500 Subject: [PATCH] Allow ECDHE and DHE as forward-compatible aliases

Re: [openssl.org #3236] support for DNSSEC in openssl

On 01/13/2014 11:26 AM, Elmar Stellnberger via RT wrote: Webkit browsers and many other openssl based programs like ssh would already like to make use of DNSSEC. AFAIK DNSSEC has already been standardized and would therefore be free to be implemented by openssl. DNSSEC could overcome many

Re: OpenSSL version 1.0.1f released

On 01/06/2014 09:49 AM, OpenSSL wrote: OpenSSL version 1.0.1f released === [...] The OpenSSL project team is pleased to announce the release of version 1.0.1f of our open source toolkit for SSL/TLS. For details of changes and known issues see the

Re: Safe ECC curves

On 01/02/2014 12:35 PM, Dr. Stephen Henson wrote: That's just TLS. To add more complete support to OpenSSL including storing private keys in PEM files and public keys in case we ever use it in ECDH certificates it needs an OID and some details on how the keys are encoded. But ECDHE doesn't

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

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

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

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

Re: Safe ECC curves

On 01/01/2014 03:45 PM, Kurt Roeckx wrote: Hi, I recently ran into this: http://safecurves.cr.yp.to/ It seems that openssl doesn't support any of the curves that are listed there as safe. At least the curve 25519 is popular and has a draft for using it in TLS. Would it be possible to

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

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:

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

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:

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

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

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

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

Normalize PFS key exchange labels

This set of patches normalizes the terminology for Perfect Forward Secrecy key exchange within OpenSSL to the terms used by standards bodies and other implementations, while keeping backward compatibility for existing configurations and other inputs. The relevant RFCs and other implementations

[PATCH 08/10] change SSL3_CK_EDH_* to SSL_CK_DHE_* (with backward-compatibility)

This change normalizes the SSL_CK_DHE_ #defines to use the common term DHE, while permitting older code that uses the more uncommon EDH constants to compile properly. --- ssl/s3_lib.c | 12 ++-- ssl/ssl3.h | 18 -- 2 files changed, 18 insertions(+), 12 deletions(-) diff

[PATCH 01/10] Allow ECDHE as a synonym of EECDH when specifiying ciphers

The standard terminology in https://tools.ietf.org/html/rfc4492 is ECDHE. openssl ciphers outputs ECDHE. But users of the library currently cannot specify ECDHE, they must specify EECDH. This change allows users to specify the common term in cipher suite strings without breaking backward

[PATCH 10/10] update remaining documentation to move from EDH to DHE

change documentation and comments to indicate that we prefer the standard DHE naming scheme everywhere over the older EDH --- doc/apps/ciphers.pod| 24 doc/ssl/SSL_CIPHER_get_name.pod | 4 ++-- doc/ssleay.txt | 12 ++-- ssl/tls1.h

[PATCH 06/10] use SSL_kDHE throughout instead of SSL_kEDH

DHE is the standard term used by the RFCs and by other TLS implementations. It's useful to have the internal variables use the standard terminology. This patch leaves a synonym SSL_kEDH in place, though, so that older code can still be built against it, since that has been the traditional API.

[PATCH 09/10] Replace EDH-RSA-DES-CBC-SHA, etc. with DHE-RSA-DES-CBC-SHA

Replace the full ciphersuites with EDH- in their labels with DHE- so that all DHE ciphersuites are referred to in the same way. Leave backward-compatible aliases for the ciphersuites in question so that configurations which specify these explicitly will continue working. --- ssl/s3_lib.c | 12

[PATCH 02/10] emit ECDHE instead of EECDH for kX packet trace output

other parts of packet tracing emit the standard ECDHE label instead of EECDH. This change brings the output of ssl_print_client_keyex() and ssl_print_server_keyex() into accordance with the standard term. --- ssl/t1_trce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 04/10] Allow DHE and kDHE as synonyms of EDH and kEDH when specifiying ciphers

The standard terminology in https://tools.ietf.org/html/rfc5426 is DHE. openssl ciphers outputs DHE (for the most part). But users of the library currently cannot specify DHE, they must currently specify EDH. This change allows users to specify the common term in cipher suite strings without

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

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

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

On 12/20/2013 12:52 PM, Stephen Henson via RT wrote: On Fri Dec 20 18:37:18 2013, d...@fifthhorseman.net wrote: I posted a series of 10 changesets to openssl-dev which standardizes OpenSSL's input, API, and output on the standard names (DHE and ECDHE) while retaining backward compatibility

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

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

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

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

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

On 12/20/2013 03:30 PM, Matt Caswell wrote: I had this problem with my ocb patch recently. For future reference, I solved it by creating a temporary branch and using git merge --squash. So if your commits are on my-branch, and you want to create a patch against master: fwiw, i think squashing

EDH vs DHE: which specifications use the term EDH ?

hey folks-- I'm working on a set of patches that will hopefully normalize the terminology for PFS key exchange within OpenSSL to the terms that the rest of the world uses. (Keeping backward compatibility is one of my goals too, of course). In particular, i'm concerned that when the rest of the

[openssl.org #3164] [PATCH] require DH group of 1024 bits

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 +++

Re: OpenSSL client DH group limits

On 11/07/2013 09:15 AM, Kurt Roeckx wrote: I filed a ticket about this ealier (#3120) You can see the discussion about that here: http://openssl.6102.n7.nabble.com/openssl-org-3120-Minimum-size-of-DH-td46401.html ah, thanks. It's too bad that discussion isn't mirrored on

  1   2   >