#privacy #relay #oblivious #http-request #requests #ip #ohttp

bin+lib ohttp-relay

Relay Oblivious HTTP requests to protect IP metadata

8 releases

0.0.8 Mar 27, 2024
0.0.7 Mar 19, 2024
0.0.2 Feb 20, 2024

#4 in #oblivious

Download history 32/week @ 2024-07-19 137/week @ 2024-07-26 54/week @ 2024-08-02 136/week @ 2024-08-09 90/week @ 2024-08-16 12/week @ 2024-08-23 14/week @ 2024-08-30 59/week @ 2024-09-06 10/week @ 2024-09-13 35/week @ 2024-09-20 31/week @ 2024-09-27 61/week @ 2024-10-04 113/week @ 2024-10-11 193/week @ 2024-10-18 47/week @ 2024-10-25 63/week @ 2024-11-01

420 downloads per month
Used in 2 crates

MITNFA license

29KB
558 lines

OHTTP Relay

A rust implementation of an Oblivious HTTP relay resource.

This work is undergoing active revision in the IETF and so are these implementations. Use at your own risk.

Usage

Run ohttp-relay by setting PORT and GATEWAY_ORIGIN environment vaiables. For example, to relay from port 3000 to an OHTTP Gateway Resource at https://payjo.in, run the following.

PORT=3000 GATEWAY_ORIGIN='https://payjo.in' cargo run

Alternatively, set UNIX_SOCKET to bind to a unix socket path instead of a TCP port.

This crate is intended to be run behind a reverse proxy like NGINX that can handle TLS for you. Tests specifically cover this integration using nginx.conf.template.

Bootstrap Feature

The Oblivious HTTP specification requires clients obtain a Key Configuration from the OHTTP Gateway but leaves a mechanism for doing so explicitly unspecified. This feature hosts HTTPS-in-WebSocket and HTTPS-in-CONNECT proxies to allow web clients to GET a gateway's ohttp-keys via Direct Discovery in an end-to-end-encrypted, authenticated manner using the OHTTP relay as a tunnel so as not to reveal their IP address. The bootstrap feature to host these proxies is enabled by default. The ws-bootstrap and connect-bootstrap features enable each proxy individually.

How does it work?

Both bootstrap features enable the server to forward packets directly to and from the OHTTP Gateway's TCP socket to negotiate a TLS session between the client and gateway. By doing so, the OHTTP Relay is prevented from conducting a man-in-the-middle attack to compromise the TLS session.

Dependencies

~12–23MB
~323K SLoC