RE: Generate DH parameters on the fly

2014-09-20 Thread Dave Thompson
> From: owner-openssl-us...@openssl.org On Behalf Of Marco Bambini
> Sent: Friday, September 19, 2014 12:04

> my server needs to accept DHE ciphers from clients so I think I would need
to
> be able to load static dh512.pem, dh1024.pem, dh2048.pem and dh4096.pem
> certificates on server side. In order to increase security I would like to
skip
> the pem file loading step and generate these dh certificates on the fly.
> 
Those aren't certificates, they are parameters. For DHE (and also DH-anon) 
server and client each generates a new (ephemeral) keypair for each
handshake 
using the same parameters. Having many keypairs under the same parameters 
is secure, this is how Diffie-Hellman works. Generating a new keypair is 
nearly instantaneous; generating new parameters takes a minute or 
several, which would be unacceptable per connection on most servers.
Generating them on server startup, or now and then such as monthly,
would give you the same extremely tiny increase in security.

If you really want that, generate parameters using the DH_ specific 
routine or the EVP_PKEY_ wrapper and pass that to set_tmp_dh or 
use it (or maybe them) in the callback set by set_tmp_dh_callback,
instead of the one(s) read from file(s).

The protocol does define "static" DH suites which use DH certificates.
(SSLv3 through TLSv1.1 distinguished DH certs signed by RSA or DSS 
in the ciphersuite; 1.2 essentially merges them and uses the new 
sigalgs extension instead.) OpenSSL did not implement these in any 
release yet; 1.0.2 is planned to. DH certificates cannot be requested 
using the standard PKCS#10 CSR (because DH can't sign) and I've never 
seen nor heard of any CA that issues a DH cert nor any system wanting 
to use static-DH. (OpenSSL *does* implement the static *EC*DH suites,
although I haven't seen them used in anger either.)



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Change in default behavior from 1.0.1g to 1.0.1h: string global_mask

2014-09-20 Thread Dave Thompson
> From: owner-openssl-us...@openssl.org On Behalf Of Andy Schmidt
> Sent: Wednesday, September 17, 2014 18:28

> I just tracked down an obscure bug in our certificate authentication
> code to a change in in the global mask for ASN.1 strings in
> crypto/asn1/a_strnid.c.
> (https://github.com/openssl/openssl/commit/3009244da47b989c4cc59ba02c
> f81a4e9d8f8431)
> I have a couple of questions about this:
> 
> 1. Was this change made for a security related reason?
> That is, by changing global_mask back to the 1.0.1g initialized value,
> are we introducing a security vulnerability?
> 
Going back (probably, depending on the actual string values you use) 
may encode differently than standards call for. AFAICS there is no direct 
security impact, but if and to the extent it causes compliance or 
interop problems, those may indirectly affect security. (Canonical 
example: browser displays a dialog box about "this certificate may 
be invalid because $technical_details. 99.999% of users click on 
the box that says "I don't want this computer gibberish, just 
connect me to the website even if it is run by thieves so that 
I can have my money and personal data stolen QUICKLY.)

> 2. Is there a changelist somewhere in the source tarball that lists
> the 1.0.1g to 1.0.1h revisions? Or a list that outlines changes in the
> default settings?
> This would be extremely helpful to incorporating newly released 1.0.1
> subversions. The file CHANGES appears to only list security
> vulnerabilities.
> 
IME CHANGES generally lists visible (i.e. commandline or API) changes,
and internal ones (like refactoring) if they are considered important.
You are not the only one visibly unhappy this change was made unlisted.
It was apparently made for http://rt.openssl.org/Ticket/Display.html?id=3371
then affirmed by http://rt.openssl.org/Ticket/Display.html?id=3402
and http://rt.openssl.org/Ticket/Display.html?id=3469 .
AFAICT rt ticket creations are "published" on openssl-dev,
and these two were definitely discussed there.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org