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.

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

Add HTTPS proxy support #719

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

DanGould
Copy link
Contributor

@DanGould DanGould commented Feb 4, 2024

HTTPS tends to be the default these days, and I would like to proxy via some server that are HTTPS only using ureq.

I ran into a small issue where we're calling Response::do_from_stream which takes ownership of the tls_stream that we ultimately need to return, and there's no easy way to clone a Box<dyn ReadWrite> returned from tls_conf.connect(..), but it seems surmountable. The old PR didn't have this problem because I the Stream abstraction wasn't being used in connect_host. Any suggestion to address this problem?

This reopens #544

The addition of HTTPS proxy support requires a change of the
`connect_host` interface. The return type is changed, but since this is
only used internally in this one file and has visibility pub(crate) this
should not be a breaking change.
@DanGould
Copy link
Contributor Author

DanGould commented Feb 4, 2024

force pushed to fix clippy lints

DanGould added a commit to payjoin/rust-payjoin that referenced this pull request Mar 17, 2024
Previously we were supplying the OHTTP Gateway's Key Configuration
`OhttpKeys` manually with configuration.

Now that the Rust ohttp-relay supports fetching it via https-in-https
CONNECT tunnel, we can fetch it from the server while revealing our IP
address only to an ohttp relay.

While ureq and reqwest advertise https-in-https CONNECT functionality,
in practice neither properly tunnels TLS in TLS, though I'm [trying to
change this](algesten/ureq#719). For this reason
this version uses https-in-http CONNECT which still gets an
authenticated response from the gateway (payjoin directory)

Now we only e2e test v1 payjoin cli, and this is complex behavior we
probably want to test for which means standing up an ohttp-relay,
payjoin directory, and provisioning https certs for them in testing.

## Regarding Configuration

This PR makes it possible to provide an optional default ohttp-keys
config to override fetching one.

In the future, ohttp-keys may be cached per-directory and only refreshed
when they fail.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant