Would it be possible to display the TLS certificate's common name in the identity panel instead of top domain? Topic is solved

[jobbautista9]

I think the top domain can be misleading as the "identity" for domain verification, because an HTTPS website doesn't always control its top domain. This scenario can easily be seen for websites using a free DNS service like https://freedns.afraid.org/. Just because my website is hosted under a subdomain of say tworiverssoftware.com (yes it has a real website under the top domain and yes that's also an available "public" top domain on afraid.org for some reason lol) doesn't mean my website is verified to be the same identity of whatever is hosted on that top domain.

Now I know there is the option to display the entire host name (in the Advanced Preferences provided by Pale Moon Commander the setting is first under Security => SSL), but that one is kinda misleading too its own way. For example this very forum and the main website both have a DV cert with *.palemoon.org as common name. With the default "top domain" setting the identity panel of both shows as palemoon.org, correctly implying that both websites are verified to be under the same control. However with the "entire host name" setting it allows the interpretation that both websites are not verified to have the same identity.

So IMO a "common name" setting would not only be great, but also a better default than the current "top domain".

[Moonchild]

Not really an option. Certificates are often supplied with many subject alt names for shared hosts, where the CN is not at all representative of the website visited and might not even be related at all. Displaying the CN would be really, really misleading in that case and completely wrong as an indicator of the site or owner.

an HTTPS website doesn't always control its top domain

But that's not what the domain display is for. The top domain does control its subdomains, at least as far as domain names and certificates is concerned. So it always makes sense to display the controlling entity for the domain (i.e. the TLD+1) since they are effectively in control of the domain you are operating under. While they might not operate the subdomain host themselves, they are responsible for it.

[jobbautista9]

Not really an option. Certificates are often supplied with many subject alt names for shared hosts, where the CN is not at all representative of the website visited and might not even be related at all.

