[openssl-dev] [openssl.org #4107] [PATCH] null pointer dereference: bn_wexpand return code not checked in bn_g2fm.c

[Pascal Cuoq via RT]

The function bn_wexpand() can fail. Most of the invocations in bn_g2fm.c are 
guarded, but three of them aren't, causing a null pointer dereference when 
bn_wexpand() fails:

https://github.com/openssl/openssl/blob/3f6c7691870d1cd2ad0e0c83638cef3f35a0b548/crypto/bn/bn_gf2m.c#L700

If the calls to bn_wexpand() are guarded as in the attached patch, the null 
pointer dereferences no longer occur.




bn_wexpand.patch
Description: Binary data
___
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 #4108] Set TLS ticket keys API

[Viktor Dukhovni]

On Tue, Oct 27, 2015 at 03:13:27AM +, Chris Conroy via RT wrote:

> Pull request on github: https://github.com/openssl/openssl/pull/452
> 
> The existing API for managing RFC 5077 TLS ticket keys is cumbersome:
> callers must either specify a key once at startup or they must implement a
> complicated callback API.
> 
> This new API allows a caller to set a list of TLS ticket keys. The first
> key in the list is preferred, and any other keys in the list will be
> accepted with an upgrade to a ticket with the preferred key. This scheme
> allows groups of servers to implement seamless key rotation strategies.
> 
> The original patch comes from Twitter's https://github.com/twitter/sslconfig

Having written functionally similar code for Postfix some years
back, I should probably review this one.

A few quick comments:

* The encryption algorithm for session tickets is hardcoded to
  aes-128-cbc.  It should default to aes-256-cbc, and should
  be configurable.

* I don't see any attempt to synchronize the key rotation cycle,
  with the session lifetime.  If the session cache lifetime is
  shorter than the key lifetime, sessions will be refused as
  stale.

* In the Postfix implementation, keys have a explicit end-time
  for use in creating new sessions, and another end time for
  use in decrypting existing sessions, and the session lifetime
  is set to exceed the latter.  Instead of applications having
  to provide a list of keys up front, the callback fetches new
  keys as keys expire or session tickets arrive with a key that
  is not available in memory.  This allows applications to
  generate new keys on demand, or fetch them "just-in-time",
  ... which is perhaps more flexible than preloading a list.

I've not yet read all the code in detail, so I might retract some
of the above, but I'd like to ask who'll be the primary contact to
discuss any feedback on the proposed design?  Perhaps we can do
something that takes the best ideas from both the Twitter and the
Postfix approaches (and any others that might have good ideas).

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

Re: [openssl-dev] Improving OpenSSL default RNG

[Dr. Matthias St. Pierre]

On 10/24/2015 05:55 PM, Marcus Meissner wrote:
> On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote:
>> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote:
>> ...
>> In general the NIST DRBGs seem fairly complicated (or completely 
>> untrustworthy
>> like Dual EC DRBG), so I'd rather have a different implementation as default
>> RNG for OpenSSL.
> 
> Well, the Dual EC has been removed from the guidance.
> 
> The other 3 modes described in NIST 800-90a make sense though. I suggest to 
> read
> the standard, the main things making it long are all the error handling and
> reseeding strategies.
> 
> Ciao, Marcus

I agree, to me it seems to be a rather straightforward implementation of a 
hybrid RNG. To get an impression of the
essentials, e.g. for the DRBG based on AES-CTR, it helps to have a look at 
Figures 11 (p.49) and 12 (p.51)
of  .

The nice part about the DRBG is that one can connect it to an external entropy 
source and configure 
the reseed interval. It also supports prediction resistance on demand, although 
this feature is not available through
FIPS_drbg_method(), only if one uses FIPS_drbg_generate() directly.

So it would be convenient for us to have it available in the normal OpenSSL 
library without having to fiddle
with the FIPS object module. It wouldn't have to be the default OpenSSL RNG, 
though.

Regards, Matthias

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