> Am 29.05.2017 um 00:57 schrieb Rob Kampen <rkam...@kampensonline.com>:
>
> On 28/05/17 23:56, Leon Fauster wrote:
>>> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz <r...@htt-consult.com>:
>>>
>>>
>>>
>>> On 05/28/2017 04:24 AM, Tony Mountifield wrote:
>>>> In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
>>>> Robert Moskowitz <r...@htt-consult.com> wrote:
>>>> Interesting. I just did a quick check of the various servers I support,
>>>> and have noticed that all the CentOS 5 and 6 systems report entropy in
>>>> the low hundreds of bits, but all the CentOS 4 systems and the one old
>>>> FC3 system all report over 3000 bits.
>>>>
>>>> Since they were all pretty much stock installs, what difference between
>>>> the versions might explain what I observed?
>>> This is partly why so many certs found in the U of Mich study are weak and
>>> factorable. So many systems have inadequate entropy for the generation of
>>> key pairs to use in TLS certs. Worst are certs created in firstboot
>>> process where at times there is no entropy, but the firstboot still creates
>>> its certs.
>>
>> /var/lib/random-seed and $HOME/.rnd are approaches to mitigate this scenario.
>>
>
> so there are mitigations - the question really is: why hasn't redhat made
> these mitigations the default for
> their enterprise products - maybe other influences we are unaware of - seems
> like a huge big hole. With the
> advent of SSL/TLS being mandated by google et al, every device needs access
> to entropy.
Who said upstream hasn't done something? :-) The mentioned artifacts are the
evidence that they are "in place/in use"
by default. BTW, any crypto-sensitive task needs beside entropy also others
prerequisites. So, i recommend checking
the own systems to understand, what upstream respectively the crypto
functions/libraries etc. actually does/do.
--
LF
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
