[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] [PATCH] Improve handling of SSL/TLS alerts with GnuTLS.
From: |
mancha |
Subject: |
Re: [Bug-wget] [PATCH] Improve handling of SSL/TLS alerts with GnuTLS. |
Date: |
Mon, 06 May 2013 09:38:09 +0000 |
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
- Re: [Bug-wget] [PATCH] Improve handling of SSL/TLS alerts with GnuTLS.,
mancha <=