> Am 29.05.2017 um 14:41 schrieb Robert Moskowitz <r...@htt-consult.com>: > > > > On 05/29/2017 06:46 AM, Leon Fauster wrote: >>> Am 29.05.2017 um 05:46 schrieb Robert Moskowitz <r...@htt-consult.com>: >>> >>> >>> >>> On 05/28/2017 06:57 PM, Rob Kampen wrote: >>>> On 28/05/17 23:56, Leon Fauster wrote: >>>> 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. >>> The challenge is this is so system dependent. Some are just fine with >>> stock install. Others need rng-tools. Still others need haveged. If >>> Redhat were to do anything, it would be to stop making the default cert >>> during firstboot. Rather spin off a one-time process that would wait until >>> there was enough entropy and then create the default cert. Thing is I can >>> come up with situations were that can go wrong. >>> >>> There are a lot of best practices with certificates and crypto that are not >>> apparent to most admins. I know some things for the crypto work I do (I am >>> the author of the HIP protocol in the IETF). There is just not one size >>> fits all here, and people need to collect clues along with random >>> entropy.... >> >> This default cert is not valid anyway and as random source they use: > > Not valid in what way? Yes the Subject and Issuer names are dorkie, but how > are they not valid?
Not valid in terms of validation (PKI), not equal with verification in terms of "it works". -- LF _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
