Google's mysterious 'search.app' links leave Android users concerned | Hacker News Reader

Google's mysterious 'search.app' links leave Android users concerned

bleepingcomputer.com

29 pointsN19PEDL28 comments

One of the weirder parts of this to me is this:

> After publishing this piece, multiple BleepingComputer readers have pointed out an anomaly with the TLS certificate issued for the 'search.app' domain.

> To add confusion, search.app's certificate has the Common Name (CN) set to fallacni.com, a French language website that claims to help you "find your national identity card."

> BleepingComputer further noticed that the same SSL certificate is in use by more than a hundred domains, shown below, which are hosted on the same Firebase server (IP address 199.36.158.100)

Is this typical for how Firebase (and similar offerings) work? Is there any risk of one site on a shared Firebase server being able to MITM users that are collocated on the same IP and using the same certificate, or is having a separate domain enough to mitigate this? I'd never considered the idea of entirely unrelated (and separately owned) domains sharing an identical TLS certificate before, and I'm not enough a crypto/security person to be able to immediately think through the ramifications of this.

All of the domains are pointing to the same hosted services run by Firebase, meaning only Firebase themselves has the private key, so the customers whose domains use the certificate shouldn’t be able to MITM anything.

Cloudflare used to do (or maybe still does?) this with their free certificates as well.

Review: the article finds multiple instances of users saying that when sharing from the Google discover in built web frame prepends a link shortener type website allowing Google to intermediate the link.

The article speculates that it can be used for sender and receiver tracking, but also offers a positive option which would be blocking malicious shares.

No explanation is given by Google when reached.

Google Chat has been redirecting every clicked link through Google's domains for a while now.

Which is sketchy too, and I don't understand how this is OK with their business and corporate customers.

Microsoft do this to, I think it’s called something like “safelinks”. All links in outlook/teams are intermediated via a MS url that does some sort of “scan” then redirects you. Extremely frustrating when that service stops working, because now you can’t click on any links. I recall this happened sometime last year :/

I've never had the google service fail, but my employer added another layer to our email -- proofpoint. Google redirects to their URL, then I go to the urldefense.com URL, then to my actual website. Hopefully.

These companies want us to reduce phishing, etc attacks by being smart and looking at URLs before we click on them. Then they obfuscate them constantly like this so we can't see the actual URL. Then they wonder why phishing attacks constantly keep working.

This is every single company. Just trying to log into my doctor's patient portal, I go to my doctor's website, which redirects me to some weird 3rd party URL, which sends me to some authentication URL, then finally to the patient portal after I login, which is back to another URL. And the business names are never in the URLs. It's always "mypatientportal" or some URL with some old business name from a company that got acquired.

The most annoying thing is these fuckers keep blaming the users for getting phished. Just keep training the users. More training. More training that doesn't seem to be helping for some reason.

But here's more proof that they put metrics and data gathering over actual security. People need to learn how URLs work for fucks sake and start pushing back against their company when they do this shit. It always goes ignored everywhere I work.

They mean Subject Alternative Name (SAN) not Server Name Indication (SNI).

Reply on news.ycombinator.com