Hide Forgot
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.
(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.
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.
(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
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.
(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(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.
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.