[Cryptography] Security of Ubuntu RNG pollinate?

Tom Mitchell mitch at niftyegg.com
Mon Nov 21 22:57:04 EST 2016


On Mon, Nov 21, 2016 at 1:01 PM, John Gilmore <gnu at toad.com> wrote:

> Dustin Kirkland wrote a randomness client and server for feeding
> Ubuntu virtual machines that don't have good randomness sources, which
> is now a standard feature in Ubuntu since 14.04 Cloud instances.  See:
>
>   http://blog.dustinkirkland.com/2014/02/random-seeds-in-
> ubuntu-1404-lts-cloud.html
>   https://launchpad.net/pollinate



> I am wondering just how hard this would be for NSA or another passive
> attacker to break.
>


> that hash of the response to /dev/urandom.  The code is shipped with
> the certificate of host "entropy.ubuntu.com" and by default makes an
> HTTPS access to it, checking via the certificate that it hasn't been
> impersonated.
>
> My initial concern is that the entire transaction is visible to
> eavesdroppers.

...

> What am I missing?


You seem to have a handle on the risks.
To me the issue is the notion of a cloud and cloud service.

For a VM in a cloud to reach out to the internet at any time
especially as part of the normal system boot sequence and
initial firewall settings seems wrong.  A cloud service can fix that
and should in the images they deploy for you.

I see that,  pollinate is easy to modify and puppet  has
some notion of how to keep things close:
   "Prior to configuring puppet you may want to add a DNS CNAME record for
puppet.example.com,
   where example.com is your domain. By defaultPuppet clients check DNS for
puppet.example.com
   as the puppet server...."
Keeping control over external connections and actions at initialization is
important.

Using the same mind set I would change entropy.ubuntu.com to
entropy.cloud.my_domain.con
having put a local server inside the cloud space and behind the main
firewall.  I would
also install a default firewall rule set and force hop counts at
initialization to be short enough
that they never leave the building until a number of sanity checks and
initializations are finished.

The entropy service is modest enough that a raspberry-pi could serve up
bits for a very large number of first boot systems as long as the power is
sequenced.

He has a solution for his cloud view but the world is bigger.
His idea seems simple, portable  and easy to adjust...
I suspect managing the default firewall and hop count would be key
to keeping initial actions close to home and under control.

The title is interesting...
Cheng Jin and Kang G. Shin, "Defense against Spoofed IP Traffic
Using Hop-Count Filtering", IEEE/ACM Trans. Networking, vol. 15 No. I, Feb
2007.
https://www.eecis.udel.edu/~hnw/paper/rogueip_ccs03.pdf

On Ubuntu.. pick a number that does what is needed.
   sudo sysctl net.ipv4.ip_default_ttl=5    # to start keep things close
   sudo sysctl net.ipv4.ip_default_ttl=129  # all set, let us go

-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161121/411a0a51/attachment.html>


More information about the cryptography mailing list