[DO NOT MERGE] Use notary-server

[mhchia]

Based on #11 . For this PR to be ready, we'd need some changes in notary-server.

Issues

1. No way to set X-Session-Id

Notary Server expects a header X-Session-Id to get session_id, but browser WebSocket API doesn’t allow setting custom headers. Possible workarounds can be seen here. Promising ones are

1. ⭐ Accept sessionId through the header Sec-WebSocket-Protocol
   • Example
     • Browser: const ws = new WebSocket("wss://127.0.0.1:7047/notarize", ["sessionId", sessionId])
     • Server: parse the header of Sec-WebSocket-Protocol and get sessionId
2. Accept sessionId through url params: const ws = new WebSocket("wss://127.0.0.1:7047/notarize?sessionId={sessionId}”)
   • Cons
     • URLs are possibly recorded in server logs, and so are sessionIds

This PR uses option 2 but now I'm leaning towards option 1 since it seems to have fewer side-effects.

2. Self-signed root cert

In the browser, no way to accept root cert when initiating http request, due to browser restriction. Now we can bypass it by manually setting the notary server as trusted.

What is done?

Talk to the notary-server instead of the simple-notary.

Steps to run

Step 1: Fill in information twitter message information

tlsn-extension/wasm/prover/src/lib.rs

Lines 43 to 52 in 9f40dc2

	const SERVER_DOMAIN: &str = "twitter.com";
	const ROUTE: &str = "i/api/1.1/dm/conversation";
	const CONVERSATION_ID: &str = "";
	const CLIENT_UUID: &str = "";
	const USER_AGENT: &str = "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36";
	const AUTH_TOKEN: &str = "";
	const ACCESS_TOKEN: &str = "";
	const CSRF_TOKEN: &str = "";

Step 2: Open a new terminal. Build and run a websocket proxy

git clone https://github.com/novnc/websockify && cd websockify
./docker/build.sh
docker run -it --rm -p 55688:80 novnc/websockify 80 twitter.com:443

Step 3: Open a new terminal. Run a modified notary server

git clone [email protected]:mhchia/notary-server.git
cd notary-server && git checkout accept-session-id-in-url

RUST_LOG=debug,yamux=info cargo run --release

Step 4: Build the wasm and run the dev server

pnpm install
pnpm run build:wasm
npm run dev

Step 5: Load built extension
Go to chrome://extensions, click Load unpacked, select the build directory

Step 6: Run notarize
Open the TLSN Extension and click Notarize. Check out the console by clicking the offscreen.html in the inspect views section in TLSN Extension

[themighty1]

@mhchia , just a quick thought about 2. Self-signed root cert
A possible solution is instead of connecting via wss, the parties will establish a TLS connection using plain ws as a transport.
Just like our native prover uses TLS over TCP, the browser prover would use TLS over plain WS.

(this approach requires some changes on the notary-server side)

[themighty1]

sry, this is actually a deeper topic. we first need to decide if it useful to allow the extension to use new WebSocket to directly talk to the Notary or if the extension must talk to it only by calling into wasm (in the latter case we would set up TLS over WS inside wasm)

[mhchia]

@themighty1 thanks a lot for your insights! 😊

Sorry that I didn't add context about the self-signed root. From my understanding from the discussion with @yuroitaki (please feel free to correct me if I misunderstood your points 🙏 ), it seems like we'll eventually be using an officially signed cert from a proper CA chain for the notary server in production.

Given that, I'm thinking it might make sense to connect notary server with wss and manually set it as trusted for now. After notary server uses the officially signed CA everything will work correctly without any changes. Would this make sense or did I get anything wrong?

[themighty1]

OK, makes sense about assuming that the notary will be using a proper CA-signed cert for now.

Note however, for p2p (notary-less) scenarios where the prover proves interactively to the verifier, requiring the verifier to have a CA-signed cert seems unnecessarily burdensome.
(but we can proceed as is right now and revisit this later)

[mhchia]

@themighty1 Thanks for the input! Now there is already a public notary server with a properly signed cert so it works well now.

About the p2p scenario, for websocket on browser to work without verifying certs, I think you're right we would need to go with the TLS over a plain ws as you mentioned

[mhchia]

p2p scenario is tracked in #19. Closing this PR since it's stale