On Sat, Nov 17, 2012 at 10:56 PM, <jb-open...@wisemo.com> wrote:
> On 16-11-2012 19:57, Jeffrey Walton wrote:
>>
>> Hi Jacob,
>> On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
>>>
>>> On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
>>>>
>>>> ...
>>>> Headless servers, entropy starvation, and rollbacks are a concern in
>>>> modern environments. OpenSSL and other entropy gathers, such as EDG,
>>>> don't account for the later. Its best to take the bull by the horns
>>>> and do it yourself. At minimum, you need to call RAND_add() with
>>>> entropy external to /dev/{u}rand.
>>>
>>> Would you care to elaborate on the following points:
>>> 1. What do you mean by "rollback"
>> Virtual Machine rollback attacks.
> And how would an attacker rollback the victims VM?, an attacker with that
> level of control is already presumably able to access the VMs data,
> storage and execution state directly.
It could happen accidentally by the folks in the data center.
>>> 2. What RNG/PRNG are you referring to as "EDG"
>>
>> EDG is Entropy Gatering Daemon. I was talking to John Steven about it
>> over the summer (John is CTO of Cigital, OWASP member, and part of the
>> project). EDG does not take measure to mitigate rollback attacks.
> Ah, I thought that was called "EGD"
My bad...
...
>> If I go to https://www.wisemo.com, I initiated that connection so its
>> not under control of an attacker). The exchange contains some random
>> (but public) data - namely, Wisemo's public key. A passive attacker on
>> the public internet may be able to observe the exchange. So we can
>> improve entropy in the generator at the cost of leaking information
>> about state input.
> And what if (hypothetically speaking) I had doctored that public key
> to negatively affect the entropy of some well known PRNG when used
> with some well known hedging software (I haven't, but you have to
> take my word for it).
Point taken, but the attacker is not going to control *that* many
machines. Or at least I don't believe he/she can.
...
>> I know of a number of medium and large size enterprises that don't use
>> hardware, and rely on the software generator provided by the OS. Those
>> enterprises include financial institutions in New York.
>> This is a true story. I'm a security architect, and this got pushed to
>> the team for risk acceptance. One financial institution was having
>> problems with entropy depletion in a virtual environment. The
>> appliance was apparently running out, and could not push sufficient
>> entropy to its hosts (it was blocking in calls to /dev/random, if I
>> recall correctly). The vendor stated we should delete /dev/random and
>> then link it to /dev/urandom (or vice versa), so the generator would
>> not block.
> Yeah, typical incompetent support, and or management forcing the
> engineers to provide a quick fix even if only a slower fix is possible.
> Happens all the time to safety measures much more important than this.
I caught a lot of heat for pointing it out (the folks in engineering
had their heart's set on using it), and calling "bullshit" on the
recommendation. I think it was my presentation....
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
