Security of hubzilla communications from surveillance

2025-02-08 07:16:17

adminsforum@hubzilla.org

citc wrote the following post Sat, 08 Feb 2025 07:16:16 -0600

Security of hubzilla communications from surveillance

UK government has extant legislation ('investigatory powers act') that has been used to order a certain 'AMGAF' company for access to encrypted data. Unsurprisingly, other organisations in so-called democratic countries want similar power (Europol, FBI).

How secure is information within the hubzilla system?

https://www.washingtonpost.com/technology/2025/02/07/apple-encryption-backdoor-uk/

show all 21 comments

2025-02-08 07:54:04

Scott M. Stolz

scott@loves.tech

When transmitted or on the server? Zot protocol or ActivityPub?

If you have "Even More Encryption" turned on, you can create encrypted posts that require a shared key. I believe these are stored encrypted in the database, and only people on Hubzilla can open them (with the correct key and with the correct permissions, of course). Maybe people on (streams) can open them as well since it supports Zot6. The Admin would not be able to open these without the shared key.

I remember Mike mentioning that Zot Protocol is double encrypted in transit, once by Hubzilla, and then again by SSL.

If you don't encrypt your posts, or you send it over ActivityPub, it's not encrypted, other than using SSL in transit. The receiving server probably stores the incoming posts in plain text.

So, encryption is available server side, but it is optional, and only for posts transmitted from Hubzilla to Hubzilla. And it is double encrypted in transit over Zot6, and, as far as I can tell, single encrypted over ActivityPub.

Since it is a social platform that is designed to communicate with a variety of platforms, it is hard to enforce end-to-end encryption when communicating with platforms other than Hubzilla.

2025-02-08 10:14:08

citc

citc@zotum.net

The text box 'comment' to reply within a thread as option 'encrypt text', then a dialogue window to request the password.

Why is this option available to the user (usual question about documentation)

2025-02-08 16:25:51

Scott's Code Journal

scott@codejournal.dev

@citc The Admin can turn on or off this feature in the Editor section of: /admin/features/

I am not sure if the user can turn this on or off. If they can. I am not sure where.

2025-02-09 02:40:49

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz There's no double encryption. The connection between the servers use TLS, as is normal these days, but there's no additional layers of encryption. Not that there would be much value in such an extra layer in any case.

The database and file storage is not encrypted outside of any file system/disk encryption provided by the operating system. Again, such encryption would not have much value as the keys to access the plaintext would also have to be accessible to the system, which in practice reduces it to no encryption anyways.

2025-02-09 06:36:19

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen

There's no double encryption. The connection between the servers use TLS, as is normal these days, but there's no additional layers of encryption. Not that there would be much value in such an extra layer in any case.

Maybe that is just in (streams) then, because I remember Mike commenting on it.

2025-02-09 06:41:15

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen

The database and file storage is not encrypted outside of any file system/disk encryption provided by the operating system. Again, such encryption would not have much value as the keys to access the plaintext would also have to be accessible to the system, which in practice reduces it to no encryption anyways.

I never said it was.

The only reason why "Even More Encryption" works is because the shared key for the post is not stored in Hubzilla at all.

Maybe that is what Mike was referring to when he said that the posts were double encrypted?

2025-02-09 06:45:47

citc

citc@zotum.net

The option 'encrypt' text is available both at the start of a new post, or a separate comment to an extant post.
If the database nor the files are not encrypted, what is the purpose of this option?
How is the option 'encrypt text' supposed to be used successfully?

2025-02-09 07:06:38

Scott M. Stolz

scott@loves.tech

@citc

If the database nor the files are not encrypted, what is the purpose of this option?

The encrypted post or comment is stored encrypted in the database. The recipient would need the shared key to unencrypt it.

In fact, your browser encrypts it using JavaScript BEFORE it is even sent to the server. So the server does not even know what the shared key is.

This encrypted message (click on lock and enter password "wistex"):

Is stored in the post (in the database and when transmitted) as:

[crypt]eyJoaW50IjoiNzc2OTczNzQ2NTc4IiwiYWxnIjoiWFNhbHNhMjAiLCJzYWx0IjoiZDljZDQ0Y2Q4YTRhY2I5MTU1ZWVlZmVlNThkODEzMDYiLCJub25jZSI6ImFmY2FiMzQ3ZjJhMGI4NDIzOWQyMGMzMjk5YzE0MDMzN2I5ODM4ZTQwNTY1OWIwYiIsImNpcGhlcnRleHQiOiI0MWU5NDYyOGFhMDM1NjYzYzk5OTI0NGI0OWUzNTNjMzU2ODg1YmY3NWFiZThkMzNhZGRmMWY2ZmUyYmE1MmNlZGE5NmY0In0=[/crypt]

Notice that you can mix encrypted text with plain text in the same post.

Note: Those not on Hubzilla will probably see nothing or just a bunch of code.

2025-02-09 07:18:02

citc

citc@zotum.net

The 'lock' cannot be seen, to test this behaviour

2025-02-09 07:21:56

citc

citc@zotum.net

Have just noticed that the 'lock' image is not visible due to an extension used 'imageblock'. Disabled the extension, to see the image.
There was no 'alternate text' attribute with the image; not accessible in accordance with W3C guidance.
This observation also promotes the question: "how do you send the password?" ;)

2025-02-09 07:30:04

Scott M. Stolz

scott@loves.tech

@citc

This observation also promotes the question: "how do you send the password?" ;)

You tell the recipient the password using some other secure method. If you sent it over Hubzilla, you would compromise security.

2025-02-10 02:40:26

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz

I never said it was.

Sorry, didn't mean to imply you were either. Just mentioning it for completeness.

2025-02-11 05:06:14

Mario Vavti

mario@hub.somaton.com

@Harald Eilertsen

There's no double encryption.

In fact zot server to server communication is double encrypted if the post is not public. The package is encrypted with the receivers site key prior to sending it over the wire.

2025-02-11 05:16:23

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen

Not that there would be much value in such an extra layer in any case.

The reason I knew there was double encryption was because a few years ago there was a TLS/SSL exploit that allowed certain actors to break the encryption and read sensitive communication under specific conditions.

https://thehackernews.com/2020/09/raccoon-ssl-tls-encryption.html

I am not sure if this was the specific incident, but I do remember Mike posting about how everyone thought his double encryption was overkill, and he was just proved right since hackers managed to get around the TLS encryption.

2025-02-11 06:03:11

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti Ah, yes that may be. Still I'd rather rely on TLS than any home grown solution for transport security. You have to be really careful to not introduce timing based side channels or other subtle flaws that actually weaken the protection instead of strengthening it.

And seeing stuff like this in the code doesn't increase my confidence:

         if ($this->error) {
            // make timing attacks on the decryption engine a bit more difficult
            usleep(mt_rand(10000,100000));
            return($this->response);
        }

2025-02-11 06:07:36

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz Tbh, I'd think anyone able to bypass TLS – whether it's with Raccoon, Heartbleed, POODLE or any of the other attacks against older TLS versions – would be able to get through the custom encryption added by Hubzilla as well if they wanted.

2025-02-11 09:08:43

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen The double encryption was created by Mike, who pioneered all of this stuff. And one of his main concerns in privacy. So I trust his solution, especially when combined with TLS.

As with any type of security, someone determined enough will be able to break it. That does not mean we should make it easy for them.

Also, it uses the same keys we use to verify a channel's identity. So we are already using encryption in the main functionality of Hubzilla.

2025-02-11 09:10:33

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen Actually, it probably should increase your confidence. It means he anticipated potential breaches and/or responded to a breach to make it more secure. I would be worried if such code did not exist.

2025-02-11 10:18:56

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz The point is, that that code snippet provides no added security, and shows that the author does not properly understand the problem. There's a good explanation (which discusses this very example) here: https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html

Cryptography is hard, and doing it badly can actually hurt security rather than enhancing it. I'm not saying that the implementation in Hubzilla does that. I have neither the time nor the knowledge to prove that it does (or that it doesn't). But as said, the snippet and comment in my previous reply does not inspire confidence.

Also, it uses the same keys we use to verify a channel's identity.

The keys are not he issue here, neither is it whether we are using encryption or not. It's how we're using it, and whether the implementation leaks information via side channels or not.

2025-02-11 10:27:28

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen A good look over from time to time is a good idea. That way we keep Hubzilla secure.

But I would not want to see the double encryption removed because "we don't need it."

2025-02-11 11:31:06

Marshall Sutherland

dwatney@hub.farthinghalearms.com

Tbh, I'd think anyone able to bypass TLS – whether it's with Raccoon, Heartbleed, POODLE or any of the other attacks against older TLS versions – would be able to get through the custom encryption added by Hubzilla as well if they wanted.

You probably aren't going to be dealing with whoever actually knows how to bypass TLS, but instead a script-kiddie who downloaded an exploit tool. Once they encounter another layer or encryption, they are stuck unless someone else has solved this problem for them.

Mike has said on many occasions that this isn't designed to stop state-level actors.