Re: libssh2_session_handshake remains stuck

[Peter Stuge]

Hi Simone,

Simone Azzalin wrote:
> After looking at /dev/random, I noticed that it's not being updated as 
> fast as /dev/urandom...

Please consider why that is so.


> So I just thought to force libgcrypt to use /dev/urandom.

Is /dev/urandom suitable for cryptography?


> I recompiled all in a moment and it seems it works fine !

In fact /dev/urandom is *not at all* suitable for cryptography.

A weak entropy source results in guessable encryption keys. This
happened in debian: https://www.debian.org/security/2008/dsa-1571

Forcing a shared cryptographic library to use a weak entropy source
not only compromises that one file transer but in fact compromises
the security of every software on the system using the same library,
for the entire lifetime of the product. Don't do that.


I'll repeat what I wrote before, please take it seriously although you
don't have to pay for it:

> >> If you neglect this issue and choose not to implement any solution to
> >> the lack of entropy problem then your /dev/random becomes predictable
> >> across boots, rendering any asymmetric encryption on the system useless;
> >> allowing MITM attacks and perhaps even worse extraction of the SSH
> >> authentication credentials.


To summarize:

* Your embedded system lacks a hardware entropy source.

* /dev/random blocks when the crypto library needs entropy for the
  SSH session key exchange if insufficient entropy is available.

* I described one possible workaround for this problem; saving
  randomness across boot. If you choose this solution please consider
  what you will do in manufacturing. You do *NOT* want to ship all
  devices with the same initial seed.

* /dev/urandom is unsuitable for cryptography and forcing cryptographic
  libraries to use it destroys security in your entire system.

You have to solve the lack of entropy problem properly if you want
an actually secure system.


If you don't care about security then you could use FTP for the file
transfer on boot.


Kind regards

//Peter
___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Re: libssh2_session_handshake remains stuck

[Simone Azzalin]

Well,

After looking at /dev/random, I noticed that it's not being updated as 
fast as /dev/urandom...

So I just thought to force libgcrypt to use /dev/urandom.

To do this I changed the libgcrypt configure file (lines 13082:13803) from

*NAME_OF_DEV_RANDOM="/dev/random"**
**NAME_OF_DEV_URANDOM=***"/dev/urandom"**

**to**
**
*NAME_OF_DEV_URANDOM="/dev/urandom"
NAME_OF_DEV_RANDOM=NAME_OF_DEV_URANDOM*

so effectively forcing the lib to use */dev/urandom*.

I recompiled all in a moment and it seems it works fine !
Now libssh2 starts sending files from the first seconds after boot.

Thanks Peter !
Simon

On 6/22/21 5:36 PM, Simone Azzalin wrote:

Hello Peter,

Thank for your useful information. Yes this is an embedded system.
I will try the solution that you suggest as soon as possible and give 
you a feedback.


Simon

On 6/22/21 4:24 PM, Peter Stuge wrote:

Simone Azzalin wrote:

I have noticed that during the first minutes after boot, the
libssh2_session_handshake execution remains stuck blocking the
execution of the program.

Is that an embedded system, without a strong entropy source?



Is this a known issue ? Do you have any possible suggestion to
determine the cause of it ?

The session handshake includes among other things a key exchange,
which requires random numbers.

When the system has little entropy, such as after boot when not much
has happened, then when the crypto library that libssh2 uses (so not
libssh2 itself) reads /dev/random that read will hard block until
more entropy becomes available.

One ideal solution would be a dedicated hardware entropy source.

The most basic workaround is to save a /dev/random seed across reboots
by saving the /dev/random contents to a file when shutting down and
writing it back to /dev/random on boot.


If you neglect this issue and choose not to implement any solution to
the lack of entropy problem then your /dev/random becomes predictable
across boots, rendering any asymmetric encryption on the system useless;
allowing MITM attacks and perhaps even worse extraction of the SSH
authentication credentials.


//Peter
___
libssh2-develhttps://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


--
*Simone Azzalin*
*Embedded Systems Engineer | DARES TECHNOLOGY*
Esteve Terrades, 1 | Edificio RDIT, Parc UPC – PMT | E – 08860 
Castelldefels, Barcelona
+34 93 514 1652 | sazza...@dares.tech  | 
www.dares.tech  | Legal notice 



___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


--
*Simone Azzalin*
*Embedded Systems Engineer | DARES TECHNOLOGY*
Esteve Terrades, 1 | Edificio RDIT, Parc UPC – PMT | E – 08860 
Castelldefels, Barcelona
+34 93 514 1652 | sazza...@dares.tech  | 
www.dares.tech  | Legal notice 

___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Re: libssh2_session_handshake remains stuck

[Simone Azzalin]

Hello Peter,

Thank for your useful information. Yes this is an embedded system.
I will try the solution that you suggest as soon as possible and give 
you a feedback.


Simon

On 6/22/21 4:24 PM, Peter Stuge wrote:

Simone Azzalin wrote:

I have noticed that during the first minutes after boot, the
libssh2_session_handshake execution remains stuck blocking the
execution of the program.

Is that an embedded system, without a strong entropy source?



Is this a known issue ? Do you have any possible suggestion to
determine the cause of it ?

The session handshake includes among other things a key exchange,
which requires random numbers.

When the system has little entropy, such as after boot when not much
has happened, then when the crypto library that libssh2 uses (so not
libssh2 itself) reads /dev/random that read will hard block until
more entropy becomes available.

One ideal solution would be a dedicated hardware entropy source.

The most basic workaround is to save a /dev/random seed across reboots
by saving the /dev/random contents to a file when shutting down and
writing it back to /dev/random on boot.


If you neglect this issue and choose not to implement any solution to
the lack of entropy problem then your /dev/random becomes predictable
across boots, rendering any asymmetric encryption on the system useless;
allowing MITM attacks and perhaps even worse extraction of the SSH
authentication credentials.


//Peter
___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel


--
*Simone Azzalin*
*Embedded Systems Engineer | DARES TECHNOLOGY*
Esteve Terrades, 1 | Edificio RDIT, Parc UPC – PMT | E – 08860 
Castelldefels, Barcelona
+34 93 514 1652 | sazza...@dares.tech  | 
www.dares.tech  | Legal notice 

___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Re: libssh2_session_handshake remains stuck

[Peter Stuge]

Simone Azzalin wrote:
> I have noticed that during the first minutes after boot, the 
> libssh2_session_handshake execution remains stuck blocking the
> execution of the program.

Is that an embedded system, without a strong entropy source?


> Is this a known issue ? Do you have any possible suggestion to
> determine the cause of it ?

The session handshake includes among other things a key exchange,
which requires random numbers.

When the system has little entropy, such as after boot when not much
has happened, then when the crypto library that libssh2 uses (so not
libssh2 itself) reads /dev/random that read will hard block until
more entropy becomes available.

One ideal solution would be a dedicated hardware entropy source.

The most basic workaround is to save a /dev/random seed across reboots
by saving the /dev/random contents to a file when shutting down and
writing it back to /dev/random on boot.


If you neglect this issue and choose not to implement any solution to
the lack of entropy problem then your /dev/random becomes predictable
across boots, rendering any asymmetric encryption on the system useless;
allowing MITM attacks and perhaps even worse extraction of the SSH
authentication credentials.


//Peter
___
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel