Browser Extension for encryption on sites that don't support it natively

I have recently released a browser extension for easy encryption and decryption on sites that don't support it natively. It is an extension for Chromium/Firefox. Users can do ephemeral key exchange to share a symmetric key with a correspondent, and use that key to encrypt and decrypt any communications to them. We are targeting sites that don't have support for encrypted communication (Discord, Slack), and sites that don't respect user privacy (Weibo) to mitigate data mining. If a site is not supported, encryption can still occur in the extension popup, and decryption is site agnostic.

More information is available in the README, along with links to download the extension. If you have any questions, I am happy to clarify anything.

https://github.com/XCF-Babble/babble

 

Interesting and seems to have pretty decent security. Well, but I need to have my counterpart to install the extension. One question from curiosity, IIRC Libsodium provides three security levels for Argon2 each corresponds to 32(64?)MB, 128(256?)MB, and 1GB memory, so what parameter is used for your tool? I guess the lowest one, to be compatible w/ mobile browser, anyway 32MB Argon2i should give decent security for moderately secure passwords especially if iteration count is 10+.

Also I don't know much about browser and web, but is your iframe secure even in this condition: an adversary knows you're using the tool and its address, and even can trick the user to click on a malicious link (not for memory corruption, but an additional explanation for in-sandbox memory corruption is welcome) when they're encrypting or decrypting? I don't know how web accessible resource is different, but if it was an usual site, some protective header or CSP would be required.

 

We use constants defined in libsodium for interactive online operations. The memory limit is 64MB, although I would be open to increasing this value in an advanced options menu if this is something people wanted.

In the case of encryption, a malicious page cannot do anything. Plaintext is entered in the extension popup, which is completely isolated from the webpage. The plaintext is encrypted before it is sent to the page.

Decryption is done with an element picker and the inner text in the highlighted DOM element is sent to be decrypted inside of an iFrame. The reason for the iFrame is to display the decrypted content in the web page, while also ensuring the page cannot extract anything inside of the iFrame due to the same origin policy. The most a malicious page can do is delete the iFrame or overlay their own content on the iFrame. In both cases, I plan to mitigate this by detecting if the iFrame is removed/modified or if it is not in the viewport, then send a notification to the user.

Not sure I understand the question, but if a webpage can corrupt memory inside the browser sandbox, that would be a very serious bug in the browser.

 

Thx, so max of 64MB memory and minimum of 2 or 3 iteration of Argon2i or id, right? Just as a potential FYI, there's known time-memory trade-off attack against Argon2i when iteration is less than 10. It's not a big issue tho.
https://eprint.iacr.org/2016/759.pdf

That was what I thought of firstly. Can't you simply use CSP frame-ancestors or X-Frame-Options on the page? Sorry if I'm saying silly thing as I'm no IT geek.
I think if subsequent conditions (besides already mentioned) are all met, a XSS attack will also be possible: (1) resultant texts are dynamically generated on the page (chrome-extension://(your extension URI and parameters if any) by javascript/typescript) and there's no difference btwn usual websites and chrome-extension://, and (2) only protection is SOP. So the attacker tricks a victim to click a malicious link which contains the URI w/ a malicious script appended. Now he can execute arbitrary script on the URI, effectively bypassed SOP. Ofc these conditions are not very realistic, and my thought may be wrong. I'm just asking on curiosity.

I've added that on a whim. I guess if it was on Chromium which attributes different processes for each site, the attacker still can't do any harm, but if Firefox where process isolation is incomplete, he may be able to turn off webSecurityEnabled flag and send the texts via XmlHttpRequest. Anyway it's a matter of browser, sorry for asking non-relevant thing.

I like your tool, but persoanlly prefer it having access-data permission only for fully supported sites - tho I understand it actually works on any websites and it's anyway open source.

Other thoughts:
- Is the base of unique characters really needed? I think this may confuse people who don't use these languages. How about adding an option to output ASCII char or numbers?
- I think it's better to hide passphrase on Babble Keystore by asterisk to prevent shoulder surfing (click-to-open).
- Please add descriptive popup to each icon to explain what it does.
- It would be too difficult to use for common people - they don't know what the public key is and why they need to exchange it - it's okay if your tool targets only those who know how it works, but if not, UI need to be improved, tho I can't comment on it much.

 

I checked the libsodium source and it is 2. I looked at the paper and am definitely considering increasing the default iterations. Thanks. Unfortunately, 10 iterations is noticeably sluggish to derive a key on Chromium. No noticeable performance hit on Firefox since libsodium complied to web assembly is fast (Chrome supports web assembly in extensions, but I'd need the unsafe-eval permission, which is a security nightmare).

These are HTTP headers to mitigate XSS and Clickjacking respectively in webservers, and Babble does not run a webserver.

So the two attacks I believe you are describing is you and the attacker have a shared secret. The attacker sends you a babbled message with <script>, and this is executed inside of the iFrame. This doesn't work because the decrypted data is escaped before getting rendered. If the attacker sends a malicious link, the anchor tag has target="_blank", which opens the link in its own tab, not the iFrame. This this is no different than someone sending you a malicious link without babble.

It is for decrypting on sites we don't support. "Supported" just means the input from the popup is sent to the standard input box on the website.

These languages are chosen because ChaCha encrypts to 256 possible bytes, and we use those bytes as indices in a string to encode the data. Any set of 256 unique characters will work. We have chosen ours from frequency charts of popular languages. We are open to adding more preset bases (the field is also editable).

I agree with all of these and have made them blockers for the next release. Thanks.

 

Thanks for all the replies and clear explanation!

Well, what I was thinking is more like this: an app (Discord, Slack, etc.) has a workspace of three or more members, and one (A) in them is the attacker. He now sees members B & C are communicating on the app, and A knows B & C use your tool. Now A sends a malicious link disguised as a safe link, either via the app or email or anything. B or C was about to encrypt or decrypt, but now he stopped and opened the link which is like: chrome-extension://(your addon id)?(any parameter used in your addon)=<script>(malicious code)</script> for example.

If I understand you correctly, you mean it's safe because (1) decrypted data is escaped before rendering, and (2) it's inside iframe? For (1) it's good. I'm not sure about (2). If the link opens the same URI as src of iframe, SOP will not work anymore as they're same origin, so it should be possible to snoop the text and send it by script.

 

Oh, I see. None of the pages take any parameters. The extension communicates between pages via the browser messaging API.

 

Thanks, I've learned sth new!

As to Argon2, I don't take TMTO as much of concern, but this document seems to suggest Libsodium uses Argon2id by default since ver.1.0.15 (it also says iteration must be at least 3 for Argon2i). If this is the case, you don't need to worry about.