> 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: >>>> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz <rgm at htt-consult.com>: >>>> >>>> >>>> >>>> On 05/28/2017 04:24 AM, Tony Mountifield wrote: >>>> 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. >>> >>> -- >>> LF >> 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: "/proc/apm:/proc/cpuinfo:/proc/dma:/proc/filesystems:/proc/interrupts:/proc/ioports:/proc/pci:/proc/rtc:/proc/uptime" -- LF
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: >>>>> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz <rgm at htt-consult.com>: >>>>> >>>>> >>>>> >>>>> On 05/28/2017 04:24 AM, Tony Mountifield wrote: >>>>> 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. >>>> >>>> -- >>>> LF >>> 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?> "/proc/apm:/proc/cpuinfo:/proc/dma:/proc/filesystems:/proc/interrupts:/proc/ioports:/proc/pci:/proc/rtc:/proc/uptime"
> 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". -- LF