24 Apr
2010
24 Apr
'10
8:50 a.m.
Hi,
Apologies in advance if these are stupid questions...
1) With previous VPS providers, I've found that I've had to symlink
/dev/random to /dev/urandom to avoid an issue where SSL/TLS smtp
connections would hang for a long time waiting for sufficient entropy to
setup the secure connection. Is this something I need to do at Bitfolk too?
2) I've setup postfix (with TLS), and a self-signed certificate. This is
fine for my purposes, but I wondered if there was a risk that other
relay hosts would be unable to deliver email to my box if they weren't
able to validate the certificate? If so, is there a way of forcing other
relays to use non-secure connections, while retaining the ability to do
authenticated SMTP over TLS?
thanks in advance for any help with this!
Matt.
24 Apr
24 Apr
9:22 a.m.
Hi Matt,
On Sat, Apr 24, 2010 at 09:50:19AM +0100, Matt Holgate wrote:
Apologies in advance if these are stupid questions...
1) With previous VPS providers, I've found that I've had to symlink
/dev/random to /dev/urandom to avoid an issue where SSL/TLS smtp
connections would hang for a long time waiting for sufficient entropy to
setup the secure connection.
I've been looking into this after a couple of people mentioned that
they sometimes didn't have enough entropy.
I've bought an entropy key (http://www.entropykey.co.uk/) and am
planning to hook it up to the entropy-gathering daemon. People who
are interested would then be able to run their own egd that talks to
mine in order to obtain more entropy.
This isn't a very high priority at the moment. I accidentally had
the ekey plugged in to a machine that doesn't have USB enabled in
the BIOS, so I need to visit the datacentre to sort that out, and I
don't plan to do that until I have a new server ready to install in
a couple of weeks. But I am working on it.
I've started graphing available entropy to see what difference it
will make, if any.
Typical VMs:
http://tools.bitfolk.com/cacti/graph_1847.html
http://tools.bitfolk.com/cacti/graph_1863.html
http://tools.bitfolk.com/cacti/graph_1900.html
I'll see how/if the ekey improves things.
[yes I am aware of all the wacky ideas of putting webcams in front
of lava lamps or in dark boxes, letting sound cards listen to static
etc etc.]
Is this something I need to do at Bitfolk too?
Unless you get entropy from somewhere else, the lack of real
hardware devices means a lack of entropy which means things which
require a lot of entropy like setting up SSL connections under GNU
TLS may be slow. If you can't get enough entropy then yes, forcing
things to use /dev/urandom when they really wanted /dev/random might
be your only option.
2) I've setup postfix (with TLS), and a
self-signed certificate. This is
fine for my purposes, but I wondered if there was a risk that other relay
hosts would be unable to deliver email to my box if they weren't able to
validate the certificate? If so, is there a way of forcing other relays to
use non-secure connections, while retaining the ability to do
authenticated SMTP over TLS?
As far as I'm aware, you get the choice of whether to verify the
other end's certificate but you don't get to tell the other end not
to verify yours.
I don't think many people verify certificates for SMTP, not between
themselves and third parties anyway.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
25 Apr
25 Apr
3:06 p.m.
On Sat, 24 Apr 2010 09:22:21 +0000
Andy Smith <andy(a)bitfolk.com> wrote:
Hi Matt,
On Sat, Apr 24, 2010 at 09:50:19AM +0100, Matt Holgate wrote:
The Entropy Keys are a wonder - even for servers that aren't VPS
based... Though, dependant on how many people are using your egd, you
might find that it doesn't give enough, and might have to have more
than one (or wait for the ptang, if it ever comes out)
Apologies in advance if these are stupid
questions...
1) With previous VPS providers, I've found that I've had to
symlink /dev/random to /dev/urandom to avoid an issue where SSL/TLS
smtp connections would hang for a long time waiting for sufficient
entropy to setup the secure connection.
I've been looking into this after a couple of people mentioned that
they sometimes didn't have enough entropy.
I've bought an entropy key (http://www.entropykey.co.uk/) and am
planning to hook it up to the entropy-gathering daemon. People who
are interested would then be able to run their own egd that talks to
mine in order to obtain more entropy.
This isn't a very high priority at the moment. I accidentally had
the ekey plugged in to a machine that doesn't have USB enabled in
the BIOS, so I need to visit the datacentre to sort that out, and I
don't plan to do that until I have a new server ready to install in
a couple of weeks. But I am working on it.
I've started graphing available entropy to see what difference it
will make, if any.
Typical VMs:
http://tools.bitfolk.com/cacti/graph_1847.html
http://tools.bitfolk.com/cacti/graph_1863.html
http://tools.bitfolk.com/cacti/graph_1900.html
I'll see how/if the ekey improves things.
26 Apr
26 Apr
7:43 a.m.
Hi Andy,
Thanks for the detailed response.
Unless you get entropy from somewhere else, the lack
of real
hardware devices means a lack of entropy which means things which
require a lot of entropy like setting up SSL connections under GNU
TLS may be slow. If you can't get enough entropy then yes, forcing
things to use /dev/urandom when they really wanted /dev/random might
be your only option.
The entropy keys sound very interesting, however it's probably
sufficient for my purposes to just link random->urandom (that's not an
open invitation for you all to attempt to compromise my box ;-)).
I found an article which gives the necessary udev runes here:
http://n0tablog.wordpress.com/2007/11/24/running-out-of-entropy-in-debian-e…
(otherwise a manual symlink will be lost on reboot).
I don't think many people verify certificates for
SMTP, not between
themselves and third parties anyway.
Cool...
Thanks for your help
Matt.
10:47 a.m.
In a very similar manner I use rng-tools to replenish entropy from
urandom if entropy falls too low, which whilst having the security
hole of being more predictable (especially when consuming below my top
up margin) of has the benefit of real randomness mixed in there.
I believe rng-tools is supposed to be used with a hardware key
(possibly such as Andy's) but even when using urandon as a source it
works around the issue of blocking randomness.
~Mat
On 26 April 2010 08:43, Matt Holgate <matt-bitfolk(a)holgate.org.uk> wrote:
Hi Andy,
Thanks for the detailed response.
Unless you get entropy from somewhere else, the
lack of real
hardware devices means a lack of entropy which means things which
require a lot of entropy like setting up SSL connections under GNU
TLS may be slow. If you can't get enough entropy then yes, forcing
things to use /dev/urandom when they really wanted /dev/random might
be your only option.
The entropy keys sound very interesting, however it's probably sufficient
for my purposes to just link random->urandom (that's not an open invitation
for you all to attempt to compromise my box ;-)).
I found an article which gives the necessary udev runes here:
http://n0tablog.wordpress.com/2007/11/24/running-out-of-entropy-in-debian-e…
(otherwise a manual symlink will be lost on reboot).
I don't think many people verify certificates
for SMTP, not between
themselves and third parties anyway.
Cool...
Thanks for your help
Matt. 
11:42 a.m.
On 26/04/10 11:47, Mat Johns wrote:
In a very similar manner I use rng-tools to replenish
entropy from
urandom if entropy falls too low, which whilst having the security
hole of being more predictable (especially when consuming below my top
up margin) of has the benefit of real randomness mixed in there.
That's exactly how urandom works but in reverse; that seems a bit of a
bizarre setup to me (reading from urandom will deplete your system
entropy just like random does).
Too many apps read from random when urandom is 'good enough', but in
either situation (yours or reading from urandom) you then can't tell
which data is high-quality, which could be a problem when it is required
(e.g. creating important keys).
Ta
Alex.
--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com
5353
days inactive
5355
days old
5 comments
5 participants
participants (5)
-
Alex Hudson -
Andy Smith -
Martin Meredith -
Mat Johns -
Matt Holgate