TeleMessage, used by Trump officials, can access plaintext chat logs(micahflee.com)
micahflee.com
TeleMessage, used by Trump officials, can access plaintext chat logs
https://micahflee.com/despite-misleading-marketing-israeli-company-telemessage-used-by-trump-officials-can-access-plaintext-chat-logs/
91 comments
Stories like this are why we started the gospl.chat project I've been part of.
Most so called “secure” systems sabotage themselves not by accident, but because of compromises. There's always an attempt to “secure the system” for the system which often results in architectures that fail the people they're supposed to protect. Industry headliners often focus on encryption protocols, but E2EE alone doesn’t guarantee safety. If a user or business finds themselves in a life-threatening situation most messaging platforms will do nothing to protect them and may even become part of the threat. We approached gospl.chat from the opposite direction - modeled real world threats and built a communication system that minimizes the risk of harm, even in worst-case scenarios.
Security isn’t just about math. It’s about context. It’s about the environment where an app is used and how it behaves when things go wrong. Our goal isn’t to win a crypto audit. It’s to make sure no one loses their freedom, safety, or life because of a message.
Recent and related:
Technical analysis of the Signal clone used by Trump officials - https://news.ycombinator.com/item?id=43875476 - May 2025 (313 comments)
Technical analysis of the Signal clone used by Trump officials - https://news.ycombinator.com/item?id=43875476 - May 2025 (313 comments)
Mike Waltz Accidentally Reveals App Govt Uses to Archive Signal Messages
https://news.ycombinator.com/item?id=43865103
https://news.ycombinator.com/item?id=43865103
Isn't that the point?
No, the point is for the government to have access the plaintext after it is securely delivered to an approved archive location, not TeleMessage having access on AWS-hosted servers exposed to the public internet.
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.
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.
I doubt that’s the point either. The government should have cipher text they are able to decrypt in an approved archive location with rigorously managed key material and a careful cryptographically variable chain of custody from its inception. Plain text should never factor into this.
The US government does have storage facilities and secure messaging tools with escrow, all designed for exactly this use-case (secure messaging amongst DoD personnel.) But the whole point of Signal+TeleMessage was to route around that "clunky stuff" by outsourcing it to a vendor.
I understand the point - the point is people who believe the size of their bank account is proportional to their intelligence and aptitude at everything making flat dumb decisions because, if anything, the relationship is none of not inversely proportional. Their arrogance and eschewing of expertise in favor of magical thinking will end up with a lot of people dead.
The DoD obviously has a need to message with people who don't have access to their hardware. Signal can basically do this on its own if you link a Signal account to an Internet-connected PC and back up those messages, I don't see why you would want a third party app involved.
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.
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.
There are PIV creds for more than just DoD.
The point is that it was supposed to be end-to-end encrypted by this company all the way to the government's archive.
That's what they claimed, but their service did no such thing.
That's what they claimed, but their service did no such thing.
How, in Signal's security model, could there be "end to end encryption all the way to the government archive"?
By saying that chatting and logging are separate processes, and each one has end to end encryption. Only the clients and the archive can see the text.
And that's what the actual quote says. End to end from phone to archive.
And that's what the actual quote says. End to end from phone to archive.
But the entity we're saying has access to the plaintext is the archive.
The "TeleMessage Archive Server" in the diagram is not the archive. It's a relay that should not have access to the plaintext, but does. And because TeleMessage owns it, they get access too.
The "Archive Destination" is the actual archive and the only thing that should have decryption keys.
The "Archive Destination" is the actual archive and the only thing that should have decryption keys.
This actually seems pretty trivial to me, without a custom Signal client. You link a secure PC with the secure archival software to your Signal account and it will receive all messages E2E encrypted.
We're using words like "should" have access or whatever, but my understanding of the point of these apps is that they allow users to use Signal while keeping compliance archives of messages. They're not cryptographically interesting (or really cryptographic at all). This is more like e-discovery software than secure messaging. If you're using it, cryptography is out the window.
It’s not end-to-end, but that seems a bit exaggerated. An organization will still want encryption in transit, encryption at rest for its archive, and good access control.
In secure messaging as a cryptographic discipline, this is like saying you don't want secure messaging. Secure messaging is end-to-end secure, and the basic core threat modeling of a secure messaging service includes adversaries who defeat transit-only encryption.
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.
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.
Hypothetically, wouldn't the best Signal archiving be to make the custom client auto-add an archiving "user" to all chats, with that user only connected from secure archiving machines? Then convert archive user client text to whatever government encrypted form on that machine for long term storage?
Curious what the best way of archiving with Signal's security model would be.
Curious what the best way of archiving with Signal's security model would be.
There's a reason Signal doesn't archive, and you have to fork it to make that happen.
My stock, unmodified Signal app does archive: Settings > Chats > Chat backups.
"a reason"?
Secure group chat is possible. If saving messages to an archive is what you want, Why isn’t the archive just another endpoint to deliver messages to?
The threat model would cover the risk of intercepting messages on the way to the archive and unauthorized access to the archive.
The threat model would cover the risk of intercepting messages on the way to the archive and unauthorized access to the archive.
Why would they need to hire a foreign Israeli firm for that?
Through this procurement decision, the government has displayed gross incompetence.
Through this procurement decision, the government has displayed gross incompetence.
Presumably, in the spectrum of secure network protocols, something exists between "delete the message before it can leave this machine" and "send this message to a cloud provider and have them email it in plain text to another cloud provider".
And Email protocol backbone itself was not designed to be secure.
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.
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.
This might have been the case back in the day - in the 90s, young me would get a kick out of seeing just how many SMTP servers my email passed through. But now, email communication is "essentially" point-to-point, and relays in use are configured/whitelisted.
My SMTP server will pull up your MX and talk directly to it. It might be your Exchange server, a Google server, or a third-party scanner that then sends on to your "real" MX.
But gone are the days of "Hey, I only know a few places to send this message, so I'll send to one of them and they'll forward it". Nor can you do anything akin to route poisoning or other things to try to insert yourself into the message flow.
My SMTP server will pull up your MX and talk directly to it. It might be your Exchange server, a Google server, or a third-party scanner that then sends on to your "real" MX.
But gone are the days of "Hey, I only know a few places to send this message, so I'll send to one of them and they'll forward it". Nor can you do anything akin to route poisoning or other things to try to insert yourself into the message flow.
That's good to hear, however, as a compliance officer, what evidence I can provide to an auditor that our email communications are indeed encrypted?
It's not a secure messaging system. It's explicitly the opposite.
If you're sending plaintext out of an ostensible e2ee system, it's not an e2ee system. You have an 'end' that's not, you know, end-to-end.
The end that's relaying the plaintext is the user agent itself, not a third component in the system.
There is no 'relaying plaintext' in an e2ee system.
Sure, 100% agreed. But the way you phrased the earlier post implied that there was a third "end" to the system that was doing the plaintext leaking, and that's not the case (assuming I understood the description correctly, and it's accurate).
It's supposed to be available in plaintext to the end customer (government), at their secured archive, but not available in plaintext to TeleMessage.
>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.
>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 for the program TeleMessage to have access.
On top of that the company TeleMessage has access, and that is bad.
On top of that the company TeleMessage has access, and that is bad.
> Isn't that the point?
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?
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?
[deleted](1)
It’s probably against the rules to self-link old comments. And it’s hard to be remotely proud about having a good take on this news as it unfolded.
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.
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.
Brewing? This is it. All of these messages have been leaking; that's what the article is about.
Have you found info on the chat texts?
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.
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.
A leak to the press is one of the least damaging (relatively speaking) categories of leak, because intelligence officials quickly become aware. What's far more damaging is when secret communications are leaked to outside intelligence.
Right. What evidence is out there on the leak contents?
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.
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.
If it was your life on the line, how comfortable would you be with all of that room for interpretation?
> It’s probably against the rules to self-link old comments
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!
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!
No, I rarely think self-referential comments are useful, let alone interesting.
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.
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.
I think it's good to compare and contrast the items you got right and wrong in the take and discuss why it did or did not play out that way.
I'd find it useful if I could access my Signal chat logs in plaintext. The software offers no facility to do this on any platform, and on Desktop the programs that have allowed me to take proper backups are (by necessity) a moving target because of changes to the database, so I am constantly having to get around to updating them and occasionally even that's a pain.
> I'd find it useful if I could access my Signal chat logs in plaintext
I'd probably also find it useful if I could access your Signal chat logs in plaintext. That's the problem.
I'd probably also find it useful if I could access your Signal chat logs in plaintext. That's the problem.
If someone has enough control of the app to utilize its export-to-plaintext button you were SOL anyway, there are plenty of use cases for “export a password protected encrypted blob of chat history so I don’t lose everything every time I switch devices”
> If someone has enough control of the app to utilize its export-to-plaintext button
Or find the lowest-paid, most-indebted and/or most-adulterous member of the TeleMessage team and bribe and blackmail them.
Or find the lowest-paid, most-indebted and/or most-adulterous member of the TeleMessage team and bribe and blackmail them.
Signal already has exactly that? That isn't the same as a plain text export like the GP was saying though.
It'd also be useful if backups on Android actually streamed somewhere off the phone so they could be meaningfully appended to, kept. Or handled per channel (i.e. my baby pictures channel with family).
That would hit the Google One revenue if people would use alternatives…
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.
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.
PhotoSync can incrementally backup iOS/Android photos to self-hosted or cloud storage targets, with optional encryption, https://www.photosync-app.com/support/encryption
...and if the restore process wasn't so fragile. The only time I needed to backup and restore it just crashed part-way through, so the backup process wasn't even doing any validation.
The lack of encrypted (and cross platform) backups is the biggest security hole I know of in Signal.
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.
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.
This comment confused me a lot, because Signal has encrypted backups, just not cross platform. Looking into it more, it seems that iOS only has a "transfer" option instead of allowing backups. It's hard not to suspect this is due to arbitrary limitations on filesystem access on iOS.
Neither do other chat apps.
It's usually impossible to regularly export your chats to a machine you own in a format you can use. Same with photo apps.
It's usually impossible to regularly export your chats to a machine you own in a format you can use. Same with photo apps.
[deleted]
Why bother hacking your phone and installing a keylogger when we can convince your IT department to buy it and install it for your entire team. Have to say, this is pretty epic.
[deleted]
These are the guys trying to jail Krebs for being honest. They earned the “experts” they deserve.
For anyone else confused, "Krebs" in this context refers to Chris Krebs[0, 1], former Director of the US Cybersecurity and Infrastructure Security Agency.
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...
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...
And still there is ample support for the administration, also here. I am curious how much of it is through cognitive dissonance and how much not thinking too hard about the stuff a particular supporter don't like, and how much of it is with eyes open, embracing the crazy and the incompetence for some "higher goal" whatever that may be.
(It also probably is very different, all from "own the libs" through "escalate the second coming of Christ" or any combination thereof.)
(It also probably is very different, all from "own the libs" through "escalate the second coming of Christ" or any combination thereof.)
[deleted]
[deleted]
You DO realize that TeleMessage was put in place and procured before Trump took office right?
[deleted]
So far, no especially substantive analysis in this HN thread. What can anyone say at this point?
A large portion of HN's commenters wouldn't make this mistake in a quickly written offhand comment.
A large portion of HN's commenters wouldn't make this mistake in a quickly written offhand comment.
[deleted]
asadm(1)
Anyone can change the client name and build it to mislead baddies when photographed in public.
This may be a factual but not truthful article. This was initially framed to appear like the Trump Administration was doing something out of the ordinary by using Signal. There were also accusations that they were using Signal's disappearing message feature to conceal their activities from the authorities, and that they were breaking the Presidential Records Act, etc. Now it's revealed that they are using a version that actually archives all the messages to be compliant with the law and individual Agency policies. The new theory is that the Trump Administration is doing something especially nefarious by archiving the messages and/or they are doing it insecurely and they are controlled by Israel.
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.
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.
Without more technical details about telemessage it isn't clear how archive servers are actually selected by the app, where they are hosted, or how they are secured.
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.
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.
Reading through the guide, organizations have to compile their own apk/ipa and deploy via MDM. I'd suspect that "archive server" variable is set at build time. Maybe not and dozens of agencies ATO'd a setup where the data was running in the clear to a vendor, and to a low security cloud environment. I just don't see that happening at the DoD level.
> First and foremost, the Signal infrastructure was setup in most cases by the previous administration!
That's likely also true for the phones on their desks.
You're still not allowed to call me up and disclose in advance the battle plans for an attack on Yemen on your phone, though.
That's likely also true for the phones on their desks.
You're still not allowed to call me up and disclose in advance the battle plans for an attack on Yemen on your phone, though.
genius