Re: [Bug-wget] [PATCH] Improve handling of SSL/TLS alerts with GnuTLS.

[mancha]

Hi.

You are right that GNUTLS_E_WARNING_ALERT_RECEIVED is not the only
non-fatal return value. In GnuTLS 2.12.x there's 
GNUTLS_E_INTERRUPTED,
GNUTLS_E_REHANDSHAKE, GNUTLS_E_WARNING_IA_IPHF_RECEIVED, and
GNUTLS_E_WARNING_IA_FPHF_RECEIVED.

My patch only addresses non-fatal *alerts* (a subset of non-fatal
errors) so theoretically the loop is logically equivalent to:

do
 [code]
while (err == GNUTLS_E_WARNING_ALERT_RECEIVED);

My first version of the patch relied entirely on
gnutls_error_is_fatal() like your example. However, I decided
to narrow down the scope because I didn't feel familiar enough
with potential side-effects of ignoring other non-fatal events.

As to re-handshake requests, wget doesn't handle those (something
to work on).

--mancha

On Mon, 06 May 2013 08:24:50 +0000 "Tim Ruehsen" 
<address@hidden> wrote:
>Hi,
>
>thanks for your work to improve wget !
>
>Are you shure, there are no other non-fatal return values ?
>e.g. GNUTLS_E_REHANDSHAKE
>
>AFAIK, a GnuTLS example that also uses a handshake loop, but 
>relies completely 
>on gnutls_error_is_fatal():
>
>// simplified version without timeout handling
>do {
>       ret = gnutls_handshake(session);
>} while (ret != 0 && !gnutls_error_is_fatal(ret));
>
>Regards, Tim
>
>Am Sunday 05 May 2013 schrieb mancha:
>> Hello.
>> 
>> wget, built against GnuTLS, terminates SSL/TLS handshakes
>> upon receiving any error alert (including non-fatal ones).
>> 
>> This creates a problem when connecting to servers that support
>> TLS-SNI and reply with a warning-level unrecognized name alert
>> (eg. due to misconfiguration).
>> 
>> My patch changes wget's behavior to ignore warning-level alerts
>> during client/server hello and provides more detailed logging. 
>The
>> patch's compound conditional is not strictly necessary because
>> GNUTLS_E_WARNING_ALERT_RECEIVED is non-fatal but a check on the
>> latter is included as a fail-safe. It applies cleanly to
>> address@hidden
>> 
>> Ignoring non-fatal alerts during handshake is consistent with
>> Firefox and Chrome behavior.
>> 
>> I set up a server to replicate unrecognized_name alert 
>conditions:
>> 
>> A. Current behavior:
>> 
>>    [warning-level alert]
>>    $ wget https://localhost
>>    --2013-05-05 08:18:35--  https://localhost/
>>    Resolving localhost (localhost)... 127.0.0.1
>>    Connecting to localhost (localhost)|127.0.0.1|:443... 
>connected.
>>    GnuTLS: A TLS warning alert has been received.
>>    Unable to establish SSL connection.
>> 
>>    [fatal-level alert]
>>    $ wget https://localhost
>>    --2013-05-05 08:20:52--  https://localhost/
>>    Resolving localhost (localhost)... 127.0.0.1
>>    Connecting to localhost (localhost)|127.0.0.1|:443... 
>connected.
>>    GnuTLS: A TLS fatal alert has been received.
>>    Unable to establish SSL connection.
>> 
>> B. Behavior after patch:
>> 
>>    [warning-level alert]
>>    $ wget https://localhost
>>    --2013-05-05 08:01:40--  https://localhost/
>>    Resolving localhost (localhost)... 127.0.0.1
>>    Connecting to localhost (localhost)|127.0.0.1|:443... 
>connected.
>>    GnuTLS: A TLS warning alert has been received.
>>    GnuTLS: received alert [112]: The server name sent was not
>> recognized
>>    HTTP request sent, awaiting response... 200 OK
>>    Length: unspecified [text/html]
>>    Saving to: 'index.html'
>> 
>>    [fatal-level alert]
>>    $ wget https://localhost
>>    --2013-05-05 08:03:27--  https://localhost/
>>    Resolving localhost (localhost)... 127.0.0.1
>>    Connecting to localhost (localhost)|127.0.0.1|:443... 
>connected.
>>    GnuTLS: A TLS fatal alert has been received.
>>    GnuTLS: received alert [112]: The server name sent was not
>> recognized
>>    Unable to establish SSL connection.
>> 
>> Cheers and thank you for wget!
>> 
>> --mancha