Error code: NSERRORNETINADEQUATESECURITY If the web browser (eg Mozilla Firefox or Google Chrome) is too far out of date, it can’t support modern cipher standards and reverts back to an older variant. This backwards compatibility is the default for most NGINX and Plesk based systems. If you decide to disable HTTP/2 in IIS on Windows Server 2016 and only use HTTP/1.1, you can do so by adding two DWORD registry keys. You can copy the text in the box below into an empty Notepad file and save it as a.reg file. Then double-click the file to import the registry keys and reboot. This problem was still present in Fedora 28 (which is past end of life). I had to manually update nss and restart firefox to fix the problem One would expect this to.
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 theaddress 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. Anattacker could easily reveal information which you thought to be safe. Thewebsite administrator will need to fix the server first before you canvisit 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, thenAdvanced, then Network, then Settings. The settingwas 'No proxy.' I then right-clicked on the 'Your connection is not secure' page and chose View Page Info. When I clicked on the Securitytab, I saw the 'Owner' value listed as 'This website does not supply ownership information.' In the Technical Details section, I saw 'ConnectionNot Encrypted' and 'The website www.google.com does not support encryptionfor 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 softwarepacket analyzer and captured the network traffic betweenthe Google webserver and the CentOS host. When I attempted to access the Google serveragain, 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 addresswas 172.217.7.174, which when I performed a reverse DNS lookup with the nslookup command equated to iad30s09-in-f14.1e100.net.
The 1e100.netdomain 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 wrongIP address for the Google server.
I then checked the packets that followed the DNS response. I saw the expectedthree way handshake between the host and Google server, i.e., the host senta SYN packet, the server responsded with a SYN, ACK packet, and then thehost responded to the server's SYN request with its own ACK packet. I thensaw 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 thensent a 'Change Cipher Spec, Hello Request, Hello Request' packet and thenan 'Encrypted Alert' packet.
That packet was followed immediately by a FIN, ACK packet from theclient to the server. The server then sent Application Data in replyand the client reset the connection with a RST packet.
I thought, perhaps, that the system didn't currently support the latestversion 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.
Firefox Ns_error_net_inadequate_security
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 sentby 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.
So I thought the issue probably was not caused by use of an outdatedcipher on the client side. But, since I thought openssl was probably out-of-date, I updated it with yum upgrade openssl.
I then closed and reopened Firefox. I still saw the same issue forthe Google and Wikipedia sites when I restored the prior session. But Inoticed that I didn't see the security message in another tab that wasopen for https://noscript.net. I noticedthat a couple of other HTTPS sites open in other Firefox tabs were alsodisplaying 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 relatedto accessing that page, I noticed that after the client system senta 'Client Hello' packet to the server and the server subsequentlysent a 'Server Hello' packet to the client, that the server sent apacket that Wireshark categorized as 'Certificate' in the Infocolumn of its display. When I looked at the cipher selected by theserver in the SSL section of the 'Server Hello' packet, I saw thatthe 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 packetsexchanged between client and server systems for TLS exchanges at Traffic Analysis of an SSL/TLS Session. That was the same cipher key Isaw selected in the 'Server Hello' packet from the Google web server.
I tried accessing several more sites via HTTPS. I couldn't access almostall of them, getting the same 'Your connection is not secure' security messagewith '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 Firefoxon 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 theCertificates tab, then selected View Certificates (you canalso get to that view by clicking on the icon with the 3 short, horizontalbars at the top, right-hand corner of the Firefox window and clickingon 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 producingthe 'your connection is not secure' message nor those where I didn't havea problem, such as the Juniper Networks site.
And when I clicked on the View button to view the certificatedetails for the Google certificate, I saw that the serial number and theSHA1 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 atNS_ERROR_NET_INADEQUATE_SECURITY on opening www.wikipedia.de whereRichard W.M. Jones mentioned in a reply to the poster that an update tonss is needed. So I checked the version of the Network Security Services(NSS) rpm on the system and then upgraded it to the latest versionwith the yum upgrade nss command.
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:
Ns_error_net_inadequate_security Asp.net Core
- List supported SSL/TLS versions for a specific OpenSSL build
Posted: December 11, 2014
Stack Overflow - Traffic Analysis of an SSL/TLS Session
By: Álvaro Castro-Castilla
Date: December 23, 2014
The Blog of Fourthbit