Bug 1299938 - lynx does not support X.509 SubjectAltName extension
lynx does not support X.509 SubjectAltName extension
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lynx (Show other bugs)
6.6
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Kamil Dudka
BaseOS QE - Apps
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-19 10:14 EST by Jeff Lightner
Modified: 2016-07-13 08:26 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-13 08:26:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Lightner 2016-01-19 10:14:09 EST
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 11:02:05 EST
(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 11:20:26 EST
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 12:07:51 EST
(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 12:19:33 EST
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 12:40:16 EST
(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 13:35:32 EST
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 08:26:37 EDT
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.