1299938 – lynx does not support X.509 SubjectAltName extension

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1299938 - lynx does not support X.509 SubjectAltName extension

Summary: lynx does not support X.509 SubjectAltName extension

Keywords:
Status:	CLOSED NEXTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	lynx
Sub Component:
Version:	6.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Kamil Dudka
QA Contact:	BaseOS QE - Apps
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2016-01-19 15:14 UTC by Jeff Lightner
Modified:	2016-07-13 12:26 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-07-13 12:26:37 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Jeff Lightner 2016-01-19 15:14:09 UTC

Description of problem:
We have a monitoring script that does monitoring of a web page by looking for hidden text embedded in the source of the page. We have successfully been running for a long time the following command:
lynx -source http://www.<oursite>.com:80

However, on making a change to https as follows:
lynx -source http://www.<oursite>.com:443

We got errors:
Looking up www.<oursite>.com
Making HTTPS connection to www.<oursite>.com

lynx: Can't access startfile https://www.<oursite>.com/
[root@atlema02 ~]# lynx -version
Lynx Version 2.8.6rel.5 (09 May 2007)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.0.0-fips, ncurses 5.7.20090207(wide)
Built on linux-gnu May 14 2010 11:06:40

Copyrights held by the University of Kansas, CERN, and other contributors.
Distributed under the GNU General Public License.
See http://lynx.isc.org/ and the online help for more information.

See http://www.openssl.org/ for information about OpenSSL.

Version-Release number of selected component (if applicable):
lynx-2.8.6-27.el6.x86_64

How reproducible:
Able to reproduce on all RHEL 6 versions including 6.2 and 6.6. Able to reproduce both on our own site and on external sites such as comcast.com.

Steps to Reproduce:
1. Pick a site that has both http and https access (e.g. www.comcast.com)
2. Run "lynx -source https://<site>:443"
(e.g. lynx -source https://www.comcast.com:443)

Actual results:
Looking up www.comcast.com
Making HTTPS connection to www.comcast.com

lynx: Can't access startfile https://www.comcast.com/

Expected results:
Source output of the web page as one would see if specifying http and port 80 rather than https and port 443.

Additional info:
1) There appears to be only one lynx package for all RHEL6 versions. Online investigation suggests compile time options.
Running "lynx -version" outputs:
Lynx Version 2.8.6rel.5 (09 May 2007)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.0.0-fips, ncurses 5.7.20090207(wide)
Built on linux-gnu May 14 2010 11:06:40
Copyrights held by the University of Kansas, CERN, and other contributors.
Distributed under the GNU General Public License.
See http://lynx.isc.org/ and the online help for more information.
See http://www.openssl.org/ for information about OpenSSL.

I suspect issue is that lynx was not recompiled after fix of openssl heartbleed and other bugs. We are running openssl version 1.0.1e-30.el6_6.4 and latest is 1.0.1e-42.el6_7.2 but it appears the earlier version of openssl 1.0.0-fips is statically compiled in the RHEL6 version.
2) This is NOT an issue for RHEL7 lynx version.
3) Work around for RHEL6 is to use elinks rather than lynx. The "elinks -source" flag returns the expected results for our monitoring script but has not otherwise been exhaustively tested.

Comment 2 Kamil Dudka 2016-01-19 16:02:05 UTC

(In reply to Jeff Lightner from comment #0)
> However, on making a change to https as follows:
> lynx -source http://www.<oursite>.com:443

You should use the "https://" prefix for HTTPS.

> I suspect issue is that lynx was not recompiled after fix of openssl
> heartbleed and other bugs.

I fail to see why a rebuild of lynx would be necessary.  OpenSSL is dynamically linked to lynx, which means it is enough to start a new process of lynx to load an updated version of OpenSSL.

> 2)  This is NOT an issue for RHEL7 lynx version.

I can confirm that lynx successfully connects to www.comcast.com on RHEL-7.

The actual difference seems to be missing support for the X.509 SubjectAltName  extension, which is implemented in RHEL-7 lynx but not in RHEL-6 lynx.

Comment 3 Jeff Lightner 2016-01-19 16:20:26 UTC

lynx -source http://www.<oursite>.com:443 was of course a typo.

I was in fact getting the error when doing:
lynx -source https://www.<oursite>.com:443

You say it is dynamically linked but my suspicion was based on the output of the lynx -version showing OpenSSL 1.0.0-fips in the output.  It made me think that was statically compiled in but I'll admit I didn't do any look at the source since I implemented the elinks work around.  I just wanted to report the issue so RedHat can address whatever it is in case the work around doesn't work for others.

Comment 4 Kamil Dudka 2016-01-19 17:07:51 UTC

(In reply to Jeff Lightner from comment #3)
> You say it is dynamically linked but my suspicion was based on the output of
> the lynx -version showing OpenSSL 1.0.0-fips in the output.  It made me
> think that was statically compiled in but I'll admit I didn't do any look at
> the source since I implemented the elinks work around.  I just wanted to
> report the issue so RedHat can address whatever it is in case the work
> around doesn't work for others.

It took me a while to figure out why this happens.  OpenSSL intentionally fakes an older version of itself when returning its run-time version info to programs that were built before:

https://git.centos.org/blob/rpms!openssl/a5ef24ff/SOURCES!openssl-1.0.1e-version.patch

Comment 5 Tomas Mraz 2016-01-19 17:19:33 UTC

The reason for that 'version faking' is that actually less things gets broken with it than when it was not done. The fix is just to rebuild lynx against the current openssl version.

Comment 6 Kamil Dudka 2016-01-19 17:40:16 UTC

(In reply to Tomas Mraz from comment #5)
> The fix is just to rebuild lynx against the current openssl version.

To clarify it, the rebuild would only make lynx report the version of OpenSSL that it really uses.  In order to fix the subject matching (and consequently make lynx connect www.comcast.com), patching of lynx's source code is needed.

Comment 7 Tomas Mraz 2016-01-19 18:35:32 UTC

Yes(In reply to Kamil Dudka from comment #6)
> (In reply to Tomas Mraz from comment #5)
> > The fix is just to rebuild lynx against the current openssl version.
> 
> To clarify it, the rebuild would only make lynx report the version of
> OpenSSL that it really uses.  In order to fix the subject matching (and
> consequently make lynx connect www.comcast.com), patching of lynx's source
> code is needed.

Yes, of course.

Comment 8 Kamil Dudka 2016-07-13 12:26:37 UTC

RHEL-6 is in Production Phase 2, which means no future features are planned.  You are welcome to upgrade to RHEL-7, where the feature is already available.

Note You need to log in before you can comment on or make changes to this bug.