Meine Beobachtungen zeigen, dass Certificate-Pinning bei Apps nicht immer als Schutzmechanismus eingesetzt wird, sondern häufig dazu dient, rechtlich fragwürdige Praktiken und (kalkulierte) Datenschutzverstöße zu verschleiern. Auszug aus dem demnächst erscheinenden Artikel »In den Datenstrom eintauchen: Ein Werkzeugkasten für Tester von Android-Apps«.
@kuketzblog Nur für Verständnis: Was meinst du mit Certificate Pinning? Bei HTTP(S) ist diese Praxis aus vielerlei Gründen obsolet, hauptsächlich aber weil die Praxis mehr Probleme verursacht als sie löst. Gibt es da bei Apps noch andere Arten des Pinnings oder meinst du hier das gleiche?
So I think my partner @owen is experiencing a @signalapp#MitM attack... I suspect on the part of the phone manufacturer, #Unihertz
How can I...I don't know, prove this? Fix it?
Here's what I did so far to troubleshoot:
@owen received a new phone, a Unihertz Atom L, and switched his Signal over to it. As I try to make a habit of, I called him over to verify our "security number". The check failed. The first sign of trouble.
@jimsalter@scott@GossiTheDog@owen@signalapp@JoeRess@pluralistic If you're just going to use TCP dump, you'll just want to tell it the correct network interface to capture and then after you have the capture you can filter it down and investigate in wireshark.
To reduce the risk of such attacks in the future an early stage service called CertWatch has been published by our Community: https://certwatch.xmpp.net/
This service allows you to check your XMPP server's #TLS setup, helps you publicly store the hash of the public key in a secure way, and then monitors your server to make sure that connections to it get the same public key that you have configured and sends notifications if anything changes (which may indicate a #mitm attack on your service).
IOW, you open an XMPP connection, signal in an XMPP-specific way that you want to use TLS, the server confirms it, and only then you run a TLS handshake.
@jabberati@feld
they attacker could try send valid XMPP stanzas unencrypted, together with the starttls and a buggy server may interpret them as part of the encrypted and authenticated connection after starttls.
If a server has a bug like that, an attacker in a MITM position can inject stanzas into client's session without actually MITMing the TLS.
I'd take these allegations with a grain of salt. But I must say that MitM'ing with a #LetsEncrypt certificate and then forgetting to renew it, leading to discovery, sounds like the most German law enforcement thing ever.
Looks like a transparent bridge was deployed in front of the actual server, obtained dedicated certificates from #LetsEncrypt and MitMed all incoming client connections since July. It was discovered because the LE certificate expired 🤦
@ge0rg This is disturbing and could easily be fixed on the letsencrypt side by requiring a challenge from the client that initiates the dv, for example:
On first DV, submit TOTP secret to client, client then sends a TOTP each time it does a new request for the same domain.
But I suppose Let's Encrypt may as well be a Trojan horse whose hidden agenda is to turn end to end encryption into end to edge encryption.
@juliank
The weak point of TOTP is recovery after token loss. You don't want your domain burned forever with LE, and LE doesn't know anything about you for any reasonable manual recovery process. And if they did, it could still be gamed.
The CAA with accounturi approach I linked earlier in the thread is a good trade off, that just nobody knows about.
Box.com hosting a page which goes to Cloudflare protected #MITM / #AITM#phishing
As usual, the whole trust on corporate URLs is going down big time. I have seen abuses on Microsoft,LinkedIn,Notion,Box and Zoho in a matter of couple of days.