9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] Http parsing auth (Was Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances) )
       [not found] <YTXPR0101MB12291D09D7F6F1D597CB4956E8F49@YTXPR0101MB1229.CANPRD01.PROD.OUTLOOK.COM>
@ 2021-08-21  4:40 ` unobe
  0 siblings, 0 replies; only message in thread
From: unobe @ 2021-08-21  4:40 UTC (permalink / raw)
  To: 9front

See below, which is a forward of a message I received a couple weeks ago.

The best I can tell is that the parser for lynx didn't understand the
authn part of the URI.  I think libhttpd doesn't have the same
problem--it just returns a bad uri, which is better than leaking.  I'm
looking at /sys/src/libhttpd/parsereq.c:/^parseuri .
/sys/src/libhttpd/parse.c parses the mime header, so it's not an issue
with requests that are sent with the authorization that way.  From
httpd(2):
     BUGS
          This is a rough implementation and many details are going to
          change.

Webfs(4) looks to handle things properly in parsing (
/sys/src/cmd/webfs/url.c ), but would still generate a URI that
libhttpd couldn't handle: /sys/src/cmd/webfs/url.c:^/Ufmt .

Questions: if my analysis is correct, should parseuri be made to parse
authuser and authpass?  Or is libhttpd not used as much and other
software is preferred?

Quoth Katherine Mcmillan <kmcmi046@uottawa.ca>:
> FYI
> 
> ________________________________
> From: Lynx-dev <lynx-dev-bounces+kmcmi046=uottawa.ca@nongnu.org> on behalf of Ariadne Conill <ariadne@dereferenced.org>
> Sent: 07 August 2021 10:17
> To: oss-security@lists.openwall.com <oss-security@lists.openwall.com>
> Cc: Axel Beckert <abe@debian.org>; lynx-dev@nongnu.org <lynx-dev@nongnu.org>; security@debian.org <security@debian.org>; 991971@bugs.debian.org <991971@bugs.debian.org>
> Subject: Re: [Lynx-dev] [oss-security] Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
> 
> Attention : courriel externe | external email
> 
> 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
> 


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-08-21  9:10 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <YTXPR0101MB12291D09D7F6F1D597CB4956E8F49@YTXPR0101MB1229.CANPRD01.PROD.OUTLOOK.COM>
2021-08-21  4:40 ` [9front] Http parsing auth (Was Re: bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances) ) unobe

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ https://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git