Chunked OHTTP support (martinthomson#10)

* chunked response * checked responses * fix * streaming * client * FFI for CVM guest attestation library * documentation * updated docker files (#1) Co-authored-by: tienle <[email protected]> * Add user-selected PCRs to CVM guest attestation FFI * support secp384r1 with Sha384 * AesGCM256 support * changing defaults * kms configuration and receipt verification * signature verification * remove spurios fields * whiper docker * various * audio txt example * script for generating HTTP requests * fixes * local config support * whspier support * server bug fix * upgrade server build container * remove debugging * print content * Refactor CGPU attestation as library * Load key from KMS - now imports correct value from JWKS * process audio * fix for large whisper chunks (#3) * fix for large whisper chunks * updated constant --------- Co-authored-by: root <root@tienWhishper1vm8.ryo44skwzyvufbtmgla1rqrm2c.cx.internal.cloudapp.net> * output formatting * kms url * makefile change * Use port 8000 for faster-whisper demo * Add mCCF service cert of KMS to examples/ * Switch to OpenAI API format * default kms * demo script * target path as client parameter * verify quote * Updates for demo v2 including CBOR key release * Tienle/custmaa (#4) * updated custom MAA * updated discover * update for FFI safe * update rust version * update server image * added run server container * updated server logic * updated MAA config --------- Co-authored-by: root <root@tienWhishper1vm8.ryo44skwzyvufbtmgla1rqrm2c.cx.internal.cloudapp.net> * headers and mult-part form for whisper * KMS and MAA URLs * refactoring * interface fixes * refactorings * refactoring * removing public APIs * removing KMS specific logic from OHTTP library * client support for curl like flags * fixes * removed chunking * headers * fix * various fixes * Make file change --------- Co-authored-by: Antoine Delignat-Lavaud <[email protected]> Co-authored-by: Tien Le <[email protected]> Co-authored-by: tienle <[email protected]> Co-authored-by: root <root@tienWhishper1vm8.ryo44skwzyvufbtmgla1rqrm2c.cx.internal.cloudapp.net> modified: README.md modified: examples/request.txt modified: ohttp/Cargo.toml modified: ohttp/src/config.rs modified: ohttp/src/hpke.rs modified: ohttp/src/lib.rs modified: ohttp/src/rh/hpke.rs
microsoft · Oct 29, 2024 · 72edfe8 · 72edfe8
1 parent 21e7091
commit 72edfe8
Show file tree

Hide file tree

Showing 7 changed files with 383 additions and 67 deletions.
diff --git a/README.md b/README.md
@@ -1,9 +1,9 @@
-# Oblivious HTTP
+# Attested Oblivious HTTP
 
 This is a rust implementation of [Oblivious
-HTTP](https://www.rfc-editor.org/rfc/rfc9458.html)
+HTTP](https://www.ietf.org/archive/id/draft-ohai-chunked-ohttp-01.html)
 and the supporting [Binary HTTP
-Messages](https://www.rfc-editor.org/rfc/rfc9292.html).
+Messages](https://www.rfc-editor.org/rfc/rfc9292.html) that supports attestation and chunking. 
 
 The `ohttp` crate uses either [hpke](https://github.com/rozbb/rust-hpke) or
 [NSS](https://firefox-source-docs.mozilla.org/security/nss/index.html) for
@@ -36,8 +36,8 @@ The `ohttp` crate has the following features:
 - `client` enables the client-side processing of oblivious HTTP messages:
   encrypting requests and decrypting responses.  This is enabled by default.
 
-- `server` enables the server-side processing of oblivious HTTP messages:
-  decrypting requests and encrypting responses.  This is enabled by default.
+- `server` enables the server-side processing of chunked oblivious HTTP messages:
+  decrypting requests and encrypting chunked responses.  This is enabled by default.
 
 - `rust-hpke` selects the [hpke](https://github.com/rozbb/rust-hpke) crate for
   HPKE encryption.  This is enabled by default and cannot be enabled at the same
@@ -68,62 +68,25 @@ cargo run --bin bhttp-convert < ./examples/response.txt | \
 ```
 
 Sample client and server implementations can be found in `ohttp-client` and
-`ohttp-server` respectively.  The server acts as both an Oblivious Gateway
-Resource and a Target Resource.  You will need to provide your own relay.
+`ohttp-server` respectively. The server acts as an Oblivious Gateway
+Resource. You will need to provide a Target resource and your own relay.
 Though a direct request to the server will demonstrate that things are working,
 the server sees your IP address.
 
+## Development Environment
 
-## Getting and Building With NSS
+The repo supports development using GitHub Codespaces and devcontainers. 
 
-The build setup is a little tricky, mostly because building NSS is a bit fiddly.
+[![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://github.com/codespaces/new?hide_repo_select=true&ref=main&repo=707634300&skip_quickstart=true&machine=premiumLinux&geo=EuropeWest)
 
-First, you need a machine capable of [building
-NSS](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Building).
-For those on Ubuntu/Debian, the minimal set of prerequisites for an x64 build
-(and the later steps) can be installed using:
+## Build and Test
 
-```sh
-sudo apt-get install \
-  ca-certificates coreutils curl git make mercurial \
-  build-essential clang llvm libclang-dev lld \
-  gyp ninja-build pkg-config zlib1g-dev
-```
-
-You then need to clone this repository, the NSS repository, and the NSPR
-repository.  I generally put them all in the same place.
-
-```sh
-cd $workspace
-git clone https://github.com/martinthomson/ohttp ./ohttp
-git clone https://github.com/nss-dev/nss ./nss
-# or
-# hg clone https://hg.mozilla.org/projects/nss ./nss
-hg clone https://hg.mozilla.org/projects/nspr ./nspr
-```
-
-The build then needs to be told about where to find NSS.  The runtime also needs
-to be told where to find NSS libraries. This helps avoid linking with any NSS
-version you might have installed in the OS, which won't work (yet).
-
-```sh
-export NSS_DIR=$workspace/nss
-export LD_LIBRARY_PATH=$workspace/dist/Debug/lib
+To build docker images for the server and client, and test with a sample target service,
 ```
-
-You might need to tweak this.  On a Mac, use `DYLD_LIBRARY_PATH` instead of
-`LD_LIBRARY_PATH`.  And if you are building with `--release`, the path includes
-"Release" rather than "Debug".
-
-Then you should be able to build and run tests:
-
-```sh
-cd $workspace
-cargo build
-cargo test
+make build
+make run
 ```
 
-
 ## Contributing
 
 Contributions are welcome provided you are respectful of others in your
@@ -136,6 +99,6 @@ There is a pre-commit script that you can link to `.git/hooks/pre-commit` that
 runs `cargo fmt` on all commits.  Just run `./pre-commit install` to have it
 install itself.
 
-## Minnimum Supported Rust Version (MSRV)
+## Minimum Supported Rust Version (MSRV)
 
-`ohttp` and `bhttp` should compile on Rust 1.63.0.
+`ohttp` and `bhttp` should compile on Rust 1.70.0.
diff --git a/examples/request.txt b/examples/request.txt
@@ -1,4 +1,4 @@
-GET /hello.txt HTTP/1.1
+GET /stream HTTP/1.1
 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
 Host: www.example.com
 Accept-Language: en, mi

diff --git a/ohttp/Cargo.toml b/ohttp/Cargo.toml
@@ -26,9 +26,10 @@ aead = {version = "0.4", optional = true, features = ["std"]}
 aes-gcm = {version = "0.9", optional = true}
 byteorder = "1.4"
 chacha20poly1305 = {version = "0.8", optional = true}
+colored = "2.0.4"
 hex = "0.4"
 hkdf = {version = "0.11", optional = true}
-hpke = {version = "0.11.0", optional = true, default-features = false, features = ["std", "x25519"]}
+hpke = {version = "0.12.0", optional = true, default-features = false, features = ["std", "x25519", "p384"]}
 lazy_static = "1.4"
 log = {version = "0.4", default-features = false}
 rand = {version = "0.8", optional = true}
@@ -39,6 +40,10 @@ regex-automata = {version = "~0.3", optional = true}
 regex-syntax = {version = "~0.7", optional = true}
 sha2 = {version = "0.9", optional = true}
 thiserror = "1"
+futures-util = "0.3.30"
+futures = "0.3.30"
+bytes = "1.7.2"
+async-stream = "0.3.5"
 
 [dependencies.hpke-pq]
 package = "hpke_pq"

diff --git a/ohttp/src/config.rs b/ohttp/src/config.rs
@@ -78,6 +78,21 @@ impl KeyConfig {
         })
     }
 
+    /// Construct a configuration from an existing private key
+    /// # Panics
+    /// If the configurations don't include a supported configuration.
+    pub fn import_p384(key_id: u8, kem: Kem, sk: <hpke::kem::DhP384HkdfSha384 as hpke::Kem>::PrivateKey, pk: <hpke::kem::DhP384HkdfSha384 as hpke::Kem>::PublicKey, mut symmetric: Vec<SymmetricSuite>) -> Res<Self> {
+        Self::strip_unsupported(&mut symmetric, kem);
+        assert!(!symmetric.is_empty());
+        Ok(Self {
+            key_id,
+            kem,
+            symmetric,
+            sk: Some(crate::rh::hpke::PrivateKey::P384(sk)),
+            pk: crate::rh::hpke::PublicKey::P384(pk),
+        })
+    }
+
     /// Derive a configuration for the server side from input keying material,
     /// using the `DeriveKeyPair` functionality of the HPKE KEM defined here:
     /// <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-12.html#section-4>

diff --git a/ohttp/src/hpke.rs b/ohttp/src/hpke.rs
@@ -31,6 +31,8 @@ macro_rules! convert_enum {
 
 convert_enum! {
 pub enum Kem {
+    P384Sha384 = 17,
+
     X25519Sha256 = 32,
 
     #[cfg(feature = "pq")]
@@ -42,6 +44,8 @@ impl Kem {
     #[must_use]
     pub fn n_enc(self) -> usize {
         match self {
+            Kem::P384Sha384 => 97,
+
             Kem::X25519Sha256 => 32,
 
             #[cfg(feature = "pq")]
@@ -52,6 +56,8 @@ impl Kem {
     #[must_use]
     pub fn n_pk(self) -> usize {
         match self {
+            Kem::P384Sha384 => 97,
+
             Kem::X25519Sha256 => 32,
 
             #[cfg(feature = "pq")]