Viewing a single comment thread. View all comments

drawkbox t1_j9x9o8o wrote

Reply to comment by alsu2launda in Signal CEO: We “1,000% won’t participate” in UK law to weaken encryption by ActivePersona

Being open source does not mean it is secure. If anything it means people will overly trust it.

Open source libraries have been owned right in front of everyone. OpenSSL had the Heartbleed hole for years, everyone owned. Log4j/Log4Shell owned every device with Java on it including all Android phones for over a decade...

Opening up private messages to a third party isn't a good idea. If you are on Apple, use iMessenger. Apple can already get your info. Same on Google. Using an additional third party client, as well as a desktop client, that opens you up to all sorts of attack vectors even it you trust the company, they can be hacked. Trust leads to intrusions.

1

kcabnazil t1_j9xi3m9 wrote

You make good points here. Multiple, actually. Using any software or hardware means putting your trust in whoever made it. Extrapolating that into something of a strawman argument/fallacy that is still completely true, using any device you didn't personally manufacture and write all the firmware/software for is opening yourself up to insecurity. The real question is, as you allude to, "who do you trust, and how far?"

However, I'd argue the semantics of, "if anything, it means people will overly trust it."

People will overly trust anything that sells them the message they want. That includes using products from big name companies. That also means believing their IT friend Bob who says anything open source is the way to go. Little do they know, Bob also happens to be making a dollar a day on their open source but rarely scrutinized app for dog memes using your phone for cryptomining.

Apple's image of privacy for the iPhone is a mirage built on believable efforts and misleading reports. People still gulp it down eagerly. Signal's image of privacy is built on throwing themselves to the lions by being well known and showing their code; anyone and everyone with the capacity to look will look if it matters to them. It doesn't mean Signal is perfect, but it does mean they're putting everything on the line to prove they're doing the best they and every other contributor can. Both teams have track records, but only one is willing to show you what happened along the way.

That said, I find it very surprising that Signal has not gone the way of Lavabit. How have they evaded U.S. government gag orders while honoring their commitments? I assume no big company has; that's rather perposterous, honestly. Several have canaries for these situations.

2

drawkbox t1_j9xtvb4 wrote

