Warn when using non HTTPS connection

[mluisbrown]

When trying to decrypt secrets on my homepage, having accessed it with http instead of https I got the rather unhelpful error:

Decryption failed: TypeError: Cannot read properties of undefined (reading 'importKey')

Only after checking your example with an incorrect password did I realise the error was not related to my password (which I was sure I had correct).

Then I realised I was using http and that might cause Crypto APIs to not work, which was indeed the problem. It might be helpful to warn users that this only works over an SSL connection.

[TeddyBear06]

Hi,

The secrets doesn't require an HTTPS server to extract (only the creator, as stated in the creator readme).

Edit: In the end, not exactly, see #35 (comment) for a more detailed answer.

[mprimi]

@mluisbrown I think you are correct, according to this, HTTPS is required for crypto.subtle, and a more clear error should be presented otherwise.

Keep in mind that there's always a workaround: save html from your (http) server as a file then open it in the browser as a local file. The browsers I've tested allow crypto.subtle for file:///, so you can decrypt.

[TeddyBear06]

Good catch, I was misleading by the fact that I've always opened secrets in file:/// context.

From Chromium point of view:

“Secure origins” are origins that match at least one of the following (scheme, host, port) patterns:

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

This list may be incomplete, and may need to be changed.

[TeddyBear06]

In order to summarize, it's not - directly - related to HTTPS, HTTP nor file:/// but more with the notion of "secure contexts".

For example, serving your secret locally under http://localhost will allow you to extract it without any kind of issue regarding Crypto APIs because localhost is considered as "secure".

The isSecureContext property seems to be fully supported and indicates exactly if the current context is considered as secure or not.

I'll propose a draft PR that try to detect ASAP the potentially insecure context and display a usefull message to the user (it's all arbitray and open to suggestions, of course) but it can look like in the picture below.

On the picture below, on the left side, the "insecure" context and its - potential - warning message. On the right side a context that is considered as "secure" (without the warning message, of course).

[TeddyBear06]

Let summarize my proposal #36 in two parts as creator and secret does not meets the same requirements.

A - Concerning the creator:

Requires HTTPS at any time.

Message: Please host this tool on an HTTPS server (notice that some browsers are not happy with a self-signed certificate).

B - Concerning the secret:

Requires a "secure context" (given by the isSecureContext property).

Message: The current browser context is not considered "secure" and portable-secret won't work properly. Please open this secret from your local filesystem (file://) or from an HTTPS server.