On 05/29/2017 10:18 AM, Leon Fauster wrote: >> Am 29.05.2017 um 14:41 schrieb Robert Moskowitz <rgm at htt-consult.com>: >> >> >> >> On 05/29/2017 06:46 AM, Leon Fauster wrote: >>>> Am 29.05.2017 um 05:46 schrieb Robert Moskowitz <rgm at 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". Oh, and in my 8 years with Verizon, I worked with the Cybertrust PKI team. And I am the author of the Bridge CA model used in the US Fed PKI, the BioPharm PKI and a few others. I despair about what it costs to do decent Identity management. And how meaningless much of it still is.