This repository has been archived by the owner on Dec 20, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #17 from tlsnotary/migration-notice
Migration notice
- Loading branch information
Showing
1 changed file
with
2 additions
and
108 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,109 +1,3 @@ | ||
[![CI](https://github.com/tlsnotary/notary-server/actions/workflows/ci.yml/badge.svg)](https://github.com/tlsnotary/notary-server/actions) | ||
## ⚠️ IMPORTANT NOTICE ⚠️ | ||
|
||
|
||
# notary-server | ||
|
||
An implementation of the notary server in Rust. | ||
|
||
## ⚠️ Notice | ||
|
||
This project is currently under active development and should not be used in production. Expect bugs and regular major breaking changes. | ||
|
||
--- | ||
## Running the server | ||
### Using Cargo | ||
1. Configure the server setting in this config [file](./config/config.yaml) — refer [here](./src/config.rs) for more information on the definition of the setting parameters. | ||
2. Start the server by running the following in a terminal at the root of this repository. | ||
```bash | ||
cargo run --release | ||
``` | ||
3. To use a config file from a different location, run the following command to override the default config file location. | ||
```bash | ||
cargo run --release -- --config-file <path-of-new-config-file> | ||
``` | ||
|
||
### Using Docker | ||
There are two ways to obtain the notary server's Docker image: | ||
- [GitHub](#obtaining-the-image-via-github) | ||
- [Building from source](#building-from-source) | ||
|
||
#### GitHub | ||
1. Obtain the latest image with: | ||
```bash | ||
docker pull ghcr.io/tlsnotary/notary-server:latest | ||
``` | ||
2. Run the docker container with: | ||
```bash | ||
docker run --init -p 127.0.0.1:7047:7047 ghcr.io/tlsnotary/notary-server:latest | ||
``` | ||
3. If you want to change the default configuration, create a `config` folder locally, that contains a `config.yaml`, whose content follows the format of the default config file [here](./config/config.yaml). | ||
4. Instead of step 2, run the docker container with the following (remember to change the port mapping if you have changed that in the config): | ||
```bash | ||
docker run --init -p 127.0.0.1:7047:7047 -v <your config folder path>:/root/.notary-server/config ghcr.io/tlsnotary/notary-server:latest | ||
``` | ||
|
||
#### Building from source | ||
1. Configure the server setting in this config [file](./config/config.yaml). | ||
2. Build the docker image by running the following in a terminal at the root of this repository. | ||
```bash | ||
docker build . -t notary-server:local | ||
``` | ||
3. Run the docker container and specify the port specified in the config file, e.g. for the default port 7047 | ||
```bash | ||
docker run --init -p 127.0.0.1:7047:7047 notary-server:local | ||
``` | ||
|
||
### Using different key/cert for TLS or/and notarization with Docker | ||
1. Instead of changing the key/cert file path(s) in the config file, create a folder containing your key/cert by following the folder structure [here](./fixture/). | ||
2. When launching the docker container, mount your folder onto the docker container at the relevant path prefixed by `/root/.notary-server`. | ||
- Example 1: Using different key/cert for both TLS and notarization: | ||
```bash | ||
docker run --init -p 127.0.0.1:7047:7047 -v <your folder path>:/root/.notary-server/fixture notary-server:local | ||
``` | ||
- Example 2: Using different key for notarization (your folder should only contain `notary.key`): | ||
```bash | ||
docker run --init -p 127.0.0.1:7047:7047 -v <your folder path>:/root/.notary-server/fixture/notary notary-server:local | ||
``` | ||
--- | ||
## API | ||
All APIs are TLS-protected, hence please use `https://` or `wss://`. | ||
### HTTP APIs | ||
Defined in the [OpenAPI specification](./openapi.yaml). | ||
|
||
### WebSocket APIs | ||
#### /notarize | ||
##### Description | ||
To perform notarization using the session id (unique id returned upon calling the `/session` endpoint successfully) submitted as a custom header. | ||
|
||
##### Query Parameter | ||
`sessionId` | ||
|
||
##### Query Parameter Type | ||
String | ||
|
||
--- | ||
## Architecture | ||
### Objective | ||
The main objective of a notary server is to perform notarization together with a prover. In this case, the prover can either be | ||
1. TCP client — which has access and control over the transport layer, i.e. TCP | ||
2. WebSocket client — which has no access over TCP and instead uses WebSocket for notarization | ||
|
||
### Design Choices | ||
#### Web Framework | ||
Axum is chosen as the framework to serve HTTP and WebSocket requests from the prover clients due to its rich and well supported features, e.g. native integration with Tokio/Hyper/Tower, customizable middleware, ability to support lower level integration of TLS ([example](https://github.com/tokio-rs/axum/blob/main/examples/low-level-rustls/src/main.rs)). To simplify the notary server setup, a single Axum router is used to support both HTTP and WebSocket connections, i.e. all requests can be made to the same port of the notary server. | ||
|
||
#### WebSocket | ||
Axum's internal implementation of WebSocket uses [tokio_tungstenite](https://docs.rs/tokio-tungstenite/latest/tokio_tungstenite/), which provides a WebSocket struct that doesn't implement [AsyncRead](https://docs.rs/futures/latest/futures/io/trait.AsyncRead.html) and [AsyncWrite](https://docs.rs/futures/latest/futures/io/trait.AsyncWrite.html). Both these traits are required by TLSN core libraries for prover and notary. To overcome this, a [slight modification](./src/service/axum_websocket.rs) of Axum's implementation of WebSocket is used, where [async_tungstenite](https://docs.rs/async-tungstenite/latest/async_tungstenite/) is used instead so that [ws_stream_tungstenite](https://docs.rs/ws_stream_tungstenite/latest/ws_stream_tungstenite/index.html) can be used to wrap on top of the WebSocket struct to get AsyncRead and AsyncWrite implemented. | ||
|
||
#### Notarization Configuration | ||
To perform notarization, some parameters need to be configured by the prover and notary server (more details in the [OpenAPI specification](./openapi.yaml)), i.e. | ||
- maximum transcript size | ||
- unique session id | ||
|
||
To streamline this process, a single HTTP endpoint (`/session`) is used by both TCP and WebSocket clients. | ||
|
||
#### Notarization | ||
After calling the configuration endpoint above, prover can proceed to start notarization. For TCP client, that means calling the `/notarize` endpoint using HTTP (`https`), while WebSocket client should call the same endpoint but using WebSocket (`wss`). Example implementations of these clients can be found in the [integration test](./tests/integration_test.rs). | ||
|
||
#### Signatures | ||
Currently, both the private key (and cert) used to establish TLS connection with prover, and the private key used by notary server to sign the notarized transcript, are hardcoded PEM keys stored in this repository. Though the paths of these keys can be changed in the config to use different keys instead. | ||
This project has been **MERGED** into the [tlsn repository](https://github.com/tlsnotary/tlsn/tree/8783a62ea104ee7f5f1591f1dc51d1785128d8b8/notary-server). |