5 ms·
Random Seeds in Ubuntu 14.04 LTS Cloud Instances
- bmm6o 13y agoThe links in the slides are borked, there seem to be 3 stray bytes at the end of each shortened url.
- zimbatm 13y agoTLDR; PRNG seeds in the cloud are somewhat predictable. Because sshd generates the keys on boot it's possible to guess the private key on a fraction of the cloud hosts. Ubuntu 14.04LTS solves the problem by adding a new source of entropy. They add a early-boot (before sshd) service that fetches data from an external server. In short: `curl http://some-server http://some-server > /dev/urandom` EDIT: Looking for the default server but launchpad seems to be down. Ideally it would be a trusted source like the cloud provider themselves. EDIT2: https://entropy.ubuntu.com/ https://entropy.ubuntu.com/ and the public cert is provided with the package.
- bmm6o 13y agoUbuntu hosts one, but it's open source so the cloud provider can host one, or you can host one yourself (when appropriate).
- hiphopyo 13y agoChoose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, and the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
- skywhopper 13y agoIt would be interesting to hear how OpenBSD deals with the issue Ubuntu is attempting to address here. This comment, however, is neither interesting nor is it, apparently, related in any way to the topic of this post or the content of the article.
- justincormack 13y agoTheo is against virtualisation, and there is no support for it (you can of course do it anyway with full hardware emulation). "You've been smoking something really mind altering, and I think you should share it. x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
- jmnicolas 13y agoThough I don't have any experience with OpenBSD myself, I read somewhere that it was hard to virtualize.
- Thaxll 13y agoWhy use Pf when you can use a more advanced fw like Iptables?
- bronson 13y agoChoose Tide for your laundry needs! Choose Glisten for the whitest teeth! Shameless.
- shitlord 13y agoYou can actually use bottles of Tide to purchase drugs, if you ever get sick of washing clothes. So in a way, Tide might be the best laundry detergent.
- otterley 13y agoIs egd not sufficient here?
- lotharrr 13y agoNope. Linux systems don't need EGD: the in-kernel gatherers do everything the user-space EGD daemon would, and better. The problem they're aiming to solve is that some things (like first-boot ssh key generation) are running so early that the in-kernel gatherers haven't produced anything yet, so a user-space daemon couldn't do any better. (disclaimer: I wrote EGD) This sort of "early remote entropy fetch" could work well in an EC2-like environment, where there's a mature box with its own well-seeded entropy pool nearby (e.g. the physical host of the new VM), close enough that we can talk to it without an eavesdropper hearing the seed. We really do need network-proximity for this: encryption wouldn't help you. If the attacker knew the complete state of your client, they could deduce your "random" DH session key, and then learn the seed you were trying to transfer. You either need an unobserved conversation, or a pre-shared secret (and if you have that, you could just use it as the seed).
- otterley 13y agoHow about rngd?
- e12e 13y ago> We really do need network-proximity for this: encryption wouldn't help you. That was my first thought on reading the article - they do connect via ssl/tls to a daemon and get 64 bytes of entropy. But how much good entropy would you need to complete a secure tls handshake? Granted, it should be less than for generating some private key(s) -- but this still feels a little (too) hand-wave-y for me. I certainly appreciate the effort (both writing the simple client and server, and highlighting the problem (more)). Looks like a great thing to run on vm hosts, though.
- zackelan 13y ago> That was my first thought on reading the article - they do connect via ssl/tls to a daemon and get 64 bytes of entropy. But how much good entropy would you need to complete a secure tls handshake? It certainly doesn't mitigate the attack completely, but it does reduce it to a narrower window of time, so I think that's a step in the right direction. Before - given 1000 machines in EC2, running the same AMI, it seems like you have a better-than-expected chance of predicting the SSH host keys (or other sensitive "random" data that was generated on first boot) of a fair number of those machines. With this - given those same 1000 machines in EC2, you would have to eavesdrop on the network traffic of each one, at the time of its first boot, to have a reasonable chance of guessing the state of the internal entropy pool.
- qoo 13y agohaveged - A simple entropy daemon The haveged project is an attempt to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm. Haveged was created to remedy low-entropy conditions in the Linux random device that can occur under some workloads, especially on headless servers. Current development of haveged is directed towards improving overall reliablity and adaptability while minimizing the barriers to using haveged for other tasks. http://www.issihosts.com/haveged/index.html http://www.issihosts.com/haveged/index.html
- neuroscr 13y agoSending your random seed over the wire doesn't sound like the right direction. For those listening, it always makes sure they have your seed. Did the NSA get them too?