lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] [oss-security] Re: bug in Lynx' SSL certificate validatio


From: Ariadne Conill
Subject: Re: [Lynx-dev] [oss-security] Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Date: Sat, 7 Aug 2021 09:17:55 -0500 (CDT)

Hi,

On Sat, 7 Aug 2021, Thorsten Glaser wrote:

Axel Beckert dixit:

This is more severe than it initially looked like: Due to TLS Server
Name Indication (SNI) the hostname as parsed by Lynx (i.e with
"user:pass@" included) is sent in _clear_ text over the wire even

I *ALWAYS* SAID SNI IS A SHIT THING ONLY USED AS BAD EXCUSE FOR NAT
BY PEOPLE WHO ARE TOO STUPID TO CONFIGURE THEIR SERVERS RIGHT AND AS
BAD EXCUSE FOR LACKING IPv6 SUPPORT, AND THEN THE FUCKING IDIOTS WENT
AND MADE SNI *MANDATORY* FOR TLSv1.3, AND I FEEL *SO* VINDICATED RIGHT
NOW! IDIOTS IN CHARGE OF SECURITY, FUCKING IDIOTS…

It turns out SNI is only marginally related to this issue. The issue itself is far more severe: HTParse() does not understand the authn part of the URI at all. And so, when you call:

  HTParse("https://foo:bar@example.com";, "", PARSE_HOST)

It returns:

  foo:bar@example.com

Which is then handed directly to SSL_set_tlsext_host_name() or gnutls_server_name_set(). But it will also leak in the Host: header on unencrypted connections, and also probably SSL ones too.

As a workaround, I taught HTParse() how to parse the authn part of URIs, but Lynx itself needs to actually properly support the authn part really.

I have attached the patch Alpine is using to work around this infoleak.

Ariadne

Attachment: fix-auth-data-leaks.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]