People inevitably end up working around it, which can mean using SMS, copying the threads / screenshots / attachments to arbitrary other storage, or switching to things like TeleMessage because of record keeping requirements.
I wish Signal were less hostile towards forks. I'd happily switch to a client that uses their network, but that's compatible with iCloud backup.
But also, it must have something to do with law enforcement. On the other hand, Google may say that forensic investigation of phone is harder (if no jailbreak), but on the otherhand it is easier to hand over the data behind the scenes from the remote cloud.
Backups are not E2EE by default (user can enable, so they have an argument), so in most cases law enforcement can access WhatsApp messages, SMS messages and anything else without a problem. Many people don’t think about this, and defaults matter.
I'd probably also find it useful if I could access your Signal chat logs in plaintext. That's the problem.
Or find the lowest-paid, most-indebted and/or most-adulterous member of the TeleMessage team and bribe and blackmail them.
TeleMessage pitched their service as using end-to-end encryption of the message into the corporate archive.
> End-to-End encryption from the mobile phone through to the corporate archive
Apparently the plaintext messages were going to a TeleMessage server on AWS (not an approved government archive location) that was publicly accessible. Naturally it was hacked.
It seems likely to me that this was the "whole point of Signal+TeleMessage" and then in addition to being a bad solution, it got misused for communications that shouldn't have left the DoD's networks anyway.
That's what they claimed, but their service did no such thing.
All this is to say: it's unremarkable to me that the Signal compliance fork government officials are using, which is premised on the capability of archiving messages, defeats secure messaging. That's literally what it's for.
The threat model would cover the risk of intercepting messages on the way to the archive or unauthorized access to the archive.
Curious what the best way of archiving with Signal's security model would be.
Through this procurement decision, the government has displayed gross incompetence.
It's worse than internet packets over HTTPS -- the secure connection is established between client and server, so man-in-the-middle cannot decrypt it. In email, connections are only secure between relays, so any relay can decrypt read your email. You cannot guarantee what relays are used. Similar to SMS.
>TeleMessage lies about this in their marketing material, claiming that TM SGNL supports "End-to-End encryption from the mobile phone through to the corporate archive."
Surely someone of your expertise and renown recognizes this difference.
The point is making SecDef's communications, including scramble orders, available to whoever can find a TeleMessage employee who will cave to a bribe or blackmail?
(It also probably is very different, all from "own the libs" through "escalate the second coming of Christ" or any combination thereof.)
Chris Krebs is unrelated to Brian Krebs of Krebs on Security.
[0] https://en.wikipedia.org/wiki/Chris_Krebs
[1] https://www.whitehouse.gov/fact-sheets/2025/04/fact-sheet-pr...
First and foremost, the Signal infrastructure was setup in most cases by the previous administration! Even a cursory search of USA Spending reveals millions were spent on telemessage before Trump was elected. https://www.usaspending.gov/search?hash=d900bda0a5eccae47ba7... I'm not a journalist, but look for yourself.
As for accusations that what the Biden Administration procured and configured is insecure: it's not. TeleMessage has a configuration approved for CUI that integrates with GCC-high (IL4) and O365 DoD (IL5). Thus they are fine to collect and archive unclassified CUI, ITAR, NSS data, command and control/ISR, tactical data, etc.
"TeleMessage can go a long way in enabling regulatory compliance by working with Microsoft to capture, archive, and maintain text messages, voice calls, and other files, leading to stress-free adherence to all the security controls required as per FedRAMP. Crucially, the mobile archiver supports Microsoft 365 Government Community Cloud, Government Community Cloud High, and Department of Defense solutions across all devices, carriers, and instant messengers.
Federal agencies and contractors can issue their own phones to personnel or have their employees use their own BYOD devices because TeleMessage can still securely retain all the communication within its servers or have it forwarded to a data storage vendor of choice. There is also the option of cross-carrier and international mobile text and calls archiving." -- https://web.archive.org/web/20250502041804/https://www.telem...
So far they're good in theory. They decrypted messages are transmitted in at least 1 encrypted wrapper (TLS) to mobile archiver, then ultimately landing in the DoD Azure cloud environment. The question is whether the whole chain after the phone is in the DoD environment, or if it routes through Telemessage's systems.
If you look at the hack (https://archive.ph/yyyLg), initially it leads you to believe that the message archiver doesn't live in the DoD environment and instead lives in AWS commercial or some lesser rated cloud. I think this is only true some of the time. Note in the hack, they only have messages from CPB. They don't appear to have any .mil, cia.gov, eop.gov, etc. CBP doesn't have access to the IL5 DoD Tenant in the first place and their archiver is likely hosted in AWS Commercial or AWS East/West (IL2).
Frankly, I don't think that any of the higher sensitivity organizations will be routing through a TeleMessage controlled server, or any server lower than IL4. They host that piece on their own infrastructure.
For example, while it's possible that DoD phones would only connect to Signal via proxies from within a VPN to a private network, direct Internet connectivity could lead to a potential leak of archived messages to any Internet-connected telemessage server if the app is misconfigured or the wrong app installed.
Given the debug logs shown by the attacker it sounds like the archive server has vulnerabilities exploitable over any connected network which wouldn't protect self-hosted version in govcloud from exploitation from within those networks.
A large portion of HN's commenters wouldn't make this mistake in a quickly written offhand comment.
However, when this first broke, select HN users were claiming this was OPSEC 4D chess and not deeply irresponsible cybersec practices.
That was a terrible take then, and it’s a terrible take now.
Clear as day when this started there was a nasty vendor supply chain risk lurking, and if it was 4D cybersec chess it was done by some absolute muppets.
Bad setups get exploited in natsec.
A bad setup exploited.
Sounds like a brutal US natsec leak is brewing.
It's not against the rules to link past comments - in fact it's preferred to repeating the same or similar content across stories.
At the same time, does 'look, I had the right take once in the past' make for interesting conversation? I'm keen to see it unfold!
I do think it’s useful however to claim information space on a serious topic before, interestingly, various apologists show up as is happening ITT now.
Referring to “a leak” as in these chats go public in some form vs into a RU SCIF somewhere, and that there’s some verification of what the clear text chats were/who’s in it.
I am speculating it’ll be the latter scenario, with periodic strategic leaks.
All I have found is putting 2 and 2 together that this Signal variant has been used for months, the vendor was exploited and lost data, and vendor worked with clear texts logs.
That leaves a lot of room for interpretation still. certain agencies on certain tenants, certain tenants were hacked but others, technical info like that.
I am not surprised.
dang•5h ago
Technical analysis of the Signal clone used by Trump officials - https://news.ycombinator.com/item?id=43875476 - May 2025 (313 comments)
ChrisArchitect•4h ago
https://news.ycombinator.com/item?id=43865103