> 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: >>>> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz <r...@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 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
