Hi, On Fri, Aug 06, 2021 at 05:14:32PM +0000, Thorsten Glaser <t...@mirbsd.de> wrote in https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg00000.html: > this affects both OpenSSL and Debian’s nonGNUtls builds: > > lynx https://user:pass@host/ > > … will lead to… > > SSL > error:host(user:pass@host)!=cert(CN<mainhost>:SAN<DNS=host>:SAN<DNS=otherhost> > > … for OpenSSL lynx and… > > SSL error:host(user:pass@host)!=cert(CN<mainhost>)-Continue? (n) > > … for nonGNUtls lynx. > > Obviously, user:pass@ need to be stripped before comparing.
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 _before_ I can even said "n" for "no, don't continue to talk with this server" in Lynx's prompt as shown above. I was able to capture the password given on the commandline in traffic of an TLS handshake using tcpdump and analysing it with Wireshark: From Wiresharks TLS dissector: Server Name Indication extension Server Name list length: 28 Server Name Type: host_name (0) Server Name length: 25 Server Name: user:p...@www.example.org ^^^^^^^^^^ From Wiresharks "Follow TCP stream": ...........a ....jV.. ......../.......D.&....R.+.,..... . .../.0...............z.{./.5.A... .....|.}.3.9.E.............2.8.D.......p............$."...user:p...@www.example.org......#... ... ................. .............................. (PCAPs available on request. Actually did the test with a local server of mine. But it should be easy to reproduce, be it with any Linux distribution.) I did this test with Lynx from Debian Experimental (which has the current Lynx upstream release 2.9.0dev.8) as well as with Lynx from Debian 8 Jessie ELTS (which has Lynx 2.8.9dev.1) and both leak the password via SNI. I though assume that older releases of Lynx are probably also affected as well, at least if they or the according crypto libraries support SNI. But given that the symptoms Thorsten discovered stayed unreported for quite some years, I assume that this use case is a rather seldom one. Nevertheless only trying to use Lynx that way (and seeing it fail) already leaks the used password. IMHO this nevertheless needs a CVE-ID. Cc'ing Debian Security Team as well as the OSS Security mailing list for making them aware of this issue. I also updated the subject of this thread to make it less ambigous on other mailing lists. And I'm also Cc'ing the according Debian bug report which I created for tracking this issue in Debian: https://bugs.debian.org/991971 Kind regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature