On 04/01/17 13:38, 袁建鹏 wrote:
> Dear all,
> 
> I’m a newbie to OpenVPN/OpenSSL and this is the first time I send a question.
> 
> My EasyRSA 3.0 run on an embeded system, the OpenSSL version is: OpenSSL 
> 1.0.2a 19 Mar 2015
> 
> openssl print `unable to write 'random state'` when call ./easyrsa gen-dh
> but actually the command succeed because `Failed to build DH params` is not 
> printed.
> 
> I googled, the reason is openssl has no rights to write to .rnd file.
> but the path of .rnd file defined by RANDFILE in openssl-1.0.cnf is writable.
> 
> the default HOME directory is /root, this dir is read only.
> if I change HOME to /data/, everything will be ok, /data/.rnd is generated 
> after command done.
> It seems that RANDFILE defined by openssl-1.0.cnf does not take affect.
> 
> then I do the similar work on my Ubuntu desktop system
> and use `strace` to find the details, I found openssl-1.0.cnf is opened, and 
> random file is written to HOME/.rnd. no the one defined in openssl-1.0.cnf.
> 
> Is anyone similar to this problem?

I don't know anything in particular to your issue.  But I want to raise
a concern about running CA management on an embedded device.  So below
is a "Generally speaking" rant.

* Do NOT keep your CA management files (in particular the CA private key)
  on a device directly accessible via the Internet.  In the most ideal
setups,
  the CA files can be offline most of the time, only to be activated when
  needing to sign ("generate") new certificates.

  The reason is that the CA key will be the most sacred data file you
  very likely will ever have responsibility for.  Anyone who compromises
  that key file can issue new and valid certificates without your knowledge,
  easily pretending to be issued by yourself. And you will not notice such
  abuse unless you log and verify all log entries of certificate
fingerprints
  against a list of certificates you know you have issued.

  So if there is a tiny slight chance there is a copy of your private CA
key,
  consider your CA to be compromised.  The *ONLY* solution to this problem
  is to generate a new CA from scratch and issue brand new certificate
to all
  your users.


* Be VERY CAREFUL when doing cryptography on embedded devices, and
  particularly when it comes to generating new keys and DH parameters.
  The reason is that the vast majority of embedded devices DO NOT have
  a good random number entropy source, which leads to fairly predictable
  random numbers, which again results in encryption keys which are more
  easily cracked.


* Be CAREFUL when doing cryptography on VIRTUAL MACHINES.  Much of the
  same issues related to embedded machines can in many cases be just as
  relevant to virtual machines.  The exception is if the hypervisor provides
  a virtualized hardware access to the random number generator on the host
  system.

  On publicly hosted virtual machines there are also other challenges, as
  you have no idea if anyone does a memory dump of your virtual machine
  or feeds the random number generator with predictable data.

  Alternatively, ensure you run entropy gathering software which tries to
  help the system get enough entropy for the random number generator so
  the result is as unpredictable as possible.  But again, if anyone does a
  memory dump of your virtual machine while creating keying material and
  random numbers, such memory dumps can be analysed and sensitive crypto
  related data may be extracted.  (Yes, I know this is far fetched, but it
  is at least theoretically possible - and with time such memory dump
  analysis will only get simpler with improved tools)


Just remember that the predictability of random numbers simplifies
cracking encryption keys.

<http://dilbert.com/strip/2001-10-25>
<https://www.xkcd.com/221/>


--
kind regards,

David Sommerseth


Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to