[FFmpeg-devel] [PATCH] lavf/tls_gnutls: retry gnutls_handshake on non fatal errors

[Jan Ekström]

On Sat, Jun 1, 2019 at 8:38 PM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Wed, Mar 27, 2019 at 2:09 PM Remita Amine <remitamine at gmail.com> wrote:
> >
> > fixes #7801
> >
> > Signed-off-by: Remita Amine <remitamine at gmail.com>
>
> This seems to fix switching the cipher suite, and quickly looking at
> the gnutls API docs this seems to be the way to do it.
>
> Just tested this with the following as I got a report that opening
> Facebook HTTPS URLs didn't work in a libavformat API client:
> 1. youtube-dl -g "https://www.facebook.com/downshiftaus/videos/418766325569703/"
>    (you receive a URL)
> 2. ffprobe 'THAT_URL'
>
> Without this patch the handshake fails (as there is a cipher
> re-negotiation?), and with the patch it works.
>
> Additionally, this doesn't seem to enable bad TLS configurations such
> https://rc4.badssl.com/ to get opened. Which is expected from the
> gnutls docs, but still I felt like testing.
>
> In other words, I think this is LGTM and since there already are
> reports from people on distros running into this, this should be
> back-ported to the versions still maintained by us (whatever those
> are) ?
>
> Best regards,
> Jan

Applied to master, as I consider this a pretty important fix and there
were no further comments in the span of two weeks.

Additionally, after checking wget's and curl's usage of gnutls, this
indeed seems to be the modus operandi. The only thing is that they
also happen to check how many ms are left towards the I/O timeout, but
I am not sure if we can effectively apply it here. Additionally, there
were voices on IRC that timing out in the middle of a TLS handshake
would be overkill and that fixing the connectivity issues should be
prioritized.
References of gnutls usage:
https://github.com/curl/curl/blob/master/lib/vtls/gtls.c#L332
http://git.savannah.gnu.org/cgit/wget.git/tree/src/gnutls.c#n476

Thanks,
Jan