From patchwork Tue May 12 22:05:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Jan_Ekstr=C3=B6m?= X-Patchwork-Id: 19659 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id BDE0844A3BC for ; Wed, 13 May 2020 01:35:31 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 983EB68A16F; Wed, 13 May 2020 01:35:31 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7843F689AE3 for ; Wed, 13 May 2020 01:35:25 +0300 (EEST) Received: by mail-wr1-f67.google.com with SMTP id e1so4133743wrt.5 for ; Tue, 12 May 2020 15:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=rP/S9nSKe6dzHL2j4GiNRAhvm5mYRIvkR1VLFUJd7vo=; b=OrMeBqZdkg1/DAkBKWEZk7vKyUmwbz3Zy+YOAo2X7ZQTHizSMoG9ynEkZVXmLkdurG cVhvdko1Z83TyyNCVYZdoiL6V/8bO5YrcnRKTKp9MLe658lNhkn2VGETP2gDpK2v2eM3 GfeBLk5MrADLjlgEmFrMiraPuEFv3GPSz/qLi0lBrfmTlrwSrLdSCAZdsCcbxAD/Ag6v W0DtHuaU0U1FIkrYi33+g0cUyIP2au9Lw7D0+FEiBIDoOn5aBOGz7V236kCZabKLwYko 2Xz/7d8qOdoC1P1uy8v9EeJubZ7g9LJZnEE0okduu2K8XJLhOvXTf1vS9pDKIcbdpPEP 3/3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rP/S9nSKe6dzHL2j4GiNRAhvm5mYRIvkR1VLFUJd7vo=; b=Hk6xmQrIwA5hyYWKTsVpR8v9ojawRw9HxjxfukGh4lwzw17YFNUg/7AkL2Z/d5lxkW odftXYnXOIphNCi32wb6eWAbJehl2QgBhfXFFvU/n4x2Mr88uMF1MATgkIDAJXggSayZ VYf8eKzLTtFTPoDI8wIfze2mi1DfXBQMn+mUxs1w5y/SRT/n56FKaiVoXALF+a2oP5T7 oWk92f9xNCEWuNa90SB4Ik8ouWwK4Vfd4Xjx9VyGpIovKdwRldhmqPSmid1dlUNwLuLT qhgGdmD/Vn6NTXQk1cAlEOjoDx5eYZqsHZ6SdkbZwhIU6QyfDYDZiO4x4Gw8NPZfblWw r70Q== X-Gm-Message-State: AGi0PuZSQovoSk99W4V91vdahjA9iOx7qdbBdWN9xqUdmufbR3vEejNh 9hYMlmkrIeI6LFlIAmUa5Ai8WkvO X-Google-Smtp-Source: ABdhPJxC8B7kEb0Xavy5lnGi0yJdDSFNr70izxTqMsBjzEEwc2WKMlpM93po4hHES1x0Rr7Vr/UY/A== X-Received: by 2002:a2e:9094:: with SMTP id l20mr522253ljg.115.1589321128344; Tue, 12 May 2020 15:05:28 -0700 (PDT) Received: from localhost.localdomain (91-159-194-103.elisa-laajakaista.fi. [91.159.194.103]) by smtp.gmail.com with ESMTPSA id s11sm14858178lfo.86.2020.05.12.15.05.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 15:05:27 -0700 (PDT) From: =?utf-8?q?Jan_Ekstr=C3=B6m?= To: ffmpeg-devel@ffmpeg.org Date: Wed, 13 May 2020 01:05:24 +0300 Message-Id: <20200512220525.9911-2-jeebjp@gmail.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200512220525.9911-1-jeebjp@gmail.com> References: <20200512220525.9911-1-jeebjp@gmail.com> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 1/2] avformat/tls_schannel: always decrypt all received data X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" The dec_buf seems to be properly managed between read calls, and we have no logic to decrypt before attempting socket I/O. Thus - until now - such data would not be decrypted in case of connections such as HTTP keep-alive, as the recv call would always get executed first, block until rw_timeout, and then get retried by retry_transfer_wrapper. Thus - if data is received - decrypt all of it right away. This way it is available for the following requests in case they can be satisfied with it. --- libavformat/tls_schannel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c index 4f0badcb8d..7a8842e7fe 100644 --- a/libavformat/tls_schannel.c +++ b/libavformat/tls_schannel.c @@ -424,7 +424,7 @@ static int tls_read(URLContext *h, uint8_t *buf, int len) c->enc_buf_offset += ret; } - while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK && c->dec_buf_offset < len) { + while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK) { /* input buffer */ init_sec_buffer(&inbuf[0], SECBUFFER_DATA, c->enc_buf, c->enc_buf_offset); From patchwork Tue May 12 22:05:25 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Jan_Ekstr=C3=B6m?= X-Patchwork-Id: 19658 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id B671644B1C3 for ; Wed, 13 May 2020 01:12:36 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9999368A9F3; Wed, 13 May 2020 01:12:36 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C313168A8E9 for ; Wed, 13 May 2020 01:12:29 +0300 (EEST) Received: by mail-ed1-f67.google.com with SMTP id d16so12429716edq.7 for ; Tue, 12 May 2020 15:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=mT0fk7TVDY3Kr5oPpXBm98fzcZQ2kFQA2Nbf3I5QlbQ=; b=DmH6Qfs/JZoodC4WxT6VsT09LaW9FhXoYfWVa0FY8W1hfluRpi+/NLFd+fYMStNdJy 3l72AlN8dqe4qG9vYS1E35DvThuyQU++8zru431s2CMdGxmOoFYuYuMZd27vZPOAYxcq AGHTQBD+4KFwCBzNhXMSMnD6pctPvOiFuhqX2SXfLkdILqp1GWRBwsxykhsRCloHWwLy Gut+JfYfxXw53q6Dng4e62EoZudNzc3dZh6ORHjn92eAi/cqX2G6sdqKMYcLrbZLNryp PNk8dsoOhtFh0XxKxxShxFwbB8qsTeDMeeEz+l+ys9ilRzb0lVQsDuW/y/UF//7FV7jL yjlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mT0fk7TVDY3Kr5oPpXBm98fzcZQ2kFQA2Nbf3I5QlbQ=; b=AWkjOUrYZcPU1nLV4N/lKviCcny7dQDfuqN+kgAMz9eeKMwfVzjwXPYtjXIwjj9w7m eEJBO530cwMhCqEpI6Y3Q9y+sp31dWudK5jtzei0BYlapFofqKw2TPz/Kc5CY3BZ5z5e hDitWLhFNxQQb61atvRUv10v/YDW+mranBZLP51i6FyG1AVzhTkquxyMtwOg04SGFS36 SIjlJtr+LUd+j/MLZp/i+HWvV3ioHmBQJZjohOQRDmv0LAPPKGW6Q1wSFzMGI1LaMh1R xxKdWRmiJ0j89eIaSDahW9jUvtJJAJwXHOaA6k5IPUdpjNinJWRshpWpn4MF7p8sovEK f9OA== X-Gm-Message-State: AGi0PubRZHUI8kPzhDO+c0WqDmh8esGo/OI4ktv27xaYcHmDCEDn6Wky VEpxb1d/wrIYYE13/6SckWFRA83X X-Google-Smtp-Source: ABdhPJzuX/8UBEezXxsNABdPPtsTxq3/j6wwR07g9hmIE9E6eFFWqMxAOv7CHTSemRHo8nQfsOuCFQ== X-Received: by 2002:a19:3817:: with SMTP id f23mr15587396lfa.6.1589321129511; Tue, 12 May 2020 15:05:29 -0700 (PDT) Received: from localhost.localdomain (91-159-194-103.elisa-laajakaista.fi. [91.159.194.103]) by smtp.gmail.com with ESMTPSA id s11sm14858178lfo.86.2020.05.12.15.05.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 15:05:28 -0700 (PDT) From: =?utf-8?q?Jan_Ekstr=C3=B6m?= To: ffmpeg-devel@ffmpeg.org Date: Wed, 13 May 2020 01:05:25 +0300 Message-Id: <20200512220525.9911-3-jeebjp@gmail.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200512220525.9911-1-jeebjp@gmail.com> References: <20200512220525.9911-1-jeebjp@gmail.com> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 2/2] avformat/tls_schannel: immediately return decrypted data if available X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Until now, we would have only attempted to utilize already decrypted data if it was enough to fill the size of buffer requested, that could very well be up to 32 kilobytes. With keep-alive connections this would just lead to recv blocking until rw_timeout had been reached, as the connection would not be officially closed after each transfer. This would also lead to a loop, as such timed out I/O request would just be attempted again. By just returning teh available decrypted data, keep-alive based connectivity such as HLS playback is fixed with schannel. --- libavformat/tls_schannel.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c index 7a8842e7fe..4a1c5901d0 100644 --- a/libavformat/tls_schannel.c +++ b/libavformat/tls_schannel.c @@ -392,7 +392,12 @@ static int tls_read(URLContext *h, uint8_t *buf, int len) int size, ret; int min_enc_buf_size = len + SCHANNEL_FREE_BUFFER_SIZE; - if (len <= c->dec_buf_offset) + if (c->dec_buf_offset > 0) + /* If we have some left-over data from previous network activity, + * return it first in case it is enough. It may contain + * data that is required to know whether this connection + * is still required or not, esp. in case of HTTP keep-alive + * connections. */ goto cleanup; if (c->sspi_close_notify)