It's an interesting idea, but I'm not convinced that this is either practical or desirable, as connection security is not based on TLS with a certificate.

I think it would be a mistake to show that connection is secure, but perhaps it would be reasonable if no message was shown, i.e. like localhost is handled.

The challenge here is that we have no idea how the *.onion URL will be handled. 

If, for instance, the user is insecurely connected to a remote proxy and that remote proxy resolves Onion sites, the overall connection is still not secure because the first hop isn't secure. 

To add on to #3: The security of the transport to the site relies on a lot of system configuration that we aren't privy to (e.g., whether the user correctly set up Tor, whether the user has an intercepting proxy or "helpful" DNS server that decides to resolve .onion domains, etc.), which makes it hard to use the TLD as a way of setting security UI.

Ideally, we'd like to have a path forward where we don't break Tor services in the long term, but I don't think the whitelist is necessarily the right approach.

Resolving WONTFIX based on #3 and #4. It's worth noting that Onion sites can get HTTPS certificates and some have (e.g. Facebook, see https://blog.torproject.org/facebook-hidden-services-and-https-certs) done so.  

Just hiding the "Not secure" indicator would be misleading insofar as the rest of Chrome does not treat http://*.onion/ as a secure context and as a consequence accessing these URLs over HTTP means that they cannot use powerful features (See https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features)

Then, it could be restricted to SOCKS servers at 127.0.0.1.

There is some risk that local proxy stacks on top of remote proxy that resolves Onion sites, but this case seems to be similar to a local HTTP server that, on submit, sends form to a remote server over a non-secure connection.

Sorry, sent the previous comment before updating the page. Thanks for consideration!