From libssh2-devel-bounces@cool.haxx.se Tue Jun 22 10:46:58 2021 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 15M8kGVp009259; Tue, 22 Jun 2021 10:46:45 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70122.outbound.protection.outlook.com [40.107.7.122]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 15M8kDP4009246 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 Jun 2021 10:46:14 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nTwwzzhgwe433TS/cokVsUNE/cg4ss/VFIpYvQMy5Za1iv6n7da/2ZWshJp/oIVVfDGtwxrXwfyKWCHe42tN4sVK2S0AkdQRjpvI0kghzCnZr+IpO6rjq4sycGvFV7160yhmplCFiJqFf/3GbGlZRVH3HsVvwWyx8Je/5rygUyPDDKn/ss+w8NpYrGVf7hhEBnRCYS0eIhcba14ZV6nOQn2jAIWwMFit8H/9CcwVckeHA6WrGsA5PgDL/vx5nARu7x24Gfu6vjPO7aACNG0dnfYo1f0U0BBL5YJXpfamWuBFYRGp57KvhXWox1iIEaLHxnYXzUb3eDh5Zy/X/vejqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gxn0kjBZCsmIXnNyxNSKMC/0ycWLZDD+fRNN5lSfwr4=; b=RX2GiwnllYQ006DvyFv/n7ilmhfdPmyCsrs0/wB+DzpTewPr4uvCJzGsGnOCJlQasHxkcFHF7AjBvCXH+M5okfvxPJKkU7mu7yaC9kYc/f4J37BHNV5vj+i1Kg7n/P0jFYszHK0Mu9eWb4RzMNaz4tA9xsKz9Fe471ibRhJff4JGPSLeSqKradWDvvg3SVSeDiMB5FuW8zu2JG3HgnzQms3OHKaQsGNg/1Hn0/pCaOSttqvmRd2oQ91vwylGNkDhyWHel8WKYW3TPt0bhVJJSGfWIKHTviQ3uMJpb0GLxZWWOZ6BChgCF3h447aHq7dAmLXJAODk5nXOqjnzka1xyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dares.tech; dmarc=pass action=none header.from=dares.tech; dkim=pass header.d=dares.tech; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=B66557844.onmicrosoft.com; s=selector1-B66557844-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gxn0kjBZCsmIXnNyxNSKMC/0ycWLZDD+fRNN5lSfwr4=; b=yN4QjcLM0LQSxiT9N6I7JdG/usTwJv7r2CFJSI4NHayby8wnbaSHYSFIBE5HtXg6bYQoKclqmZGNzuStq/fyV3zQ2aBKTOichHgJO1JunUxGzpGZqHCOvNOXE409+Q1c8ZY91Y9OEUBe/ZHT+Id4UY+SfRDSVfd/hZGN5NBOaag= Authentication-Results: cool.haxx.se; dkim=none (message not signed) header.d=none;cool.haxx.se; dmarc=none action=none header.from=dares.tech; Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) by DU2P194MB1566.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:2b7::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Tue, 22 Jun 2021 08:46:08 +0000 Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121]) by DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121%5]) with mapi id 15.20.4242.023; Tue, 22 Jun 2021 08:46:07 +0000 To: libssh2-devel@cool.haxx.se From: Simone Azzalin Subject: libssh2_session_handshake remains stuck Message-ID: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> Date: Tue, 22 Jun 2021 10:46:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 Content-Language: en-US X-Originating-IP: [77.208.83.171] X-ClientProxiedBy: LO2P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::23) To DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.8.101] (77.208.83.171) by LO2P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Tue, 22 Jun 2021 08:46:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 510b4de6-54a7-44cc-779b-08d9355a2d68 X-MS-TrafficTypeDiagnostic: DU2P194MB1566: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: l6t0B9FA93gH61qWwMs1JYHpeg1/w6UaNUSPgTG82qg/ZvLiZeBerJ2Rp63FyBe8wcexPvCQvJwYEEaoySioIC2ntefUx9VY5wr0kQpJsGhktH19ZjjO0XMhAoDjRBFE48A4rLmHW6KEWTcfDbqA8nZGE1Z9LNG0ZxDEGv9Ali2ZwA+BOKqFIpBsyPMn6VLU2Oke/Km/AOSIqtgMHBfEUYhbM7eGhkEu4pT43RwXBCRVZhftt3xz7j2pf3HGxC3EVkUXag1+H4wVQ+sFgDJCASArqm0TJmSiUCqBI+RP3ZXnmemBTTwdydrtUr3hkxwaE9D0cUDeelrobt+EhHrPGUhEdFsy8EDEO51jhbxD5bXsIZSsdne/tvtKtUI3O8LW+GeyEBgVVksEpK+SbLknRIKsHsHtDyzg7zT/fAwMpy0i8kCz/7d9dmEquflkyDfldmdSnFa1LbXOcbleyBRkl/7URwC92qAoKwQPUh63EiuEin0hYiW/6up6VgxNrhtNBwuyBj6mBJQt4eX0/0bVccyi2faqHnsd5AxpRHCMOKmv9wcRKuw0knoN2qxhXEj2c4Vw5DfJsbkBEH02culZykkEKZ36PIieKNYt3wfGAWlrPl6HxR0KpIky+1PqnjpkLQH5RDi0jy9aZ2xpXY6/LNzK6M0nrvrPFeHH7mh0zXqqIXJoaNdT+ziu9tvNsTj5VrUaO38LLkre+dT5w+6PtbKYobgmKI6bOIPGOPJm+f0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7P194MB0459.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(396003)(136003)(39830400003)(66946007)(38350700002)(2616005)(5660300002)(956004)(52116002)(38100700002)(66556008)(4744005)(66476007)(31686004)(31696002)(16526019)(186003)(36756003)(86362001)(478600001)(7116003)(83380400001)(6486002)(16576012)(26005)(2906002)(6916009)(8936002)(8676002)(316002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WFpTYVFGSXVZcUpKVDAvSGtGaVEyUnFQejdNT29mR1BjV3RoeTZabjFuVU8r?= =?utf-8?B?bWhId3ZlVVRQRW41T1kyZUFUcnpVakNHUWVqbzhpQWlINXhrd1pOTW9TRnlC?= =?utf-8?B?amc5dGFmV0FwSXNtcGliU3dOdm15Mmt1L05ZV0IyYnFUY3lUMGt6aHNxYlVN?= =?utf-8?B?SkRCQXRkemNpcllRcEdva05ZczlId1pWazdYKy81cXY2Mm1zdVpnTEVtS3dh?= =?utf-8?B?N1FlZllqVU1ydnNMcDU4enBZMnRsWHE4bDZJMzBaZERaQS9HSlQzK3pBL250?= =?utf-8?B?NTNxSGo4NmtIcGV4ZzI1QVBNL20vQmFtTzh1VDdJRVlXWWQwYU4yTGtESFVK?= =?utf-8?B?Y0puWTEwT2pBdkRxZkp6MG4rTEtNQTdCYjA0RE5qWmF2MWs4TVh4VXNoaVQv?= =?utf-8?B?MER5Y2UwNXZ4RXhNMWVVakZJbkNvcndmU3UrTjRBUHdkbFFKSThmSUJoSFdv?= =?utf-8?B?TGRySWt6cWcweXR0M2k0eHMxMGJia1RuS25NbFR1UUNIa3llOXdoM2lIRGxB?= =?utf-8?B?bVRiUUJQd3hZSXRXN3R0SjNjS2RIcnMwOVU5bnBMZ0t1YlFpYm81dmRQMGw2?= =?utf-8?B?dTlyazNTT3cybXJkR0xlZ1dBZVo4eGtIMHd2T0IrT2U0ZTYvLzNFWXExQm5Q?= =?utf-8?B?N2VMWXBqa0J0cElTbitzeEQ0MHlPb1UxWFdNNXZuS0R4UWQvSFNiY1V6RUZp?= =?utf-8?B?V3Fra3p2OCt0a3E4UjE0QjQ2clBXMWFhdjN3b2FFUlUxemQ2aHNWVFBFa2ZN?= =?utf-8?B?bkk0eEZob0JIMHZ2cGVPYUhCVnN3TVRZTDhDeHQxNEsrN3R1VmtvcmVkZHlv?= =?utf-8?B?c3BGL2w4SHZsbHRqdUxoUUpWRTJNeUc2RkQzblI4QmdOKzBlK2NZQXBQSXpB?= =?utf-8?B?WlZ3eGxNeGVkbWczNUNJNmQ1TjRWaXpKWkhjaUpXYkZyemhzVUJ6dmlkclpL?= =?utf-8?B?OHBqYnhJZk9EWkhFNWcwVGlZcEw5MWdWSnltWGVsNzcza1AyS282Ukk5emc5?= =?utf-8?B?TUFqS0NQZDFla3RoZURldHhzU3R1NlBSaUQ0QlZHUjY2ZUpaWjF0RXVKT0Rw?= =?utf-8?B?KzluU3Jkd0JaaHptSGtCeGFKUm1qWmdtekRPVHA4QTVzL29Ma2ZiRVNMd2h5?= =?utf-8?B?VGNiZ1NDdHE4YWlsV2Nyd3FjeHUxTUFsdWZlT2xlY2dnMlBURktrNVpWRWZl?= =?utf-8?B?VjlZaTlxMjZIazdSM1ZzMW9YUGtqUkRkeWxGenRJL3JKMVg5QU9KUDVScnJp?= =?utf-8?B?bHRQMU1YcExGSEtjZWdDdzN5OWEwRWFjM3FxSm1JZW1Lem01V0lBNmVUSDBw?= =?utf-8?B?WUtjZnRoRWlRV1N0eTM2VmdaWGN5SlpOdXVLZkRTVHZhcjJiYUxJTTh1RlU4?= =?utf-8?B?VGNITkc1VGJ5WXFDb1VuZE1kVkRPblU3eXBkdUtkUVplUTAzOTBkeDZXSkNj?= =?utf-8?B?ZENXZzhqYmt3TEZlZ0RpMTVMT2JCN3lrbU5Hczlyb3FDK1BORi9mWDNyTjlH?= =?utf-8?B?STJLNVViWGxadFNRWUZDWFBkblp5cGtXRHpJU0dmcDVPb0xHbS9tZld3VkNk?= =?utf-8?B?U2ZWLzlqanFiWEVQSHJjU2puNlRwMTRXaVQvRDJIRnZFOC9LNFc5SzZqblpx?= =?utf-8?B?elowVGw3eFdTZWdDSUQzZ2tQemJmOVR3Qk5ZMS9hdkI1TEFHZVZDaUhxUFQ2?= =?utf-8?B?aldSM201WlBVSlQ0cFNwZmZ1NFpHVlV2cXFQLzRhNmxHMkdacGFLWjlvTVNV?= =?utf-8?Q?GuD+xyMX7MqwiuI7g1anw28iFb2BWkmxZtF1dzT?= X-OriginatorOrg: dares.tech X-MS-Exchange-CrossTenant-Network-Message-Id: 510b4de6-54a7-44cc-779b-08d9355a2d68 X-MS-Exchange-CrossTenant-AuthSource: DB7P194MB0459.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2021 08:46:07.6424 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7f455517-e1d1-41dc-8637-685b5d7585e3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7J+5Gdc4NFQm53rpka+89+SMVIloTOUqG0UtVxeNuuVggZMzh1mXhZ7DOa3nDzn10nprvolSOe/1I7/lPFGK0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2P194MB1566 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 15M8kGVp009259 Hello, I have noticed that during the first minutes after boot, the libssh2_session_handshake execution remains stuck blocking the execution of the program. The code is intended to send a file using the SCP protocol, and it's based on the scp_write example. Is this a known issue ? Do you have any possible suggestion to determine the cause of it ? Thanks. Simon _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Jun 22 16:25:14 2021 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 15MEOWcr032469; Tue, 22 Jun 2021 16:25:02 +0200 Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 15MEORSV032445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 Jun 2021 16:24:28 +0200 Received: (qmail 12620 invoked by uid 1000); 22 Jun 2021 14:24:12 -0000 Message-ID: <20210622142412.12619.qmail@stuge.se> Date: Tue, 22 Jun 2021 14:24:12 +0000 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: libssh2_session_handshake remains stuck References: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 15MEOWcr032469 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 From libssh2-devel-bounces@cool.haxx.se Tue Jun 22 17:37:18 2021 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 15MFb1KS009996; Tue, 22 Jun 2021 17:37:14 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05:0:0:0:700]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 15MFavvq009955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 Jun 2021 17:36:59 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cyNDGK6OuB2UiXTBc5H38SjRXdBwMjG/dufBZ9pJpMzuxeJCdi26NrNGCJwS+pRK48qN0xR0AzcOsrdPsfx98THhYm2bjQzXxoXpjS8mm8D4I6AuSi+e1Uc+BW5rb5ufqKgcTU6DhQkvdGlVpJbEHF7yOXHoPaGCpeAVR51CmHmIjmdA63xTvMPHB/Bd8p0ycfl5e8KNirPH46JXDoBAnA390BroEUYbJzUlkT+xGbKo7FaYTmiReLYFD1Tlh7cAqtO40mgIgquruwhNSmglG/RfN6ceL4ZgHjxk7W1fyBEEKESalDSoXiTDv/tZgPVryzCdYAI7fPlxqknv5xKTmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QjJM7mcI8LdjQ5LAfLRgko/G+UsIHtl6U5DQCq3XszU=; b=WktgxzXq33zvQrviMsQV+c/Ggr1cR8Xiz6FOV3g2TMduYA2vw6etNFw/s1QvhkTB1+/rdvQS74cXQ7wo8zZ0N0bVKWnr5nGVlYluoVSHLxD6yKHpHy6Md8E8ajaPq6YUWv0MDfkuXOA1s09+7GXdknKEcmR7E1pXYNtZDzDhxEKzG7yvjUJED0UHDqigXuigW3hT9rhBIENxQQaoYQW9s15vDvWuIxHv813SPwYnzGuiw/8391p/rH4kTxS0EBORxdSrc6LSTudk1P/JvReZqpl1rNEIEquVBB3jTMOcDwSDMh4WNUL+rSovbV8RibUfQnCdHK+F6EZA9D+tvVFCQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dares.tech; dmarc=pass action=none header.from=dares.tech; dkim=pass header.d=dares.tech; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=B66557844.onmicrosoft.com; s=selector1-B66557844-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QjJM7mcI8LdjQ5LAfLRgko/G+UsIHtl6U5DQCq3XszU=; b=ri7h57DSgejHpIeqR3Scbljx41Yr7+WF5DANB6zujbwCIXTtLawdO0bFViKGytCHmEHjDjsgdZBr0F6v+Dbxj2VLAOKbrsZ3ap5gsYeseSztSDXwdDzc1CEqSZt+ktA34cBYZVwR7DGZR0qg9M8PGWkoDrjXBorq6mvwYK3Ze34= Authentication-Results: cool.haxx.se; dkim=none (message not signed) header.d=none;cool.haxx.se; dmarc=none action=none header.from=dares.tech; Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) by DBBP194MB1178.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:1e7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Tue, 22 Jun 2021 15:36:52 +0000 Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121]) by DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121%5]) with mapi id 15.20.4242.023; Tue, 22 Jun 2021 15:36:52 +0000 Subject: Re: libssh2_session_handshake remains stuck To: libssh2-devel@cool.haxx.se References: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> <20210622142412.12619.qmail@stuge.se> From: Simone Azzalin Message-ID: Date: Tue, 22 Jun 2021 17:36:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: <20210622142412.12619.qmail@stuge.se> Content-Language: en-US X-Originating-IP: [77.208.83.171] X-ClientProxiedBy: MR2P264CA0019.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::31) To DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.8.101] (77.208.83.171) by MR2P264CA0019.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18 via Frontend Transport; Tue, 22 Jun 2021 15:36:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 39bcf060-68e9-4e0d-7be1-08d935938ed1 X-MS-TrafficTypeDiagnostic: DBBP194MB1178: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YztvzeqGYrE+dayTwaO4KX19UorMPemYFJxBPg3NoqKLUbZCzRqcu44LXOFMVLLHg5ZcaQuMM69zwMDPpaVGMTOe2mK2XqSASItqzEUhBP2v8WvdopOwKcCtqmQ6LXud+c7spNvoYXT3vCofEAgonVM9+g74vqGYo3QwBKEUY2+dycjVYQ6VDYaKeSsJ4hbwxsdzidFmViLfv8TFfT+iqGFZOZg2UmC6dhO8DcCQNUIExDrJCitefXhgXekKB3t4bZDMchUY48lXO/zmMp98cNPcRP7JdF2d92MAc8F7RPBhx7Jnk44EmjqnQ1rqxiULZ9kY9+pQQlhBh5wwHsytBgeVnHFiBeL8M7QyO2UpA7dC0iEKV+iQhwpNTVRnUKp5RyKUcnErz4YY0c3tpF7Aw9DESSzMd46KQzpuczlP+gq3XBQ6kSw8bh2EqZ+yXE/lODgpRA3DrzONWY4jgEVP8KyXEYXLvpw/gEgOIlw9IL8TaHPsjbsnoJ8wiYiM/8jqSJqqU6a1zmgpkelESypaNoJIlNl5NX0lpD4rPTE1V7Y50UnCETZ/K5yvaFmWMFNqexoRfQGf+fqrnPqDn2kEZVDp22wdKK1x37E5kP7HSgwz6ly2EtzifaEP8sTr0dpa0aYQsMZCcNbIXNHFVrijkHGZ13PoyKp/c6xd/en3qeT7nd0kzgYt4QQaBQJzl6WqsJN7ANFW09mHci9yX7PItcB1Vx73KLXmjBwHVal2AbNS7sEURVPSVY33LkRJ4r5a8S5zk7U/L1IqfsqlPm6EnYqK8pUf5aIv1+l4XKexYh66KRAE2WsWvA8IKP331ebR7j5ZUAXicYyWbsWz7VrV991vgQotifBJ7qd6gkGU08/GJPIufqo9B4Nvm4eW65Kv X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7P194MB0459.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(16576012)(6916009)(508600001)(966005)(956004)(8676002)(83380400001)(5660300002)(7116003)(7066003)(15974865002)(6486002)(2616005)(166002)(36756003)(66556008)(66946007)(16526019)(86362001)(38350700002)(186003)(26005)(31696002)(53546011)(8936002)(66476007)(2906002)(38100700002)(31686004)(52116002)(33964004)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VWY2TThVOENVVlorN0hwRE1vY3R6dm9DRzVvdWNRTzZBRnM1QkhwSW1mZUNS?= =?utf-8?B?WjBIdUU4ZXZPS05ManI3SURDZ1pva0NlNGlCNVNVVzQ0d3NQVnh4ZHB2QjZq?= =?utf-8?B?TEVoS29SejFKWit4bTE1ZlVpQXJXR0JERGZhVndCblN0amM2R0RuQWx3cHNI?= =?utf-8?B?YkhKZzJYajVBdi9zRUdnVjV5OVcyd1IrQW9FQnFIajRCZElCNDNKcHhBekIw?= =?utf-8?B?ekU4RVZlYklXTGxTTnRZcEtNU2ltUVk1aU0wQ2tiWGRYNHQ4V0Z6SW4wL0JC?= =?utf-8?B?YkJrclgzMldkOW5FdlZSM3orbmVveWxkbVNrTjFub2FVWkZLZFRlMkp4VEhm?= =?utf-8?B?UE1xWkVDQ29Ra1BESUdUK0FaaXVsb3QxNzhUT3F2dDdRWkMrOXNMbnlIdVJy?= =?utf-8?B?ZXlpTnlIVlhFMmdjWGlqQWNGYXFVdTVHbmFwUWE5R1RWS3U4cmlmNTcyWkFz?= =?utf-8?B?VktEUFNZTlJHZzdqOWNucmRKeHd5VW4rS2d5VVVBbTV5c1NiUFRoby9WTUpK?= =?utf-8?B?NmlScmJXTHJqVnhJbzZlbE1Cd0lZVnV3R0NCakNwWGlDcU9NQk5lcWpGd096?= =?utf-8?B?T2k1VjJVbUN1SzkwSWkwZ2ROczVaVWdWVElnTXo4aTNXT2xONGFpcGJlWSth?= =?utf-8?B?bm41Q3VOdkg5MWdqSFpNSGI0d0VXbHFWMnNFTkREQlRHWGFISk15SXdYdzhF?= =?utf-8?B?cWsvaWZXYmpieFNoWHVUa2NvM3Rydnd4VVM1UE5uaXJ0UyttWWNjcWloNzd4?= =?utf-8?B?N3BnYm1EclhxQXNQdGRleEFEbjFlMGFIcDZJSnhuUlFjb2dFaDZlbW44T0I4?= =?utf-8?B?TXR5Yi9kY1Q5blU1NzQwTER4VENBNDZBZGVCNjFmazY2NklSM0FNeFI0NXdI?= =?utf-8?B?cEgwWnRZR3J5YWw5Q3YrK2tTWXpNUDRxRGZoMno2TXp6amNVVkpWWVkvUHNw?= =?utf-8?B?Y1lZcmtudjdrQlN4K3RkT3hEZzR3L3JUMXBmaGc5d3FkMFBDbkpWVEdJSTN4?= =?utf-8?B?VDVpeGZPRU9TQXd1SmY4Q0hncGtrOTZGMTNCZXFEQkJzVjdKZ0JYcUtaZUxl?= =?utf-8?B?YmlJQ1NndnRNdTJPMENGZkhwZUhPUERscU9qSTJ4YnNhZ0FMbVpXRkU0YytW?= =?utf-8?B?ZG80b01rUVlwVFdlTngxNTRKMTFSUUNBdEM1M3ZpNW9jV1h6T1Bic3VjSGQr?= =?utf-8?B?azJ4Rkl0ajlib292MU9RdWRrRXB3LzRaNEtvVVlSdkxLc3FNRkhnRlNhT2dJ?= =?utf-8?B?dlZxS1FuODhCN3V3dTJqNEk1dmJsSC9vK2lQc0duY2JGT0JSdy9WUnhkQ21K?= =?utf-8?B?V2FXdE9SaitxaVIwUkpyS1E1dldORDRra2pPdVpYM0lJcFRIc0Q3SExLQi9D?= =?utf-8?B?YWxYemk5cTgxZlhhdElyMUlJbFZyZHdWcWRiWjJXQzE3M2Zya29CckdXNkM3?= =?utf-8?B?YWxja05Ta0w5VVdnQ1Z5S3RGT2dYVkRPUjgzUWdFYkU2MTQzR1gxMjNZMEsr?= =?utf-8?B?T3JndUFqZnJJV05oUjEyR1llRVFpbVlDcmo4eElhcG9Ubkx6aHArMjRic2t5?= =?utf-8?B?WEZjeFZ6Rzh5WmtnS094cVF0LzY1ZHYxemJMUVFkMzBYTEZ5MWJSMFA1N1pz?= =?utf-8?B?RllsOUpWbVl6TEZUQ0ZpYTRPMzdZa3p6aFdNaDRkLzNOYzZjbEM1WEVhNWZa?= =?utf-8?B?YWwzNVQxSFlJc3g4S3NpL3ZVaGJvdVNaaE9IK2dxV0w0RDNMY3pVUTd6dDlJ?= =?utf-8?Q?QK1tHQT8IUe+VeNYUo9yTfAn7xXE0dV5CqoicYA?= X-OriginatorOrg: dares.tech X-MS-Exchange-CrossTenant-Network-Message-Id: 39bcf060-68e9-4e0d-7be1-08d935938ed1 X-MS-Exchange-CrossTenant-AuthSource: DB7P194MB0459.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2021 15:36:52.3772 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7f455517-e1d1-41dc-8637-685b5d7585e3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: m6IdThK5qZAQ96uE37LgbbtKj2+JS7z5+X+mAdgSKf+f2sfwMogvFNd/iZ7CRtJkfQwOTBPY7lqprgKPodbJcw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP194MB1178 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============2119589819==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============2119589819== Content-Type: multipart/alternative; boundary="------------2968906D226E7FCB3B4688C5" Content-Language: en-US --------------2968906D226E7FCB3B4688C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 | sazzalin@dares.tech  | www.dares.tech | Legal notice --------------2968906D226E7FCB3B4688C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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 | sazzalin@dares.tech | www.dares.tech | Legal notice
--------------2968906D226E7FCB3B4688C5-- --===============2119589819== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwczovL2Nvb2wuaGF4eC5zZS9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbGlic3No Mi1kZXZlbAo= --===============2119589819==-- From libssh2-devel-bounces@cool.haxx.se Wed Jun 23 16:42:05 2021 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 15NEfQO3007404; Wed, 23 Jun 2021 16:41:52 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10121.outbound.protection.outlook.com [40.107.1.121]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 15NEfO3u007394 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Jun 2021 16:41:25 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hCpNPks0lMt7DkMYHTZ+LBjDxtE6I5yUWrvrsu8jgMtaDcYP4Z9jct50/R2ccvBHlQgNNz6WNOztzyLBNWbfdRSp+rHMqJcO2VdPA+MolHMm027MS5LzAfZJzHZB2RsqMReuTKxiXP9O9I+83FNwykj6sOO2KxNMMZ8DvwuxlGkuApvZcfUGQTe6YNU+PGxOP4ib/jedfpxidogcFLtz9n8IawvxppMaiRxvqZS7v2kfnCe59ewJBOvo2yOKJ33tN9vK37h8XFPWAd3Zu4DpsHHVh1lR85/KWYr/gFeRek6PI32cPoLaQlrbh/o3f9lqiDFWK0EKpq3nAnRz7Viczw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kg8Q+oJpGmMHTmY/KaJnF0C8vmlZh1PgylL+t+Tz58I=; b=VGxtVf6IDC9899bxXc7Zxj4aa+uTpDAutOcSsgoAO/4Jh+npcZFnpodb8NYnFSfskoPtcjYViPhfW2pwt8c5nuiEEFM9uln1CK7Mxh5N0dLnk1M/dRczg6+PEFLSDqlRLCxQHJerkMEbYf0k+Mm2YK3FE99vyTPckmfN1o2ERncjA1wsKypfjePsqnll/Os/d7O/PiBbmr+WPCKY0b9udkJms6bm2j9o/IiXDmpS+D6S0AhTJ5X4biivMaKmhSlltXD8LHo9xEfyfIp1ZZt4J7qGWuWom3c2r9igX9Xik58IWAWUnHTbKSCW/9axAKXE/HNOQRyrSaxK3bDDifJLCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dares.tech; dmarc=pass action=none header.from=dares.tech; dkim=pass header.d=dares.tech; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=B66557844.onmicrosoft.com; s=selector1-B66557844-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kg8Q+oJpGmMHTmY/KaJnF0C8vmlZh1PgylL+t+Tz58I=; b=eBqS3zo3PSvOyxeWTsJiKgI5dBEyGEFpg0GOIH9ZIdXyAMy15Hggo8CbEGqlOziF79LebK8BQ9WkL+Uc0QVC+yk6Ule2ibkRCNK0i+1t9Oe6HWEBfrMFHfjHSwsp4RmW9VEQ80ZgezegVajpaaa82uRb9+XEYlvtd6zT8xwLRl4= Authentication-Results: cool.haxx.se; dkim=none (message not signed) header.d=none;cool.haxx.se; dmarc=none action=none header.from=dares.tech; Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) by DB9P194MB1290.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:29b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Wed, 23 Jun 2021 14:41:18 +0000 Received: from DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121]) by DB7P194MB0459.EURP194.PROD.OUTLOOK.COM ([fe80::249c:8978:5ca5:6121%5]) with mapi id 15.20.4242.023; Wed, 23 Jun 2021 14:41:18 +0000 Subject: Re: libssh2_session_handshake remains stuck To: libssh2-devel@cool.haxx.se References: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> <20210622142412.12619.qmail@stuge.se> From: Simone Azzalin Message-ID: <10828501-fac3-6e08-aab4-faaf06d55d89@dares.tech> Date: Wed, 23 Jun 2021 16:41:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [77.208.83.171] X-ClientProxiedBy: LO2P265CA0266.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::14) To DB7P194MB0459.EURP194.PROD.OUTLOOK.COM (2603:10a6:5:22::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.8.101] (77.208.83.171) by LO2P265CA0266.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Wed, 23 Jun 2021 14:41:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0b8ca4e6-95db-4053-3674-08d93654f5f4 X-MS-TrafficTypeDiagnostic: DB9P194MB1290: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bKdijxw0do6xOlcnDWbw/QmJIrz9Ss5vfS+mkfpYFw16K9hszRshtelsck6sHHbfSxfyEpl+IO32KEaIL7TuVN9RiJ8e/bupQ3+glx90uyXOcR0AZWVRP2gx1MQ4RUJEeSDRyn5JvehEhxwqehckdXdImKlu0hCaGgIN7CieZAiovo7LoWQAtPrcqTyZPcK7AEuMUYLrXeVX6jR3IQDEYydFnlgDSgC5JjZ+PmeUs4wG3bys7s2TLdei0sYdpQgDNYOWcfvoVGxnQoV0QdZeY9pCbIXCQIXsGLTcpKhl0PijbbMbp7YV5Ck7yoodprzdB0F95p7QHfWJEZzNMbMT8NvtCu9ukq1jcU8ryfO75mSKP8h00e/mM+xhbW39ocoh6WJojjdW5lV4m0R7BitFS6W1AnvX1g/MEHgMOrMea8CSszMizGe6+YpnRMhxKZJOL42/CiQSECij/TPnOXKJkgCYpf0rmcPbtggsE9DJnznuzUpuC3Wcf5EeXfsmYxFZ28Bi1enM4MeUQqURhNP/VbfQBGaj2zDsGE0C8nKQlE0C8VV77mNhldeG3t6lYYGr4alc66pAqFVVnzR2heYLzVqPvCKIswTEspmtEtPlM+KNnhEztAOdwr0hOR3GPFR8gzSHUky3opI4itCszYu2NDyHsj3ux2lBaTHq5ODi+N+JHF+DF7tX30CX9PaUhkU25uuRnbIunBeNDTDtDNHYGmxBceu+vtUHzWKKcTgmicDBaCIT+1iGts7c9nj7QKzqJ4XcPR5rWssUTCWOB4WGgCxlhp9xxtX0dEefduXH7Im2xcGykJvmZLuOvWrVvBdsDktgsU6QHff7eMJnziBwAFX4js+mzbyyimCZwCK8869Uo4eq872dTo8koKASJD+1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7P194MB0459.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(396003)(366004)(346002)(136003)(376002)(16526019)(166002)(6916009)(52116002)(186003)(956004)(33964004)(15974865002)(31696002)(5660300002)(2906002)(2616005)(26005)(36756003)(6486002)(316002)(53546011)(8936002)(31686004)(7116003)(38100700002)(38350700002)(86362001)(83380400001)(16576012)(66556008)(966005)(7066003)(478600001)(66946007)(66476007)(8676002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Mm43UDJ0ZWtiR3lmdWdTVEZPSlpuM1FZbC9Qb01MSXFIa2FleTJ6eGw4T09L?= =?utf-8?B?cDB2RHVwN29HdHNjMGpJZGpWQklKVHkySExlZWFTNER6eWNXV1JQQUtZQ0VZ?= =?utf-8?B?Y2YwbHBaRFNCMlJFNk41MWdGWldXekpWc3d6YnMycHlZamxBRkdYaVR3UUhl?= =?utf-8?B?SVl2dWQ0Skk5cHpNR3FqaTNvd0FFOUJjRkRnai9acmVZQXVmUFlNVURzWUdG?= =?utf-8?B?cVJNTWVrRXEzL3RHVzNiZVJ6UStlcnl4Rm12bUNxMVJoMENWclhtYXlBSzVH?= =?utf-8?B?OFd3Y1E1UTZRTC9FWTQydUU3QkN6Njg1VHE2ZG8yZWhjektLc0M3dkN0V1BE?= =?utf-8?B?ck8zcG05OXdKVUYxMFZDSzAyRUNkblJZc2VJbUNxS1l0Ri80YWdjTFhJK1Ux?= =?utf-8?B?VVNnaVJxdElUMWFaUE9BM3hwM24zZGQ0eUR1Q3J1R2FBQkVUczlTM3ViQTBV?= =?utf-8?B?TDI2OWw4UE5HaTNOY2k2cGR3S1UzT1hQNDUvOHRYQ1ZjQ3FqYjQwTlkvSG81?= =?utf-8?B?djMySDd3YkFxMEM1a05PZ1UxdUh0SU1hNXVaR256Z2ZXM1dnU0tRYmVvS0Zx?= =?utf-8?B?dGlYclVsQ0thVHFBUEwwcXRwTGg1QjlqOEVFK284N1JLOGtqOUEzenE2Zi81?= =?utf-8?B?T1FnaEc4ZFZ0QTg1dGJzWTRBRzBSWHFlNVZxd3BLcVRTVXJCOUw1MFhLbEdn?= =?utf-8?B?eENQbE1jUlRNQU1VRlBBR2hYbUhSQVlxV1cxOUlBMWN1QU9HSVJqNlVmZXVp?= =?utf-8?B?VTFpeWJLWVViMUlvU29aSjlYcC93czdFTlAyRTZnRXFRQ2FBbXhxbkRaZTcr?= =?utf-8?B?V0RobDVMQ2FiZEs0c2dMVFJjRldkcmFTWmtBRnVHTEVnS05iRlkwbm1oaXZS?= =?utf-8?B?MEJhNVA3OXBCai9hdUVVWDA3dC83VXBXdTVCU25YZE1adUYzZkJkRnRLMnUx?= =?utf-8?B?eE5SSlBZRmY2WnZqTHFNTUEwbGxkZ1Nuc0I0d0U1N3l6Tk9KRFhFbDNuS3k4?= =?utf-8?B?ekRCSFU0T0dHcnVydXc0Q21Pc3l1SFNLMkZZaEUwNkRzUFpnbjRSUk95a3JP?= =?utf-8?B?QWpiZ0lFTFVDQ2JKbHpNYjVoa1ZpazhBckE5Tk5VSEJjOTJPcXpoR0RtL1RJ?= =?utf-8?B?Y3hTdE1iTVNzeWo3dzZmL0d0ZnVjVjU4aWNhc2l3Y2Njeko3TkZ0WXBGYWk0?= =?utf-8?B?S29tVFRJSmFOSXhCZ3YrRlN0WTF5L3hIZm1oZ0JITk00cmgwQXR5WlZYdzVM?= =?utf-8?B?N01PVFJ3L1VzQXR3TUJoZDhlM0dvSGs5a3ZzY2p2RmtnRWlkK2xVV09nWW5l?= =?utf-8?B?dDBveTlnSFM0SGVpazlWa2VENndFajlVc2QyL3NYajROM2Jnd3EwT3ZESHZ6?= =?utf-8?B?MllsWkc2WENiaUovR1QwN0t5VGpKTU9KT25Vb0gyemU3ZDk3Wjh4aEltRVdz?= =?utf-8?B?UVV0NkNxQTBaY1pMTnlHL2k5a3ZPMzd2YU9yL0gvdDVMZkZXR2JWMmhzTHBE?= =?utf-8?B?VXZLNmgzQ2p4bm9pbGlkK0ROY2lZVXFCMHlNeURiQktFTXFqOXJRUGJxUC9P?= =?utf-8?B?Ulp3STRvd0lHUFFyTCt4NFMvMDZBdllwRER1eHJIdkpTeC9pOFlXT2pnZEhP?= =?utf-8?B?ZE9ZUXhvN1g1em9hRk5XWUlZdUduTGFRWVY2aUhyeDVSd2xrd1VSYWczTlE2?= =?utf-8?B?UW1CVTl5TnRzM29NSEFUa0E5UW4yb1VrY3NvZVppWlJPYjhhK05OcFVEQ2JL?= =?utf-8?Q?MRoUWoLgCqo+7qymq7B/BddzOzQAAAj1LZ7iyVm?= X-OriginatorOrg: dares.tech X-MS-Exchange-CrossTenant-Network-Message-Id: 0b8ca4e6-95db-4053-3674-08d93654f5f4 X-MS-Exchange-CrossTenant-AuthSource: DB7P194MB0459.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2021 14:41:18.2600 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7f455517-e1d1-41dc-8637-685b5d7585e3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qn6lP1usq2wVzQT2ya3g0kiHZtXdlqgvZu6E2jZnOGW7U+jBmXCG22dJZmHsLKzcNUYWAkXOhgz7iLNFd09Ydw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P194MB1290 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1416656027==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1416656027== Content-Type: multipart/alternative; boundary="------------676A38719803566293BFC325" Content-Language: en-US --------------676A38719803566293BFC325 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 | sazzalin@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 | sazzalin@dares.tech  | www.dares.tech | Legal notice --------------676A38719803566293BFC325 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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-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 | sazzalin@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 | sazzalin@dares.tech | www.dares.tech | Legal notice
--------------676A38719803566293BFC325-- --===============1416656027== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwczovL2Nvb2wuaGF4eC5zZS9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbGlic3No Mi1kZXZlbAo= --===============1416656027==-- From libssh2-devel-bounces@cool.haxx.se Wed Jun 23 19:57:56 2021 Return-Path: Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id 15NHvQFw005704; Wed, 23 Jun 2021 19:57:50 +0200 Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id 15NHvO9N005693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Jun 2021 19:57:24 +0200 Received: (qmail 22544 invoked by uid 1000); 23 Jun 2021 17:57:19 -0000 Message-ID: <20210623175719.22543.qmail@stuge.se> Date: Wed, 23 Jun 2021 17:57:19 +0000 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: libssh2_session_handshake remains stuck References: <3a0701d0-a5c9-8af8-450b-6ed948ae3f06@dares.tech> <20210622142412.12619.qmail@stuge.se> <10828501-fac3-6e08-aab4-faaf06d55d89@dares.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <10828501-fac3-6e08-aab4-faaf06d55d89@dares.tech> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.22 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id 15NHvQFw005704 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