I am more zero trust but if you are going to trust, trust fewer third parties. Even if trustable. Third parties get sold. Third parties need to make money from that not other ways only (Apple/Google for instance don't need you using messaging to survive).

If you are already on a browser, a password store/generator is safer without a third party involved. The OS, browser and company already have you, why involve a third party?

Same with messaging... Trusting WhatsApp/Signal/Telegram is not only another level third party, it is your most private content... why trust a funded/private equity/questionable source system if you don't have to.

Signal does appear to be the best of them, however being open is not safer always.

The new trick is dependency/build attacks, so good sometimes the main company doesn't even know it is happening (see SolarWinds that was hacked via TeamCity CI, the bad bits were being put into the dependencies at build, code was fully independently verified). The problem is blanket trust. It is what led to the OpenSSL Heartbleed hole, the Log4j/Log4Shell hole and pretty much any bit hole in the last year was part of open source.

When a company gets their source code stolen (LastPass for instance) the point is to find dependencies they can manipulate, not even the code itself. Almost all closed code uses dependencies that are open or known, and have known holes, the key there is utilizing that when you know the code flow. Open source actually makes that part easier, no need to steal source code.

I am a big OSS fan, but I hate how devs are the weak link today. Devs today are so willing to trust a third party because they heard about it or it saves a day. Those are the MOST targeted dependencies...

3

uwu2420 t1_j9xl3a4 wrote

There’s two big issues with iMessage that Signal solves:

  1. iMessage only works with iOS devices

  2. iMessages are end to end encrypted, BUT, they are stored in readable format in iOS backups, and since most people tend to use iCloud backups, which by default are not end to end encrypted, this is used as a back door to defeat the protection. The option to encrypt iCloud backups, Advanced Data Protection, is new and only came out a couple months ago — prior to this, there was no way at all to encrypt iCloud backups. Importantly, as a sender, you have no idea if your recipient is taking the proper precautions, and no way to enforce it.

2

drawkbox t1_j9xtbji wrote

Though the iMessage/iCloud backups are linked to a user and everything it keyed on that. Now they can additionally encrypt but it was always encrypted under the user.

I see this same complaint with browser password managers in the browser (not extension), they do encrypt now but they used to just by the user. You'd have to login as the user to be able to decrypt everything or access it. Things like Signal, Telegram, LastPass, Bitwarden and other third party style systems that do not encrypt by user, it is encrypted but you can break it outside the context of the user, not possible with backups, iMessage, Chrome/Safari/Edge passwords etc.

> Importantly, as a sender, you have no idea if your recipient is taking the proper precautions, and no way to enforce it.

By default Signal/Telegram both use your number and if one participant of the chat (even a 'ghost' user) isn't, or even if they are, all that data is wide open. Telegram by default has encryption off. If one of your recipients is that way, well you are wide open.

1

uwu2420 t1_j9xugo6 wrote

No, iCloud backups up until a couple months ago were not end to end encrypted and it was explicitly used by governments as a backdoor to get around iMessage encryption. There’s a leaked law enforcement slide about it somewhere.

https://support.apple.com/en-us/HT202303

See under “data categories and encryption”, under “standard data protection” (which was the only option up until a couple months ago, and still the default option to this day), note how iCloud backups (including both the full contents of the device, and iMessages) are not end to end encrypted.

Telegram’s encryption is a homebuilt algorithm rather than a tried and true standard (never roll your own crypto…) and as you pointed out not on by default. So it was always inferior to Signal.

Signal by default doesn’t keep its data in device backups. You’d need to build a custom client to get it to do that. There’s no way to get Signal to not end-to-end encrypt it’s chats, it’s on by default and can’t be turned off.

Edit: some more links to back this up:

https://www.howtogeek.com/710509/apples-imessage-is-secure...-unless-you-have-icloud-enabled/

And the leaked slide as I mentioned earlier:

https://www.pcmag.com/news/fbi-document-shows-how-popular-secure-messaging-apps-stack-up

1

drawkbox t1_j9xvw64 wrote

Good info. The leaked screenshot I wish someone had a good version of it, so small.

The point with iCloud is that it is always under the users security context, that is encrypted. The backup files themselves weren't but across the board the OS and cloud level access requires the user context, if you were to take those outside the system you'd still need the auth context.

For law enforcement that is more accessible on iCloud, but for others it is more difficult like cyber criminals or ransomware and other things.

Phone backups also don't have to go to iCloud, it is wise to for not losing content, but you can still backup to desktop or other.

The point is, they aren't a third party, they don't make money only from messaging and they have a very vested interest in making sure their system is secure from third parties. If you add a third party into the mix like on messaging, you better trust it because your OS/device already can see that AND the third party. Adding more attack vectors is really security by obscurity, but with more obscurity.

> Signal by default doesn’t keep its data in device backups. You’d need to build a custom client to get it to do that. There’s no way to get Signal to not end-to-end encrypt it’s chats, it’s on by default and can’t be turned off.

This all falls apart when a participant is added (ghost or actual) that gets the entire convo. This is very common in messaging apps and a known issue on WhatsApp, Telegram, many other ones and Signal also has the ability to attach users to convos. The moment you have another participant all the end to end encryption is moot.

Focusing on just encrypted backups is probably what third parties want people to focus on, because they are third parties and want you to use them, but even if you trust them, how long can they be trusted. When it is bought out by private equity later that can get bad. Now they might sift everything. It is alot like those VPNs that say "we retain no logs" but they divert them to a third party and when it is reviewed the logs surely aren't there, but they are still out there.

2

uwu2420 t1_j9xwdgk wrote

The backup files not being encrypted is the whole point though. What good is everything else being encrypted if you can just subpoena or get a copy of the backup where all of that stuff that was encrypted is in plaintext lol

> Phone backups also don’t have to go to iCloud

Yes, but it’s on by default, and the majority of users have it turned on. Advanced Data Protection means you’re giving up a lot of account recovery options so most users don’t have that on, plus it’s only ~3 months old.

> This all falls apart when a participant is added

Well.. then just don’t add participants you don’t trust to your group chats…

> Focusing on just encrypted backups

But it’s a big issue lol. See above and refer to the slides I linked in the earlier comment. Again, what good is the encryption if there’s an easily available plaintext version too?

> When it is bought out by private equity

Signal is open source and you can run your own server if you want.

1

drawkbox t1_j9xxebn wrote

I mean pretty much anything in a cloud should be considered secure from everything but law enforcement.

The point is you still need the user context/auth. These files only work with the OS to access them. Like an iOS app or Windows Store data/settings in an app, that is specifically signature/encrypted to your user. Outside of that context it is useless. Third party ones are usually not tied to OS/browser/app for a reason.

I think most people are worried about hackers/ransomware/criminals over law enforcement so if you use the cloud that is why people are willing to make that tradeoff. The most insecure place is the local systems most likely, very easy to compromise a user compared to Apple/Google/Microsoft. It is possible but way more difficult. You almost have to be rogue state level funded for that.

> Well.. then just don’t add participants you don’t trust to your group chats…

Sure, but there is a 'ghost' user ability. In many messengers this is used to look for spam/moderation or other potentially nefarious reasons. Any chat system that has the ability to connect more than two people has the potential for you to not see the user. This is the most common use like in honeypot apps.

Encrypted messaging app used by criminals was actually an FBI honeypot

>> The encrypted messaging app in question was called ANOM, and was installed on special smartphones that couldn’t make calls or send emails. ANOM purported to be end-to-end encrypted, meaning only the sender and receiver could view messages. In reality, every single message was passed to police, who used them to make the arrests.

Ghost users is a major problem in "secure" messaging apps. There are plausible deniability reasons for them, spam detection, moderation etc, that is the rub.

> if there’s an easily available plaintext version too?

It is only plaintext in the context of the user... Taking it out of that context it is no longer. People make this claim about browser password managers but everything is tied at the system level to the user. Sure if the person gets the user context then they can get the files unencrypted, that is how it works. That would mean everything is compromised even your "secure" third party messenger like Signal.

> Signal is open source and you can run your own server if you want.

Yes. Still doesn't mean a third party that relies on messaging only is trustable.

Apple/Google/Microsoft have a vested interest in securing all your content, you don't have to worry about them stealing messages or siphon.

All of them will be open to law enforcement most likely because there are so many attack vectors in systems and especially third parties that don't have the sophistication at the cyber security level simply due to cost.

1

uwu2420 t1_j9xyhri wrote

> I mean pretty much anything in a cloud should be considered secure from everything but law enforcement

Again, nope. If a cloud service is truly end to end encrypted, and designed well, nobody but the end user should be able to access the data. Yes, even if there is a subpoena.

> The point is your still need the user context

Or if you have access to the files on Apple’s server, then no user auth is required.

> These files only work with the OS to access them

Again, no. There are many commercial and open source tools that are able to read the backup file for you. Elcomsoft, iMazing and the Citizen Lab Mobile Verification Toolkit are some examples.

> Most people are worried about hackers

It wouldn’t be the first time someone’s iCloud account was hacked into.

> there is a “ghost” user ability

Show me where in the Signal code there is this functionality. Again, it’s open source, so a honeypot would be quickly found. Also, if you’re worried about state level honeypots, note that retrieving an unencrypted iCloud backup is a lot easier.

> It is only plaintext in the context of the user…

…and anyone with access to the files on Apple’s servers, which aren’t only subpoenas but also hackers, governments that don’t respect human rights, etc. which is the whole point of having end to end encryption, even the service provider themselves should not have the ability to access the data on your account.

Do you not understand the point of end to end encryption? The whole point is that nobody, not even the service provider hosting the cloud service can access your data.

1

drawkbox t1_j9xzevz wrote

> If a cloud service is truly end to end encrypted, and designed well, nobody but the end user should be able to access the data.

I agree this is just not the case with so many holes and side channels out there. The cloud is good for securing content from others, oversight will always find a way. Anyone that thinks otherwise is a suka.

> Or if you have access to the files on Apple’s server, then no user auth is required.

User auth still required but yeah you could hack Apple I supposed and get it. Good luck though.

> There are many commercial and open source tools that are able to read the backup file for you. Elcomsoft, iMazing and the Citizen Lab Mobile Verification Toolkit are some examples.

If those apps are getting the user context then sure. If not then no.

Take Elcomsoft for instance with LastPass vs Password managers. That is why you don't install clients or extensions, like LastPass.

Read this closely:

>> Windows Data Protection API Not Used

>> One may argue that extracting passwords stored by the Google Chrome browser is similarly a one-click affair with third-party tools (e.g. Elcomsoft Internet Password Breaker). The difference between Chrome and LastPass password storage is that Chrome makes use of Microsoft’s Data Protection API, while LastPass does not.

>> Google Chrome does, indeed, store user’s passwords. Similar to third-party password managers, the Windows edition of the Chrome browser encrypts passwords when stored. By default, the encrypted database is not protected with a master password; instead, Chrome employs the Data Protection API (DPAPI) introduced way back in Windows 2000. DPAPI uses AES-256 to encrypt the password data. In order to access passwords, one must sign in with the user’s Windows credentials (authenticating with a login and password, PIN code, or Windows Hello). As a result, Google Chrome password storage has the same level of protection as the user’s Windows login.

>> This, effectively, enables someone who knows the user’s login and password or hijacks the current session to access the stored passwords. This is exactly what we implemented in Elcomsoft Internet Password Breaker.

>> However, in order to extract passwords from Web browsers such as Chrome or Microsoft Edge, one must possess the user’s Windows login and password or hijack an authenticated session. Analyzing a ‘cold’ disk image without knowing the user’s password will not provide access to Chrome or Edge cached passwords.

>> This is not the case for the LastPass Chrome extension (the desktop app is seemingly not affected). For the LastPass database, the attacker will not need the user’s Windows login credentials of macOS account password. All that’s actually required is the file containing the encrypted password database, which can be easily obtained from the forensic disk image. Neither Windows credentials nor master password are required.

>> macOS has a built-in secure storage, the so-called keychain. The Mac version of Chrome does not use the native keychain to store the user’s passwords; neither does the iOS version. However, Chrome does store the master password in the corresponding macOS or iOS keychain, effectively providing the same level of protection as the system keychain. Elcomsoft Password Digger can decrypt the macOS keychain provided that the user’s logon credentials (or the separate keychain password) are known.

Elcomsoft mentions the OS level protections on these.

> It wouldn’t be the first time someone’s iCloud account was hacked into.

If someone gets into iCloud they are most likely getting into the device and again, the point of a "secure" messenger or cloud falls apart because they have access to their user. Yes, people should be careful with their user, it opens up everything.

> not even the service provider hosting the cloud service can access your data.

If you believe this then you believe in magic. Even if a provider tried to do this, software has holes... See OpenSSL/Log4j/Log4Shell/on and on and on and on... The fact that you trusted it because they said they don't look, it was probably a lie, but even if it wasn't they can get in.

1

uwu2420 t1_j9y02jf wrote

Yeah I agree there are always vulnerabilities in software, but the thing is, as far as I know, there aren’t any known bugs that would leak data from Signal so far despite all the security research attention it gets, and plenty of evidence that it’s safe.

Meanwhile, I’ve already explained how it’s trivial to get around the end to end nature of iMessage for a large majority of users.

If you don’t care about your conversation being end to end encrypted, then yes, by all means, use iMessage or even just plain SMS. Much easier. But if you do care, I’m not sure why you’d shoot yourself in the foot with the option known to have a major workaround.

1

drawkbox t1_j9y2ig6 wrote

Signal definitely seems the best out of them if you are into using a third party messenger, for now.

I would still trust the OS level messaging on mobile over third parties because of the scale, future funding, incentives and trust. The OS already has access to your info. Other people getting access to your data is probably always easier on third party systems, even if the third party is trustable, not ever person or dependency is.

iMessage is secure, if you are going straight SMS yes that is more open. I also know what Apple wants and their goals fully, that is a secure platform that isn't just messaging.

The fact is though, every system has holes and security issues, so the best opsec is less third parties, big or small or open or closed...

Just ask Jeff Bezos after he got hacked via WhatsApp temp hole by something sent to him by freaking MBS.

1

uwu2420 t1_j9y3ix1 wrote

The thing you’re missing is, if you’re using Signal you specifically want an end to end encrypted chat service.

The OS doesn’t upload that data in unencrypted form. You can analyze for yourself with a MITM proxy.

iMessage is secure, as long as you don’t care for your messages remaining end to end encrypted, and you trust Apple to have a copy of your messages. Is that reasonable to you? Maybe, maybe not.

With Signal, the whole idea is you shouldn’t have to trust Signal with your messages, because they don’t have the ability to read them, even if they wanted to. Yes, it could have holes like any software, so this can really be simplified to: use the tool with a known issue for sure, vs use the tool that might have an issue in the future but for now is known to be safe.

1

drawkbox t1_j9y44d1 wrote

> end to end encrypted chat service

End to end means nothing though when a client isn't in your control and may have another user attached. Again, common in many messaging apps.

iMessage is end to end encryption to iMessage, just like Signal to Signal. If you use SMS it is not.

> We designed iMessage to use end-to-end encryption, so there's no way for Apple to decrypt the content of your conversations when they are in transit between devices. Attachments you send over iMessage (such as photos or videos) are encrypted so that no one but the sender and receiver(s) can access them

Apple can't magically make SMS secure, it is not secure by default as it was really from telephone diagnostics and repurposed for messaging. So when you message Android it goes SMS. SMS was from SS7 and really only for diagnostic or messages to customers for testing. MMS is better but still not that great. Apple should bring iMessage to Android and do better on messengers, it is leading many people to third parties that open up opsec issues.

> With Signal, the whole idea is you shouldn’t have to trust Signal with your messages, because they don’t have the ability to read them, even if they wanted to.

That is a bold statement. Yes, on the surface. Again, ghost users, compromised clients, endpoints can have problems. Also Signal does have a proprietary shim for monitoring, spam checking and other things, could easily be used to surveil or sift. There are probably a dozen ways or more to get around it currently at the dependency level or breaking their encryption as it is custom.

The best opsec is always less third parties.

−1

uwu2420 t1_j9y4q7s wrote

We can assume the majority of people go with the default settings. iMessage conversations, by default, end up in a backup file on iCloud that is not end to end encrypted. Signal conversations, by default, do not.

> We designed iMessage to use end-to-end encryption

Which again is worthless when a plaintext version is also being uploaded in the form of iCloud backups, which are on by default. The same isn’t true for Signal.

You’ll have to provide a source for your claims about Signal’s ghost users. As far as a compromised client, that’s not something any messaging client can defend against, and if a service is end to end encrypted, it shouldn’t matter if the endpoint server is entirely compromised.

> breaking their encryption as it is custom

That’s the cool part, it’s not. It’s based on the same old algorithms that have been around for years. ECDSA, ECDH, AES, etc. if I remember correctly

It depends on your definition of opsec but just a reminder that we’re in a thread about Signal and end to end encryption specifically.

2

drawkbox t1_j9y5gri wrote

You dismiss user level auth/encryption like it is nothing. If anyone had access to user level auth why go to the backup file, just go to the device, load up Signal and scrape their messages.

All other messaging apps have the "ghost user" problem confirmed.

Signal has a shim for spam that is very unclear, I'll just say that. There are other things around Signal that make is sus in my opinion.

> The source code for spam detection is not public.

So there is a plausible deniability reason to hide some code... you have to trussssst. Here's the kicker, you can't check for spam if you aren't seeing the message.

Even on the self installed versions...

> Signal's servers are partially open source, but the server software's anti-spam component is proprietary and closed source due to security concerns

Signal does handle users being added better, but this could just be theater as well.

> The real problem with the GCHQ proposal is that it targets a weakness in messaging/calling systems that’s already well-known to providers, and moreover, a weakness that providers have been working to close — perhaps because they’re worried that someone just like GCHQ (or probably, much worse) will try to exploit it. By making this proposal, the folks at GCHQ have virtually guaranteed that those providers will move much, much faster on this.

> And they have quite a few options at their disposal. Over the past several years researchers have proposed several designs that offer transparency to users regarding which keys they’re obtaining from a provider’s identity service. These systems operate by having the identity service commit to the keys that are associated with individual users, such that it’s very hard for the provider to change a user’s keys (or to add a device) without everyone in the world noticing.

> As mentioned above, advanced messengers like Signal have “submerged” the group chat management into the encrypted communications flow, so that the server cannot add new users without the digitally authenticated approval of one of the existing participants. This design, if ported to in more popular services like WhatsApp, would seem to kill the GCHQ proposal dead.

I personally don't trust Signal for a few reasons beyond these items, but if you trust them then rock on.

−2

uwu2420 t1_j9y65ub wrote

> You dismiss user level auth

To scrape my Signal messages, you need access to my physical device, and you need my passcode. To get access to iMessage messages, all you need to do is get my latest backup, or the backup of the person I talked to, off of Apple’s servers, for example, with a legal request, which completely bypasses the need for any user level auth/encryption.

Agree to disagree

2

drawkbox t1_j9y8ajk wrote

> To scrape my Signal messages, you need access to my physical device, and you need my passcode.

Same with getting access to your iCloud/Apple account.

> To get access to iMessage messages, all you need to do is get my latest backup, or the backup of the person I talked to, off of Apple’s servers, for example, with a legal request, which completely bypasses the need for any user level auth/encryption.

As I said, anything stored in a cloud will have some oversight. Anyone that thinks storing something in a cloud is secure from oversight is dim.

If you think anyone from enforcement can just get your iCloud/Apple account, that would also mean they are able to access your device and everything on it including your "encrypted end to end" Signal messages that are plaintext on your client.

Messaging apps also get cam/mic/location/contacts permissions, Signal is no different, one more entity with your face/voice/place/friends.

You can trust Signal, a third party, rock on. Acton is involved in both, from WhatsApp, went to Facebook, and then when people stopped trusting Facebook he made Signal to catch those leaving. The story is he didn't trust Facebook, no one should, but can you trust Signal/Acton or is it a front. You decide. Problem is you trust them so much they got ya. I mean Elon Musk and Edward Snowden recommend it... is must be safe /s. Signal is maybe safe, maybe safe from some five eyes, but not all eyes not in the five. Even then, there are always ways to get in via dependencies and devs (mainly devops) are the weak link today sadly.

Agree to disagree, good discussion though.

0

uwu2420 t1_j9y8y3c wrote

> Same with getting access to your iCloud/Apple account

No you don’t, because it is stored unencrypted on Apple servers and Apple themselves will give it to you (for example, with a legal request). If you go this route, you don’t need the physical device or any of the user’s passwords. The user won’t even know it’s happened until they are told.

The difference is in one case, my password and my physical device is needed. If you want that, you’ll have to physically get my device from me, and then get me to tell you my passcode. The other is just stored on Apple’s servers. If you don’t see how one is much harder than the other, I dunno what to tell you lol

Edit: no need to believe me, believe American law enforcement instead and refer to the leaked slide I posted earlier.

2