I upgraded
Firefox on a
Linux system running CentOS 7 to version 52.8.0-1 with yum upgrade
firefox. When I opened Firefox afterwards and put google.com in the
address bar, I saw the message below:
Your connection is not secure
The website tried to negotiate an inadequate level of security.
uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site.
Error code: NS_ERROR_NET_INADEQUATE_SECURITY
When I went to another site, wikipedia.org, using
HTTPS, I saw
the same message. I checked to ensure that the web browser wasn't configured to
use a proxy by clicking on the icon with the three horizontal bars at the top,
right-hand side of the browser window and selecting Preferences, then
Advanced, then Network, then Settings. The setting
was "No proxy." I then right-clicked on the "Your connection is not secure"
page and chose View Page Info. When I clicked on the Security
tab, I saw the "Owner" value listed as "This website does not supply
ownership information." In the Technical Details section, I saw "Connection
Not Encrypted" and "The website www.google.com does not support encryption
for the page you are viewing," even though the URL listed was
https://www.google.com/?gws_rd=ssl.
I disabled the
NoScript add-on and tried accessing https://google.com, but saw the same
message. I tried another web browser on the system,
Vivaldi, but didn't see the issue within that browser. So I then opened
Wireshark,
a free and open-source software
packet analyzer and captured the network traffic between
the Google
webserver and the CentOS host. When I attempted to access the Google server
again, I saw a
Domain Name System (DNS) query for the address of the server and the
response from the DNS server, which indicated that the
IP address
was 172.217.7.174, which when I performed a
reverse DNS lookup with the nslookup command equated to
iad30s09-in-f14.1e100.net.
# nslookup 172.217.7.174 Server: 207.255.176.37 Address: 207.255.176.37#53 Non-authoritative answer: 174.7.217.172.in-addr.arpa name = iad30s09-in-f14.1e100.net. 174.7.217.172.in-addr.arpa name = iad30s09-in-f174.1e100.net. Authoritative answers can be found from: #
The 1e100.net
domain name is registered to Google - see
What is
1e100.net? 1e100 is
scientific notation for 1 googol, i.e., 1 raised to the power of 100, which is 1
followed by one hundred zeros. Google uses the domain name for its servers.
So there wasn't an issue with some intervening system providing the wrong
IP address for the Google server.
I then checked the packets that followed the DNS response. I saw the expected three way handshake between the host and Google server, i.e., the host sent a SYN packet, the server responsded with a SYN, ACK packet, and then the host responded to the server's SYN request with its own ACK packet. I then saw a "Client Hello" packet sent from the browser on the client. The server sent an ACK back. Wireshark then showed a "Server Hello, Change Cipher Spec, Hello Request, Hello Request" packet being sent from the server to the client. The client system then sent a "Change Cipher Spec, Hello Request, Hello Request" packet and then an "Encrypted Alert" packet.
That packet was followed immediately by a FIN, ACK packet from the client to the server. The server then sent Application Data in reply and the client reset the connection with a RST packet.
I thought, perhaps, that the system didn't currently support the latest version of the Transport Layer Security (TLS) protocol, but the protocol listed for the TLS packets by Wireshark was TLSv1.2. When I looked at the place where the TLS version number is referenced in the Secure Sockets Layer (SSL) section in the "Client Hello" packet, I saw that packet used TLS version 1.0 - Wireshark showed "TLS 1.0 (0x0301)" for the Version.
The hexadecimal values for various versions of SSL/TLS are listed below:
| Version | Hexadecimal Value |
|---|---|
| SSL 3.0 | 0x0300 |
| TLS 1.0 | 0x0301 |
| TLS 1.1 | 0x0302 |
| TLS 1.2 | 0x0303 |
But when I looked at the "Change Cipher Spec" packet subsequently sent by the client system, though, I saw it was using TLS version 1.2.
And when I used the openssl utility to check the ciphers supported on the client system, I saw TLSv1.2 was supported.
$ openssl ciphers -v | awk '{print $2}' | sort | uniq
SSLv3
TLSv1.2
$So I thought the issue probably was not caused by use of an outdated
cipher on the client side. But, since I thought openssl was probably
out-of-date, I updated it with yum upgrade openssl.
# openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 # yum upgrade openssl Loading mirror speeds from cached hostfile <text snipped> Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: openssl x86_64 1:1.0.2k-12.el7 base 492 k Updating for dependencies: openssl-libs x86_64 1:1.0.2k-12.el7 base 1.2 M Transaction Summary ================================================================================ Upgrade 1 Package (+1 Dependent package) Total download size: 1.7 M Is this ok [y/d/N]: y Downloading packages: No Presto metadata available for base (1/2): openssl-1.0.2k-12.el7.x86_64.rpm | 492 kB 00:01 (2/2): openssl-libs-1.0.2k-12.el7.x86_64.rpm | 1.2 MB 00:03 -------------------------------------------------------------------------------- Total 545 kB/s | 1.7 MB 00:03 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : 1:openssl-libs-1.0.2k-12.el7.x86_64 1/4 Updating : 1:openssl-1.0.2k-12.el7.x86_64 2/4 Cleanup : 1:openssl-1.0.1e-51.el7_2.5.x86_64 3/4 Cleanup : 1:openssl-libs-1.0.1e-51.el7_2.5.x86_64 4/4 Verifying : 1:openssl-1.0.2k-12.el7.x86_64 1/4 Verifying : 1:openssl-libs-1.0.2k-12.el7.x86_64 2/4 Verifying : 1:openssl-libs-1.0.1e-51.el7_2.5.x86_64 3/4 Verifying : 1:openssl-1.0.1e-51.el7_2.5.x86_64 4/4 Updated: openssl.x86_64 1:1.0.2k-12.el7 Dependency Updated: openssl-libs.x86_64 1:1.0.2k-12.el7 Complete! # openssl version OpenSSL 1.0.2k-fips 26 Jan 2017
I then closed and reopened Firefox. I still saw the same issue for
the Google and Wikipedia sites when I restored the prior session. But I
noticed that I didn't see the security message in another tab that was
open for https://noscript.net. I noticed
that a couple of other HTTPS sites open in other Firefox tabs were also
displaying normally, though when I tried https://bing.com,
I saw the same issue. I refreshed the NoScript page and again it displayed
normally. When I used Wireshark to capture the network traffic related
to accessing that page, I noticed that after the client system sent
a "Client Hello" packet to the server and the server subsequently
sent a "Server Hello" packet to the client, that the server sent a
packet that Wireshark categorized as "Certificate" in the Info
column of its display. When I looked at the cipher selected by the
server in the SSL section of the "Server Hello" packet, I saw that
the Cipher Suite it selected from those listed in the "Client Hello"
packet, which tells the server what cipher suites the client supports,
it was Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(0xc02f). You can find an explantation of the packets
exchanged between client and server systems for TLS exchanges at
Traffic Analysis of an SSL/TLS Session. That was the same cipher key I
saw selected in the "Server Hello" packet from the Google web server.
I tried accessing several more sites via HTTPS. I couldn't access almost all of them, getting the same "Your connection is not secure" security message with "Error code: NS_ERROR_NET_INADEQUATE_SECURITY", but I was able to access the Juniper Networks website at https://www.juniper.net.
Since I was able to access the Google website using my
MacBook Pro
laptop on the same network as the Linux system, I thought maybe Firefox
on the Linux system had an out-of-date
public key certificate stored for the Google site. I put
about:preferences#advanced in the address bar then clicked on the
Certificates tab, then selected View Certificates (you can
also get to that view by clicking on the icon with the 3 short, horizontal
bars at the top, right-hand corner of the Firefox window and clicking
on Advanced then seleting Certificates). When I
clicked on the Servers tab, I saw a certificate for www.google.com,
but no certificates were listed for either any of the other sites producing
the "your connection is not secure" message nor those where I didn't have
a problem, such as the Juniper Networks site.
And when I clicked on the View button to view the certificate details for the Google certificate, I saw that the serial number and the SHA1 and SHA-256 fingerprints were the same as when I checked the Google certificate on my MacBook Pro laptop running Firefox ESR 52.7.3 where I was not experiencing any problem accessing Google's website nor other sites.
I was finally able to resolve the problem after reading a comment at
NS_ERROR_NET_INADEQUATE_SECURITY on opening www.wikipedia.de where
Richard W.M. Jones mentioned in a reply to the poster that an update to
nss is needed. So I checked the version of the Network Security Services
(NSS) rpm on the system and then upgraded it to the latest version
with the yum upgrade nss command.
# rpm -qi nss Name : nss Version : 3.28.4 Release : 15.el7_4 Architecture: x86_64 Install Date: Tue 21 Nov 2017 11:12:27 AM EST Group : System Environment/Libraries Size : 2501949 License : MPLv2.0 Signature : RSA/SHA256, Fri 20 Oct 2017 08:33:24 AM EDT, Key ID 24c6a8a7f4a80e b5 Source RPM : nss-3.28.4-15.el7_4.src.rpm Build Date : Thu 19 Oct 2017 04:03:11 PM EDT Build Host : c1bm.rdu2.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.mozilla.org/projects/security/pki/nss/ Summary : Network Security Services Description : Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. # yum upgrade nss Loaded plugins: fastestmirror, langpacks base | 3.6 kB 00:00 epel/x86_64/metalink | 19 kB 00:00 extras | 3.4 kB 00:00 updates | 3.4 kB 00:00 vivaldi | 2.9 kB 00:00 Loading mirror speeds from cached hostfile * base: mirrors.umflint.edu * epel: mirror.us.leaseweb.net * extras: ftpmirror.your.org * updates: centos.mirror.constant.com Resolving Dependencies --> Running transaction check ---> Package nss.x86_64 0:3.28.4-15.el7_4 will be updated --> Processing Dependency: nss = 3.28.4-15.el7_4 for package: nss-sysinit-3.28.4 -15.el7_4.x86_64 --> Processing Dependency: nss(x86-64) = 3.28.4-15.el7_4 for package: nss-tools- 3.28.4-15.el7_4.x86_64 ---> Package nss.x86_64 0:3.36.0-5.el7_5 will be an update --> Processing Dependency: nss-util >= 3.36.0-1 for package: nss-3.36.0-5.el7_5. x86_64 --> Processing Dependency: nss-softokn(x86-64) >= 3.36.0-1 for package: nss-3.36 .0-5.el7_5.x86_64 --> Processing Dependency: nspr >= 4.19.0 for package: nss-3.36.0-5.el7_5.x86_64 --> Processing Dependency: libnssutil3.so(NSSUTIL_3.31)(64bit) for package: nss- 3.36.0-5.el7_5.x86_64 --> Running transaction check ---> Package nspr.x86_64 0:4.13.1-1.0.el7_3 will be updated ---> Package nspr.x86_64 0:4.19.0-1.el7_5 will be an update ---> Package nss-softokn.x86_64 0:3.28.3-8.el7_4 will be updated ---> Package nss-softokn.x86_64 0:3.36.0-5.el7_5 will be an update --> Processing Dependency: nss-softokn-freebl(x86-64) >= 3.36.0-5.el7_5 for pack age: nss-softokn-3.36.0-5.el7_5.x86_64 ---> Package nss-sysinit.x86_64 0:3.28.4-15.el7_4 will be updated ---> Package nss-sysinit.x86_64 0:3.36.0-5.el7_5 will be an update ---> Package nss-tools.x86_64 0:3.28.4-15.el7_4 will be updated ---> Package nss-tools.x86_64 0:3.36.0-5.el7_5 will be an update ---> Package nss-util.x86_64 0:3.28.4-3.el7 will be updated ---> Package nss-util.x86_64 0:3.36.0-1.el7_5 will be an update --> Running transaction check ---> Package nss-softokn-freebl.i686 0:3.28.3-8.el7_4 will be updated ---> Package nss-softokn-freebl.x86_64 0:3.28.3-8.el7_4 will be updated ---> Package nss-softokn-freebl.i686 0:3.36.0-5.el7_5 will be an update ---> Package nss-softokn-freebl.x86_64 0:3.36.0-5.el7_5 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: nss x86_64 3.36.0-5.el7_5 updates 835 k Updating for dependencies: nspr x86_64 4.19.0-1.el7_5 updates 127 k nss-softokn x86_64 3.36.0-5.el7_5 updates 315 k nss-softokn-freebl i686 3.36.0-5.el7_5 updates 211 k nss-softokn-freebl x86_64 3.36.0-5.el7_5 updates 222 k nss-sysinit x86_64 3.36.0-5.el7_5 updates 62 k nss-tools x86_64 3.36.0-5.el7_5 updates 514 k nss-util x86_64 3.36.0-1.el7_5 updates 78 k Transaction Summary ================================================================================ Upgrade 1 Package (+7 Dependent packages) Total download size: 2.3 M Is this ok [y/d/N]: y Downloading packages: updates/7/x86_64/prestodelta | 255 kB 00:01 Delta RPMs reduced 1.7 M of updates to 746 k (58% saved) (1/8): nspr-4.13.1-1.0.el7_3_4.19.0-1.el7_5.x86_64.drpm | 40 kB 00:00 (2/8): nss-softokn-freebl-3.28.3-8.el7_4_3.36.0-5.el7_5.i6 | 91 kB 00:00 (3/8): nss-softokn-3.28.3-8.el7_4_3.36.0-5.el7_5.x86_64.dr | 145 kB 00:00 (4/8): nss-3.28.4-15.el7_4_3.36.0-5.el7_5.x86_64.drpm | 330 kB 00:00 (5/8): nss-sysinit-3.36.0-5.el7_5.x86_64.rpm | 62 kB 00:00 (6/8): nss-softokn-freebl-3.28.3-8.el7_4_3.36.0-5.el7_5.x8 | 94 kB 00:00 (7/8): nss-util-3.28.4-3.el7_3.36.0-1.el7_5.x86_64.drpm | 46 kB 00:00 (8/8): nss-tools-3.36.0-5.el7_5.x86_64.rpm | 514 kB 00:00 Finishing delta rebuilds of 4 package(s) (1.4 M) -------------------------------------------------------------------------------- Total 401 kB/s | 1.3 MB 00:03 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : nspr-4.19.0-1.el7_5.x86_64 1/16 Updating : nss-util-3.36.0-1.el7_5.x86_64 2/16 Updating : nss-softokn-freebl-3.36.0-5.el7_5.x86_64 3/16 Updating : nss-softokn-3.36.0-5.el7_5.x86_64 4/16 Updating : nss-sysinit-3.36.0-5.el7_5.x86_64 5/16 Updating : nss-3.36.0-5.el7_5.x86_64 6/16 Updating : nss-tools-3.36.0-5.el7_5.x86_64 7/16 Updating : nss-softokn-freebl-3.36.0-5.el7_5.i686 8/16 Cleanup : nss-softokn-freebl-3.28.3-8.el7_4 9/16 Cleanup : nss-tools-3.28.4-15.el7_4.x86_64 10/16 Cleanup : nss-3.28.4-15.el7_4.x86_64 11/16 Cleanup : nss-sysinit-3.28.4-15.el7_4.x86_64 12/16 Cleanup : nss-softokn-3.28.3-8.el7_4.x86_64 13/16 Cleanup : nss-util-3.28.4-3.el7.x86_64 14/16 Cleanup : nss-softokn-freebl-3.28.3-8.el7_4 15/16 Cleanup : nspr-4.13.1-1.0.el7_3.x86_64 16/16 Verifying : nss-util-3.36.0-1.el7_5.x86_64 1/16 Verifying : nspr-4.19.0-1.el7_5.x86_64 2/16 Verifying : nss-sysinit-3.36.0-5.el7_5.x86_64 3/16 Verifying : nss-softokn-freebl-3.36.0-5.el7_5.i686 4/16 Verifying : nss-tools-3.36.0-5.el7_5.x86_64 5/16 Verifying : nss-3.36.0-5.el7_5.x86_64 6/16 Verifying : nss-softokn-freebl-3.36.0-5.el7_5.x86_64 7/16 Verifying : nss-softokn-3.36.0-5.el7_5.x86_64 8/16 Verifying : nspr-4.13.1-1.0.el7_3.x86_64 9/16 Verifying : nss-sysinit-3.28.4-15.el7_4.x86_64 10/16 Verifying : nss-util-3.28.4-3.el7.x86_64 11/16 Verifying : nss-softokn-3.28.3-8.el7_4.x86_64 12/16 Verifying : nss-softokn-freebl-3.28.3-8.el7_4.i686 13/16 Verifying : nss-3.28.4-15.el7_4.x86_64 14/16 Verifying : nss-tools-3.28.4-15.el7_4.x86_64 15/16 Verifying : nss-softokn-freebl-3.28.3-8.el7_4.x86_64 16/16 Updated: nss.x86_64 0:3.36.0-5.el7_5 Dependency Updated: nspr.x86_64 0:4.19.0-1.el7_5 nss-softokn.x86_64 0:3.36.0-5.el7_5 nss-softokn-freebl.i686 0:3.36.0-5.el7_5 nss-softokn-freebl.x86_64 0:3.36.0-5.el7_5 nss-sysinit.x86_64 0:3.36.0-5.el7_5 nss-tools.x86_64 0:3.36.0-5.el7_5 nss-util.x86_64 0:3.36.0-1.el7_5 Complete! #
After I upgraded NSS and then closed and reopened Firefox, the problem was solved. I was able to use the Google and Bing search engines and visit the other sites that hadn't been accessible via HTTPS previously.
Related articles:
References:
