Privatebin: Webcrypto doesn't work for insecure connections in Chromium-based browsers.

[Lmmb74]

Steps to reproduce

1. Redirect a custom address to your machine (in my case: host.protonet.tk)
2. Access the address (in my case: host.protonet.tk/paste)
3. Send a paste

What happens

Apart from not sending the paste, it displays the following error in the console:

What should happen

It should send the paste.

Additional information

If you send a paste with no password in your localhost, it will do it and you will be able to display it through the generated link. But when you try to access that same paste through the external address, it will ask for a password.

Basic information

Server address: http://host.protonet.tk/paste

Server OS: Windows 10 Pro x64

Webserver: Bitnami WAMPStack 7.3.2

Browser: Google Chrome (75.0.3770.90)

PrivateBin version: 7ab6411f71ead2513d6cda23300b48ec4ef0f913

I can reproduce this issue on https://privatebin.net: No

[r4sas]

I seen same (almost) issue here: https://github.com/PrivateBin/PrivateBin/issues/432#issuecomment-494996434
Happens when paste created with HTTPS opened on HTTP page.

[Lmmb74]

But I'm not accessing localhost using https...

[r4sas]

So that only when you trying send paste?
Can you try crease self-signed certificate and try with HTTPS? Is it reproducable with it?

Ah, I got it... jquery was recently updated, and, looks like unshift no more presented in it or so.
/cc @elrido
https://stackoverflow.com/a/49814371

[elrido]

Thanks for investigating and pointing out the solution. Will fix the unshift usage.

[elrido]

Looking at the stack trace from the screenshot and with the suggestion above, I think an exception occurs during the encryption that is caught and is supposed to be displayed, but can't as it isn't a string or an array containing a string.

The commit I just added won't fix the underlying issue, but should make it possible to display the error message from the exception. Please let us know what message gets displayed and we may finally figure out what is preventing you from creating these pastes.

[Lmmb74]

Here is the new error thrown by the console:

[elrido]

So for some reason the JSON fails to be encoded/decoded when the site is on HTTP?

I can now reproduce this in Chrome. Had a bit trouble to get it to work as all my test sites use HTTPS with HKPS and I had to figure out how to trick chrome into staying on HTTP. I'll see if I can crack this nut.

[r4sas]

So for some reason the JSON fails to be encoded/decoded when the site is on HTTP?

Seems like this.
In 1.1.1 I never seen that problem (used in I2P). With 1.2.1 must work also.
I can test with trunk if needed.

[elrido]

Yes, it is in master.

[r4sas]

Fall in same place:

>privatebin.js?1.2.1:3925
parsererror SyntaxError: Unexpected end of JSON input
    at parse (<anonymous>)
    at jquery-3.4.1.js:2
    at l (jquery-3.4.1.js:2)
    at XMLHttpRequest.<anonymous> (jquery-3.4.1.js:2)
(anonymous) @ privatebin.js?1.2.1:3925
c @ jquery-3.4.1.js:2
fireWith @ jquery-3.4.1.js:2
l @ jquery-3.4.1.js:2
(anonymous) @ jquery-3.4.1.js:2
load (async)
send @ jquery-3.4.1.js:2
ajax @ jquery-3.4.1.js:2
jQuery.PrivateBin.me.run @ privatebin.js?1.2.1:3924
jQuery.PrivateBin.me.sendPaste @ privatebin.js?1.2.1:4315
async function (async)
jQuery.PrivateBin.me.sendPaste @ privatebin.js?1.2.1:4243
dispatch @ jquery-3.4.1.js:2
v.handle @ jquery-3.4.1.js:2

add:
Replaced minimized jquery with uncompressed, full stack here:

parsererror SyntaxError: Unexpected end of JSON input
    at parse (<anonymous>)
    at ajaxConvert (jquery-3.4.1.js:formatted:8297)
    at done (jquery-3.4.1.js:formatted:8732)
    at XMLHttpRequest.<anonymous> (jquery-3.4.1.js:formatted:9020)
(anonymous) @ privatebin.js?1.2.1:3925
fire @ jquery-3.4.1.js:formatted:2990
fireWith @ jquery-3.4.1.js:formatted:3117
done @ jquery-3.4.1.js:formatted:8784
(anonymous) @ jquery-3.4.1.js:formatted:9020
load (async)
send @ jquery-3.4.1.js:formatted:9037
ajax @ jquery-3.4.1.js:formatted:8684
jQuery.PrivateBin.me.run @ privatebin.js?1.2.1:3924
jQuery.PrivateBin.me.sendPaste @ privatebin.js?1.2.1:4315
async function (async)
jQuery.PrivateBin.me.sendPaste @ privatebin.js?1.2.1:4243
dispatch @ jquery-3.4.1.js:formatted:4782
elemData.handle @ jquery-3.4.1.js:formatted:4604

[elrido]

In adding some breakpoints I noticed that there is an error shown first that gets overwritten be the one shown above. It's "Cannot read property 'encrypt' of undefined".

Addendum: Ok, that is actually the Webcrypto API that isn't available in Chrome when using HTTP. See this "wontfix" bug https://bugs.chromium.org/p/chromium/issues/detail?id=683864#c4.

[elrido]

@Lmmb74 - For your use case, please use any browser except Chrome (or IE). That is a convincing argument for introducing that HTTP warning in #407.

[r4sas]