I have seen this case too with YouTube (where the youtube.com is a Subject Alt Name and the CN is *.google.com) and Gensokyo Radio's PWA (where app.gensokyoradio.net is a SAN and the CN is some.. Turkish electricity service?). But this makes a CN option even more compelling to me, because I do want to know who the cert and encryption/decryption keys supplied is for. In the former example I would know that Google really is controlling YouTube (a poor-man's version of Extended Validation I suppose). In the latter example I would know that my browser is not really talking to a server that Gensokyo Radio controls. Sure they may be managing the contents of the website (just as an SNS user manages their profile in an SNS's URL path), but they do not hold the key used to communicate securely with me.

EDIT: Now it's also possible that GR does hold the keys (which could be the case if the PWA is hosted in a server GR operates), but they're shared with the CN's owner (and possibly the other SANs too). That would be worse than just simply outsourcing your TLS, but it's essentially the same scenario of your communications being able to be decrypted by a third-party (e.g. another website's owner who doesn't operate the target website's server).

But that's not what the domain display is for. The top domain does control its subdomains, at least as far as domain names and certificates is concerned. So it always makes sense to display the controlling entity for the domain (i.e. the TLD+1) since they are effectively in control of the domain you are operating under. While they might not operate the subdomain host themselves, they are responsible for it.

The top domain's controller is responsible for the websites hosted under the subdomain, yes. But they are not a party at all to the secure communications between me and a subdomain they do not operate. They don't hold the keys to decrypt what I send to said subdomain's website, and they wouldn't even know the exact contents said website encrypts before it sends it to me.

[Moonchild]

In the latter example I would know that my browser is not really talking to a server that Gensokyo Radio controls.

But you're wrong. the CN of a shared server doesn't mean that that domain "controls the server". Quite often it means that that domain just happened to be the first in the list of domains to secure with the shared certificate issued for whatever hosting service is in use (which may be issued for many, many domains in a single certificate). A certificate can only have one CN, but can have many SANs.
So, here, you are already seeing a clear demonstration how it points to a completely unrelated party.
What you seem to be looking for is an IP whois to know who is responsible for the server instance you are talking to, not which domain holds the name-based control. But that has nothing to do with the TLS certificate or the domain-based trust chain!
In the current day and age the ultimate "control of the server" is very often not in the hands of domain owners. That would only be the case if they co-locate own hardware, if they have a dedicated server (hardware unit) they lease in a DC, or host everything in-house. That is very a small percentage.

It'd be easier to explain in person with a notebook (or napkin) to quickly clarify some things with sketches, but unfortunately that's not an option here.

Sure they may be managing the contents of the website (just as an SNS user manages their profile in an SNS's URL path), but they do not hold the key used to communicate securely with me.

Correct. Cryptographically speaking, this is a compromise you make when using shared hosting, or a reverse caching proxy like CloudFlare or a good number of CDNs. The server operator will always have a copy of the private key and can decrypt traffic; but in the case of shared hosting they already have control of the server instance, so already have access to the data anyway. In the case of a reverse caching proxy, the website owner explicitly has to extend their trust to the proxy operator as encrypted data cannot be cached in-transit (that is what end-to-end encryption means).

In the end, though, that is up to the website owner to decide. They are the ones extending their domain trust to third parties if their infra needs it, and that should be transparent to end-users. By throwing up a "CN mismatch" to end-users, you are creating a flag that is in almost all cases a false positive. Just because a CN holds a different TLD+1 than the domain visited doesn't mean that the CN's domain "controls" the site you are visiting, and is instead pointing to an unrelated and incorrect party.

The identity panel's purpose is, primarily, to quickly show that "yes, the website you are visiting is on the domain you expect it to be", not some kind of spoofed malicious address on a different domain. It isn't designed to give detailed certificate information (which is only a click away, though).

As an alternative, I suggest you grab GeoFlag which will indicate on mouse-over the full host name, IP and country where the server is as a quick check, and can show you tons more detail in configurable context options.

[jobbautista9]

Hmm I think I may have been misunderstanding what the identity panel is for, yeah. I did not account for CN being simply the first domain of a shared certificate (though that seems pretty confusing no? I would've expected a CN to be pointing to the shared host server's nickname or something related about the shared host server, being literally the server common to all websites/alt names under it and therefore the subject of the certificate, and then the first shared host domain would be a SAN. Or is it simply for compatibility with TLS clients that don't support looking in SAN?) And I did not realize that transparency in UX is indeed important (otherwise why not also treat a website hosted in a reverse proxy differently than one hosted in a dedicated server)...

I have looked into GeoFlag and indeed it does cover what I wanted for the most part, perhaps even better than the best-case scenario of my proposed option for the identity panel. The only thing I feel missing is punycode for the full domain name; it would help against subdomains trying to impersonate another subdomain with Unicode, which would most probably happen with the free DNS service I mentioned earlier (though I haven't checked if they accept unicode as subdomain name).

[Moonchild]

I have looked into GeoFlag and indeed it does cover what I wanted for the most part, perhaps even better than the best-case scenario of my proposed option for the identity panel. The only thing I feel missing is punycode for the full domain name; it would help against subdomains trying to impersonate another subdomain with Unicode, which would most probably happen with the free DNS service I mentioned earlier (though I haven't checked if they accept unicode as subdomain name).

You can control how it is displayed. Pale Moon has had "smart" punycode display in the identity panel enabled by default on TLS sites for a long time.

See viewtopic.php?f=24&t=15583

[jobbautista9]

I meant the domain name when hovering over the flag icon (see attached screenshot), sorry for not making it clear.

I could use the "entire host name" option for the identity panel so that punycode would show for the subdomain, but I would've preferred the browser only using the option if there is Unicode in the subdomain and otherwise defaulting to just the top domain, since my navigation toolbar has gotten pretty cramped and I'd like to save as much horizontal space for the address bar's text field as possible without resorting to clearing up my toolbar or enlarging my window...

[jobbautista9]

my navigation toolbar has gotten pretty cramped and I'd like to save as much horizontal space for the address bar's text field as possible without resorting to clearing up my toolbar or enlarging my window...

FWIW I've solved my dilemma by having the sidebar enabled (currently always showing my bookmarks, and as a bonus it's much easier to navigate through my live bookmarks than when they were in the bookmarks toolbar). That way I would have to expand my window horizontally to keep my preferred viewport size at that default 1141x508 (measured thanks to https://howbigismybrowser.com/) I got on first install. Now I can have my cake (a more spacious address bar) and eat it too (entire host name for identity panel, keeping my separate search field, appearance set to large icons and text, and separate reload and stop buttons). I guess there's always a way!

[RealityRipple]

I meant the domain name when hovering over the flag icon (see attached screenshot), sorry for not making it clear.

geoflag.js line 1328 - let myHost = this.uri.host;. All you need to do is change it to this.uri.asciiHost and it should show the decoded version in the tooltip. It may potentially trigger some issues though, I haven't actually tested the full ramifications of changing this.