Page 1 of 1

Feature Request: ongoing check of certificate/whois owner of trusted domains

Posted: Tue Mar 24, 2020 1:30 am
by ozjuggler
I had an interesting event just happen which I think may have an automated solution that could be done by NoScript.
Years ago, probably back in 2010 (yes it's amazing how long NoScript has been around), I once found a free PDF of matrix math tutorials and it had an associated blog at matrixcookbook.com. You can see the old version at https://web.archive.org/web/20110430075 ... kbook.com/
So of course I probably added that domain into NoScript as trusted.
Aaand then I forgot all about it for 10 years.
So today I'm going through my bloated NoScript trusted sites list out of idle curiosity, wondering what I can cut out.
What is matrixcookbook ?? I don't remember anything about it. Just type it into the address bar and see what happens.
Then the browser seems to want to redirect to some other site on "tncrun.net", which seems strange so I look for other references to that domain.
It turns out it has been used recently as a host of malware and injected code for web skimmers that steal CC info from shopping carts. Nice!

So the problem generally is domains that are initially trusted then later lapse into disuse and get taken over by scammers who in principle may be able to exploit that trust.
The cause of the problem is that we trust names (words on the screen) which are tradable commodities, and don't trust the actual TLS certificate chains and fingerprints which should be destroyed or kept secret after domains lapse or get sold.

Two possible solutions which could perhaps be implemented by NoScript:
  • The Trusted Fingerprint Method : Adding an HTTPS site to the trusted list should record the fingerprint of the certificate and trust that, so if the certificate presented by the web site ever changes No Script will not trust it until you affirm trust on the new fingerprint. Maybe some WHOIS domainkey signature could be done on plain http or ftp domains, but I don't know if there is any reliable analogy with non-HTTPS URLs. This check would be done the first time each day that a domain is accessed by the browser.
  • The Background Check method : NoScript could store a "last checked date" for each trusted URL, then each day NoScript could check the oldest 1% of the trusted sites to see if their WHOIS domain owner has changed, and remove the domain from the trusted list if it has changed. That way you limit the time in which a domain trust exploit can happen to 100 days.
Probably there are other infosec negative side-effects to these solutions, such as creating huge amounts of extra "useless" traffic on the internet, or having an adversary figure out what is in your trusted sites list by using traffic analysis or by intercepting your DNS WHOIS and HTTPS requests.

What do users and developers of NoScript think about this problem and possible solutions?

Re: Feature Request: ongoing check of certificate/whois owner of trusted domains

Posted: Wed Mar 25, 2020 4:00 pm
by barbaz
ozjuggler wrote:
Tue Mar 24, 2020 1:30 am
The Trusted Fingerprint Method : Adding an HTTPS site to the trusted list should record the fingerprint of the certificate and trust that, so if the certificate presented by the web site ever changes No Script will not trust it until you affirm trust on the new fingerprint.
Interesting idea. I'm not sure how often fingerprints change normally, so I don't know how annoying this would be for people like me who run browser in a sandbox that gets dumped on quit. But I can see how having this as an *optional* feature could improve security.

It could make whitelisting a site from the popup different from entering it manually in NoScript Options. For sites manually entered in NoScript Options, NoScript wouldn't know any certificate fingerprint until you visit the site. Unless you can also enter/edit the certificate fingerprint manually in NoScript Options. That ability would have additional benefit of making this feature more manageable for sandbox users.

(NoScript currently supports Firefox 59 and later, while this would require at least Firefox 62 - https://developer.mozilla.org/en-US/doc ... curityInfo)
ozjuggler wrote:
Tue Mar 24, 2020 1:30 am
Probably there are other infosec negative side-effects to these solutions, such as creating huge amounts of extra "useless" traffic on the internet,
And I've seen some cases where the number of allowed WHOIS lookups is limited. I would stay away from WHOIS based solutions to this problem.