In that case we need some fallback...

[elrido]

Not gonna re-introduce SJCL for a single browser in an unusual use case. Users can still use 1.2.1 if this is required.

[r4sas]

Not gonna re-introduce SJCL for a single browser in an unusual use case. Users can still use 1.2.1 if this is required.

I'm not about SJCL, but about some library, which can do all stuff for chrome-based browsers instead webcrypto.

[r4sas]

Something like this: https://github.com/vibornoff/webcrypto-shim

[rugk]

but about some library, which can do all stuff for chrome-based browsers instead webcrypto.

Which is basically SCJL, or a polyfill based on SJCL that wraps around the webcrypto API. That said, such a thing does not exist: https://github.com/bitwiseshiftleft/sjcl/issues/317

---

But a real WebCryto polyfill is still a huge dependency: https://github.com/PeculiarVentures/webcrypto-liner http://polycrypt.net/ https://github.com/PeculiarVentures/webcrypto-liner

[elrido]

The whole reason we wanted to get rid of SJCL was because we do have to rely on a crypto library shipped through an insecure channel. Webcrypto comes with the browser and the user doesn't have to trust the transport.

You are proposing that we readd tons of logic just for users of a single browser under certain unusual conditions?

If you need it to work in Chrome use HTTPS. If you need it in Chrome using HTTP, then use our existing release that does that already. The new release will anyway present you a nasty warning if you access it via HTTP.

[r4sas]

shipped through an insecure channel

Not every transport is insecure.
Don't forget about Tor, I2P, yggdrasil, etc. networks, where transport secured out-of-box. And in that networks nothing can be done about SSL without poking user about SSL - self-signed certificate always will make dissapoint in eyes of user with it's noisy notifications about security :smile:

So, that discussion as about double-edged stick.

[Lmmb74]

Well, tested in Firefox and Edge through HTTP and it works fine. I guess I will have to create a self-signed certificate so I can use PrivateBin in Chrome. Thanks for all your help.

[elrido]

Not every transport is insecure.

The one big legitimate criticism of this project (see for example in the 2014 code review, point 4.1), is the one against the use of JS based crypto. We can't fully resolve this in the scope of a traditional webapplication. The use of a browser built-in library instead of JS shipped along the site is a big step forwards, but the user still has to trust on the rest of the code not doing anything to compromise his data.

To quote our own report on the measures taken on the code reviews critizisms:

Server admins can reduce the potential for man-in-the-middle attacks by setting up HTTPS following high standards. [...]

But as long as the encryption logic is delivered by the server, the risk of manipulation is always a possibility. This is not fixable and therefore users have to trust the webserver running PrivateBin. [...]

This is why having the option of a python client is actually very important. With that, you can create pastes securely without relying on the server or the transport being secure. And you still can send your recipient a link and they can choose to trust their transport + the webserver and open it in a browser for conveniance or use another client with built in crypto if they don't trust them.

To our softwares credit, the main reason why a server admin chooses our solution over other pastebins is that they don't _want_ to know the contents that are stored in it. Most server admins have a high motivation of not introducing anything that would make them liable and responsible for the content the host in PB.

[r4sas]

Okay. In that case lets add in #407 a restriction with message and description that webcrypto doesn't works under chrome when trying open HTTP page, independently which kind of transports (tor, i2p, etc.) is used.

[r4sas]

I wrote "Chromium-based" because in most of tested by me browsers I see same result:
Opera, Vivaldi, Bromite (android).

[rugk]

Don't forget about Tor, I2P, yggdrasil, etc. networks, where transport secured out-of-box

Is anyone of these used by Chrome/ium? Because I know Tor Browser uses Firefox, so is not affected by this here. (And no, using Tor with another browser is not secure.)

[r4sas]

Is anyone of these used by Chrome/ium? Because I know Tor Browser uses Firefox, so is not affected by this here. (And no, using Tor with another browser is not secure.)

Nothing prevents to fine-tune and further use them. For example, I do this for Chromium to use with I2P.

Yggdrasil is just overlay network which accessible from any software (200::/7 IPv6 network provided by tun inteface), so here no restrictions and main part of network is HTTP without TLS. See public services.

[r4sas]

Just for note: I'm decided to add webcrypto-liner in my I2P installation. That was already tested with ungoogled-chromium and correctly works.

[rugk]

So our final decision is: We won't add a polyfill for fixing this edge case.

You can read more about why and how in the FAQ: https://github.com/PrivateBin/PrivateBin/wiki/FAQ#why-does-it-show-me-an-error-about-an-insecure-connection

Some arguments/reasoning:

• browser vendors likely will stop supporting the Web Crypto API over insecure channels, i.e. HTTP. This is based on a W3C decision, so it's only a matter of time until Firefox will follow this.
• We have long advocated for HTTPS, and the only cases where HTTP is secure (Tor/I2P services) are rare. So the introduction of such a polyfill or library would be only for some minor edge-cases.
• Actually, Tor onion sites are considered a secure context in Tor Browser:
  
• A introduction of any library or so always causes the potential to introduce (security) bugs/risks and we like to avoid them. It's not worth introducing such a huge dependency only for fixing such a little edge-case.
• And as the FAQ entry shows, if a server admin really wants to use PrivateBin over HTTP or so, they can always add a WebCrypto API polyfill by themselves. On their own risk!

Thus closing this as "wontfix".