Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auth: use fixed jwt-secret when hosting on 127.0.0.1 #302

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

auth: use fixed jwt-secret when hosting on 127.0.0.1 #302

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3551ada
auth: use fixed jwt-secret when hosting on 127.0.0.1
lightclient Sep 6, 2022
a085c24
specify client generate a random token
lightclient Sep 22, 2022
0c4de22
auth: truncate default key to 256 bit
lightclient Mar 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions src/engine/authentication.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ Authentication is performed as follows:
- Clarification: The websocket handshake starts with the consensus layer client performing a websocket upgrade request. This is a regular http GET request, and the actual
parameters for the WS-handshake are carried in the http headers.
- For `inproc`, a.k.a raw ipc communication, no authentication is required, under the assumption that a process able to access `ipc` channels for the process, which usually means local file access, is already sufficiently permissioned that further authentication requirements do not add security.

- If the listening address is `127.0.0.1`, a fixed `JWT` secret must be used, under the assumption that sockets bound to the localhost cannot accept external connections and therefore are not susceptible to manipulation from remote adversaries. The fixed secret serves to protect against malicious webpages that may attempt to make requests against the localhost.

## JWT specifications

Expand All @@ -35,7 +35,13 @@ The HMAC algorithm implies that several consensus layer clients will be able to

The execution layer and consensus layer clients **SHOULD** accept a configuration parameter: `jwt-secret`, which designates a file containing the hex-encoded 256 bit secret key to be used for verifying/generating JWT tokens.

If such a parameter is not given, the client **SHOULD** generate such a token, valid for the duration of the execution, and **SHOULD** store the hex-encoded secret as a `jwt.hex` file on the filesystem. This file can then be used to provision the counterpart client.
If such a parameter is not given and the host is `127.0.0.1` the client **MUST** continue with the default `jwt-secret`:

```
0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3
```

If such a parameter is not given and the host _is not_ `127.0.0.1`, the client **SHOULD** securely generate a random token, valid for the duration of the execution, and store the hex-encoded secret as a `jwt.hex` file on the filesystem. This file can then be used to provision the counterpart client.

If such a parameter _is_ given, but the file cannot be read, or does not contain a hex-encoded key of `256` bits, the client **SHOULD** treat this as an error: either abort the startup, or show error and continue without exposing the authenticated port.

Expand Down