Martian is a library for building custom HTTP/S proxies

Martian Proxy Build Status

Martian Proxy is a programmable HTTP proxy designed to be used for testing.

Martian is a great tool to use if you want to:

  • Verify that all (or some subset) of requests are secure
  • Mock external services at the network layer
  • Inject headers, modify cookies or perform other mutations of HTTP requests and responses
  • Verify that pingbacks happen when you think they should
  • Unwrap encrypted traffic (requires install of CA certificate in browser)

By taking advantage of Go cross-compilation, Martian can be deployed anywhere that Go can target.

Latest Version

v3.0.0

Requirements

Go 1.11

Go Modules Support

Martian Proxy added support for Go modules since v3.0.0. If you use a Go version that does not support modules, this will break you. The latest version without Go modules support was tagged v2.1.0.

Getting Started

Installation

Martian Proxy can be installed using go install

go get github.com/google/martian/ && \
go install github.com/google/martian/cmd/proxy

Start the Proxy

Assuming you've installed Martian, running the proxy is as simple as

$GOPATH/bin/proxy

If you want to see system logs as Martian is running, pass in the verbosity flag:

$GOPATH/bin/proxy -v=2

By default, Martian will be running on port 8080, and the Martian API will be running on 8181 . The port can be specified via flags:

$GOPATH/bin/proxy -addr=:9999 -api-addr=:9898

Logging

For logging of requests and responses a logging modifier is available or HAR logs are available if the -har flag is used.

HAR Logging

To enable HAR logging in Martian call the binary with the -har flag:

$GOPATH/bin/proxy -har

If the -har flag has been enabled two HAR related endpoints will be available:

GET http://martian.proxy/logs

Will retrieve the HAR log of all requests and responses seen by the proxy since the last reset.

DELETE http://martian.proxy/logs/reset

Will reset the in-memory HAR log. Note that the log will grow unbounded unless it is periodically reset.

Configure

Once Martian is running, you need to configure its behavior. Without configuration, Martian is just proxying without doing anything to the requests or responses. If enabled, logging will take place without additional configuration.

Martian is configured by JSON messages sent over HTTP that take the general form of:

{
  "header.Modifier": {
    "scope": ["response"],
    "name": "Test-Header",
    "value": "true"
  }
}

The above configuration tells Martian to inject a header with the name "Test-Header" and the value "true" on all responses.

Let's break down the parts of this message.

  • [package.Type]: The package.Type of the modifier that you want to use. In this case, it's "header.Modifier", which is the name of the modifier that sets headers (to learn more about the header.Modifier, please refer to the modifier reference).

  • [package.Type].scope: Indicates whether to apply to the modifier to requests, responses or both. This can be an array containing "request", "response", or both.

  • [package.Type].[key]: Modifier specific data. In the case of the header modifier, we need the name and value of the header.

This is a simple configuration, for more complex configurations, modifiers are combined with groups and filters to compose the desired behavior.

To configure Martian, POST the JSON to http://martian.proxy/modifiers. You'll want to use whatever mechanism your language of choice provides you to make HTTP requests, but for demo purposes, curl works (assuming your configuration is in a file called modifier.json).

    curl -x localhost:8080 \
         -X POST \
         -H "Content-Type: application/json" \
         -d @modifier.json \
            "http://martian.proxy/configure"

Intercepting HTTPS Requests and Responses

Martian supports modifying HTTPS requests and responses if configured to do so.

In order for Martian to intercept HTTPS traffic a custom CA certificate must be installed in the browser so that connection warnings are not shown.

The easiest way to install the CA certificate is to start the proxy with the necessary flags to use a custom CA certificate and private key using the -cert and -key flags, or to have the proxy generate one using the -generate-ca-cert flag.

After the proxy has started, visit http://martian.proxy/authority.cer in the browser configured to use the proxy and a prompt will be displayed to install the certificate.

Several flags are available in examples/main.go to help configure MITM functionality:

-key=""
  PEM encoded private key file of the CA certificate provided in -cert; used
  to sign certificates that are generated on-the-fly
-cert=""
  PEM encoded CA certificate file used to generate certificates
-generate-ca-cert=false
  generates a CA certificate and private key to use for man-in-the-middle;
  most users choosing this option will immediately visit
  http://martian.proxy/authority.cer in the browser whose traffic is to be
  intercepted to install the newly generated CA certificate
-organization="Martian Proxy"
  organization name set on the dynamically-generated certificates during
  man-in-the-middle
-validity="1h"
  window of time around the time of request that the dynamically-generated
  certificate is valid for; the duration is set such that the total valid
  timeframe is double the value of validity (1h before & 1h after)

Check Verifiers

Let's assume that you've configured Martian to verify the presence a specific header in responses to a specific URL.

Here's a configuration to verify that all requests to example.com return responses with a 200 OK.

      {
        "url.Filter": {
          "scope": ["request", "response"],
          "host" : "example.com",
          "modifier" : {
            "status.Verifier": {
              "scope" : ["response"],
              "statusCode": 200
            }
          }
        }
      }

Once Martian is running, configured and the requests and resultant responses you wish to verify have taken place, you can verify your expectation that you only got back 200 OK responses.

To check verifications, perform

GET http://martian.proxy/verify

Failed expectations are tracked as errors, and the list of errors are retrieved by making a GET request to host:port/martian/verify, which will return a list of errors:

  {
      "errors" : [
          {
              "message": "response(http://example.com) status code verify failure: got 500, want 200"
          },
          {
              "message": "response(http://example.com/foo) status code verify failure: got 500, want 200"
          }
      ]
  }

Verification errors are held in memory until they are explicitly cleared by

POST http://martian.proxy/verify/reset

Martian as a Library

Martian can also be included into any Go program and used as a library.

Modifiers All The Way Down

Martian's request and response modification system is designed to be general and extensible. The design objective is to provide individual modifier behaviors that can arranged to build out nearly any desired modification.

When working with Martian to compose behaviors, you'll need to be familiar with these different types of interactions:

  • Modifiers: Changes the state of a request or a response
  • Filters: Conditionally allows a contained Modifier to execute
  • Groups: Bundles multiple modifiers to be executed in the order specified in the group
  • Verifiers: Tracks network traffic against expectations

Modifiers, filters and groups all implement RequestModifier, ResponseModifier or RequestResponseModifier (defined in martian.go).

ModifyRequest(req *http.Request) error

ModifyResponse(res *http.Response) error

Throughout the code (and this documentation) you'll see the word "modifier" used as a term that encompasses modifiers, groups and filters. Even though a group does not modify a request or response, we still refer to it as a "modifier".

We refer to anything that implements the modifier interface as a Modifier.

Parser Registration

Each modifier must register its own parser with Martian. The parser is responsible for parsing a JSON message into a Go struct that implements a modifier interface.

Martian holds modifier parsers as a map of strings to functions that is built out at run-time. Each modifier is responsible for registering its parser with a call to parse.Register in init().

Signature of parse.Register:

Register(name string, parseFunc func(b []byte) (interface{}, error))

Register takes in the key as a string in the form package.Type. For instance, cookie_modifier registers itself with the key cookie.Modifier and query_string_filter registers itself as querystring.Filter. This string is the same as the value of name in the JSON configuration message.

In the following configuration message, header.Modifier is how the header modifier is registered in the init() of header_modifier.go.

{
  "header.Modifier": {
    "scope": ["response"],
    "name" : "Test-Header",
    "value" : "true"
  }
}

Example of parser registration from header_modifier.go:

func init() {
  parse.Register("header.Modifier", modifierFromJSON)
}

func modifierFromJSON(b []byte) (interface{}, error) {
  ...
}

Adding Your Own Modifier

If you have a use-case in mind that we have not developed modifiers, filters or verifiers for, you can easily extend Martian to your very specific needs.

There are 2 mandatory parts of a modifier:

  • Implement the modifier interface
  • Register the parser

Any Go struct that implements those interfaces can act as a modifier.

Contact

For questions and comments on how to use Martian, features announcements, or design discussions check out our public Google Group at https://groups.google.com/forum/#!forum/martianproxy-users.

For security related issues please send a detailed report to our private core group at [email protected].

Disclaimer

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

Owner
Google
Google ❤️ Open Source
Google
Comments
  • Retagging of v3.0.0

    Retagging of v3.0.0

    Because I use gocenter.io - I noticed that [email protected] got retagged sometime recently (and the gocenter.io version now has a sumdb mismatch as a result).

    Can a new tag be pushed for v3 to resolve the issue for anyone who might be using gocenter, or who happened to build and now effectively has a poisoned go.sum?

  • har: change PostData.Text to []byte

    har: change PostData.Text to []byte

    Previously, it was string, which doesn't correctly round-trip with encoding/json because that package requires strings to be valid UTF-8.

    The right type is []byte, since post data can be arbitrary bytes.

    Fixes #245.

  • Optionally log request & response bodies?

    Optionally log request & response bodies?

    The body of requests and responses are not logged for performance reasons (chunked encoding).

    https://github.com/google/martian/wiki/Modifier-Reference#logging

    It'd be nice if one could optionally log request & response bodies. I'm looking for an easy way to dump requests/responses as JSON (ideally HAR).

  • http.ReadRequest would ignore Host header

    http.ReadRequest would ignore Host header

    when you request

    $ curl -H "Host: example.com" localhost
    

    the server receives localhost instead of example.com

    root cause: https://golang.org/src/net/http/request.go?s=31358:31409#L942

    func ReadRequest(b *bufio.Reader) (*Request, error) {
    	return readRequest(b, deleteHostHeader)
    }
    

    ReadRequest delete Host header 🤥

    it's a helpful trick for the developer, BTW I know

    $ curl http://www.example.com --resolve www.example.com:80:127.0.0.1
    
  • Allow rendering HAR logs as JSONP via query param

    Allow rendering HAR logs as JSONP via query param

    The popular online HAR viewer tool at http://www.softwareishard.com/har/viewer has the ability of loading (via an ajax request so even local URLs work) any HAR from its URL if this HAR is formatted as

    onInputData(harJson);
    

    If Martian allowed for this format change via, let's say, a query param (?jsonp=1) we could go to http://www.softwareishard.com/har/viewer?inputUrl=http://martian.proxy/logs?jsonp=1 to get instant rendering of the HAR timeline.

  • Other projects use the notation GitHub, but this project was fixed as Github.

    Other projects use the notation GitHub, but this project was fixed as Github.

    Hi. I use Google services frequently.

    I'm a favorite company and I hope to contribute to Google. This time, I will send you PR because I found a point that I can correct about the notation of Github.

    Other projects use the notation GitHub, but this project was fixed asGithub

    thank you.

  • Implement cache and replay

    Implement cache and replay

    This implementation of cache and replay is backed by boltdb. #75

    Features:

    • Optional cache updating
    • Optional cache replaying
    • Optional hermetic mode
    • Basic built-in cache key generator that just hashes the HTTP method and URL
    • Custom cache key support via context value, so any prefix modifier can set the cache key

    Future work:

    • Separate keygen modifier that reads an HTTP request header, e.g. X-Martian-Cache-Key, to use as custom cache key
    • Fancier keygen modifiers that:
      • Sort URL query params?
      • Include other HTTP headers?
      • Include the request body?
  • Adds CORS support to mobileproxy

    Adds CORS support to mobileproxy

    Changes main launcher method to accept whether to allow CORS as an option. In order to preserve backwards compatibility with existing clients, this PR renames the launcher method and has the old launcher methods call through to the new one, since Go doesn't support optional method parameters.

  • configure modifier failed.

    configure modifier failed.

    I am newbie to golang, and found https://github.com/netroby/gohttpproxy.git this httpproxy using martian, so I run it and with description in martian readme.md page, try to set the modifier, but it is not work out, main reason is as below, there is no martian.proxy in host,should I add it in hostname ?or what should I do the make the set of modifiers work.

    martian logs as below.

    --------------------------------------------------------------------------------
    Request to http://martian.proxy/configure
    --------------------------------------------------------------------------------
    POST http://martian.proxy/configure HTTP/1.1
    Host: martian.proxy
    Content-Length: 98
    Accept: */*
    Content-Type: application/json
    User-Agent: curl/7.49.1
    Via: 1.1 martian
    X-Forwarded-For: ::1
    X-Forwarded-Host: martian.proxy
    X-Forwarded-Proto: http
    
    {  "header.Modifier": {    "scope": ["response"],    "name": "Test-Header",    "value": "true"  }}
    --------------------------------------------------------------------------------
    
    2016/10/21 09:03:57 ERROR: martian: failed to round trip: dial tcp: lookup martian.proxy: no such host
    2016/10/21 09:03:57 INFO: 
    --------------------------------------------------------------------------------
    Response from http://martian.proxy/configure
    --------------------------------------------------------------------------------
    HTTP/1.1 502 Bad Gateway
    Content-Length: 0
    Warning: 199 "martian" "dial tcp: lookup martian.proxy: no such host" "Fri, 21 Oct 2016 09:03:57 GMT"
    
  • DO NOT MERGE; Implement http.Handler

    DO NOT MERGE; Implement http.Handler

    This patch is an experiment replacing TCP connection handle loop with http.Server. It actually works, the tests are passing, and you can run Martian as HTTP/2 server this way. It's fully compatible with HTTP/2 CONNECT spec [1]. Below example of sending h2 traffic over h2 proxy

    *   Trying 127.0.0.1:3128...
    * Connected to (nil) (127.0.0.1) port 3128 (#0)
    * ALPN: offers http/1.1
    * TLSv1.0 (OUT), TLS header, Certificate Status (22):
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS header, Finished (20):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, CERT verify (15):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Finished (20):
    * TLSv1.2 (OUT), TLS header, Finished (20):
    * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.3 (OUT), TLS handshake, Finished (20):
    * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
    * ALPN: server accepted http/1.1
    * Proxy certificate:
    *  subject: O=Sauce Labs Inc.
    *  start date: Nov 17 13:23:26 2022 GMT
    *  expire date: Nov 17 13:23:26 2023 GMT
    *  issuer: O=Sauce Labs Inc.
    *  SSL certificate verify result: self-signed certificate (18), continuing anyway.
    * allocate connect buffer
    * Establish HTTP proxy tunnel to httpbin:443
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    > CONNECT httpbin:443 HTTP/1.1
    > Host: httpbin:443
    > User-Agent: curl/7.85.0
    > Proxy-Connection: Keep-Alive
    >
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    < HTTP/1.1 200 OK
    < Connection: close
    <
    * Proxy replied 200 to CONNECT request
    * CONNECT phase completed
    * ALPN: offers h2
    * ALPN: offers http/1.1
    * TLSv1.0 (OUT), TLS header, Certificate Status (22):
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS header, Finished (20):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, CERT verify (15):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Finished (20):
    * TLSv1.2 (OUT), TLS header, Finished (20):
    * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.3 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
    * ALPN: server accepted h2
    * Server certificate:
    *  subject: O=Sauce Labs Inc.
    *  start date: Nov 17 13:23:26 2022 GMT
    *  expire date: Nov 17 13:23:26 2023 GMT
    *  issuer: O=Sauce Labs Inc.
    *  SSL certificate verify result: self-signed certificate (18), continuing anyway.
    * Using HTTP2, server supports multiplexing
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * h2h3 [:method: GET]
    * h2h3 [:path: /status/200]
    * h2h3 [:scheme: https]
    * h2h3 [:authority: httpbin]
    * h2h3 [user-agent: curl/7.85.0]
    * h2h3 [accept: */*]
    * Using Stream ID: 1 (easy handle 0xaaaaeaeb27c0)
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    > GET /status/200 HTTP/2
    > Host: httpbin
    > user-agent: curl/7.85.0
    > accept: */*
    >
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    < HTTP/2 200
    < content-length: 0
    < date: Thu, 17 Nov 2022 13:24:01 GMT
    <
    * Connection #0 to host (nil) left intact
    

    [1] https://datatracker.ietf.org/doc/html/rfc7540#section-8.3

  • Support customer logger

    Support customer logger

    When martian is used as package, it needs to work along with the host's logging infrastructure. This change adds support for custom logging.

    By default, it retains current logging, provides an option to change the logger if needed.

  • go.mod cleanup

    go.mod cleanup

    Out-of-sync go.mod with a reference to unused old version of protoc-gen-go-grpc causes a false positive finding in OWASP dependency-check.

    Running go mod tidy fixes the issue. Also fixes #327.

  • Fix CONNECT with downstream proxy

    Fix CONNECT with downstream proxy

    There was very weird logic to work with downstream proxy in case of CONNECT. Which (as far as I see) should be as easy as establish new connection using proxy ~_~

  • Generate RFC 5280 conformant serial numbers

    Generate RFC 5280 conformant serial numbers

    Generating RFC 5280 conformant serial numbers is slightly treacherous. Section 4.1.2.2 dictates that conforming implementations "MUST NOT use serialNumber values longer than 20 octets". A seemingly obvious way to pick serials that conform to this requirement is choosing a random int between [0, 1 << 20*8), which is what the mitm package previously did. The pitfall here is that the DER encoding of integers uses the MSB to indicate the sign, so if encoding/asn1 is passed a positive big.Int for which the encoding has the MSB set it will prefix the encoding with a 0x00 byte. The result of this is that if a serial number is picked that is exactly 20 bytes, and has its MSB set, it will be encoded as 21 bytes.

    The simple solution is to just re-generate the serial if you happen to pick one which is exactly 20 bytes with the MSB set. Since there are a number of users of mitm.MaxSerialNumber (both within this project, and externally), a helper function is added that can be used as a drop-in replacement for the existing crypto/rand.Int calls.

    This came up because we attempted to add a restriction to Go's crypto/x509.CreateCertificate which limited encoded serial numbers to 20 octets, which broke a number of tests inside of Google, a handful of which relied on this project. Googlers can see b/229601555 for some further context here.

  • HTTP/2 issues with curl - peer does not support HTTP/2 properly

    HTTP/2 issues with curl - peer does not support HTTP/2 properly

    Hello, I'm currently attempting to build an HTTP2 logging proxy using Martian. The test snippet below works fine with Firefox; however, when posting data with curl via the proxy, I encounter errors. The following figures shows the results when going via the HTTP2 proxy (code provided).

    GET works fine:

    $ curl -v -x 127.0.0.1:8080 -k https://example.com
    * Expire in 0 ms for 6 (transfer 0x55f31d912fb0)
    *   Trying 127.0.0.1...
    * TCP_NODELAY set
    * Expire in 200 ms for 4 (transfer 0x55f31d912fb0)
    * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
    * allocate connect buffer!
    * Establish HTTP proxy tunnel to example.com:443
    > CONNECT example.com:443 HTTP/1.1
    ...snip...
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x55f31d912fb0)
    > GET / HTTP/2
    > Host: example.com
    > User-Agent: curl/7.64.0
    > Accept: */*
    > 
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
    < HTTP/2 200 
    < age: 303681
    < cache-control: max-age=604800
    < content-type: text/html; charset=UTF-8
    < date: Tue, 01 Mar 2022 05:56:07 GMT
    < etag: "3147526947+ident"
    < expires: Tue, 08 Mar 2022 05:56:07 GMT
    < last-modified: Thu, 17 Oct 2019 07:18:26 GMT
    < server: ECS (sab/572B)
    < vary: Accept-Encoding
    < x-cache: HIT
    < content-length: 1256
    < 
    <!doctype html>
    <html>
    <head>
        <title>Example Domain</title>
    ...snip...
    

    With the following log:

    ##Headers##
    :method: GET
    :path: /
    :scheme: https
    :authority: example.com
    user-agent: curl/7.64.0
    accept: */*
    ##Headers##
    :status: 200
    age: 303681
    cache-control: max-age=604800
    content-type: text/html; charset=UTF-8
    date: Tue, 01 Mar 2022 05:56:07 GMT
    etag: "3147526947+ident"
    expires: Tue, 08 Mar 2022 05:56:07 GMT
    last-modified: Thu, 17 Oct 2019 07:18:26 GMT
    server: ECS (sab/572B)
    vary: Accept-Encoding
    x-cache: HIT
    content-length: 1256
    ##Message##
    <!doctype html>
    <html>
    <head>
    ...snip...
    

    However, POST requests fail:

    $ curl -v -x 127.0.0.1:8080 -k https://example.com -d 'foo=bar'
    * Expire in 0 ms for 6 (transfer 0x55995f82efb0)
    *   Trying 127.0.0.1...
    * TCP_NODELAY set
    * Expire in 200 ms for 4 (transfer 0x55995f82efb0)
    * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
    * allocate connect buffer!
    * Establish HTTP proxy tunnel to example.com:443
    > CONNECT example.com:443 HTTP/1.1
    ...snip...
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x55995f82efb0)
    > POST / HTTP/2
    > Host: example.com
    > User-Agent: curl/7.64.0
    > Accept: */*
    > Content-Length: 7
    > Content-Type: application/x-www-form-urlencoded
    > 
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * We are completely uploaded and fine
    * http2 error: Remote peer returned unexpected data while we expected SETTINGS frame.  Perhaps, peer does not support HTTP/2 properly.
    * Connection #0 to host 127.0.0.1 left intact
    curl: (16) Error in the HTTP2 framing layer
    

    Can you please advise? Is this an issue with my implementation or an underlying problem with Martian? The same results occur regardless of whether i use my logging processor or set the processors to nil.

    Proxy code to replicate the issue below:

    package main
    
    import (
    	"crypto/tls"
    	"fmt"
    	"log"
    	"net"
    	"net/http"
    	"net/url"
    	"time"
    
    	"github.com/google/martian/v3"
    	"github.com/google/martian/v3/h2"
    	"github.com/google/martian/v3/mitm"
    
    	"golang.org/x/net/http2"
    	"golang.org/x/net/http2/hpack"
    )
    
    type loggingProcessor struct {
    	sink h2.Processor
    }
    
    func (p *loggingProcessor) Header(
    	headers []hpack.HeaderField,
    	streamEnded bool,
    	priority http2.PriorityParam,
    ) error {
    	println("##Headers##")
    	for _, header := range headers {
    		println(header.Name + ": " + header.Value)
    	}
    
    	return p.sink.Header(headers, streamEnded, priority)
    }
    
    func (p *loggingProcessor) Data(data []byte, streamEnded bool) error {
    	println("##Message##")
    	println(string(data))
    	return p.sink.Data(data, streamEnded)
    }
    
    func (p *loggingProcessor) Priority(priority http2.PriorityParam) error {
    	return p.sink.Priority(priority)
    }
    
    func (p *loggingProcessor) RSTStream(errCode http2.ErrCode) error {
    	return p.sink.RSTStream(errCode)
    }
    
    func (p *loggingProcessor) PushPromise(promiseID uint32, headers []hpack.HeaderField) error {
    	return p.sink.PushPromise(promiseID, headers)
    }
    
    func main() {
    	fmt.Println("Http2 Proxy Test")
    
    	p := martian.NewProxy()
    	x509c, priv, _ := mitm.NewAuthority("martian.proxy", "Martian Authority", 30*24*time.Hour)
    	mc, err := mitm.NewConfig(x509c, priv)
    	if err != nil {
    		fmt.Printf("creating mitm config: %v", err)
    		return
    	}
    	mc.SetValidity(time.Hour)
    	mc.SetOrganization("Martian Proxy")
    	mc.SetH2Config(&h2.Config{
    		AllowedHostsFilter: func(_ string) bool { return true },
    		StreamProcessorFactories: []h2.StreamProcessorFactory{
    			func(url *url.URL, sinks *h2.Processors) (h2.Processor, h2.Processor) {
    				procCtoS := &loggingProcessor{
    					sink: sinks.ForDirection(h2.ClientToServer),
    				}
    				procStoC := &loggingProcessor{
    					sink: sinks.ForDirection(h2.ServerToClient),
    				}
    				return procCtoS, procStoC
    				//return nil, nil
    			},
    		},
    		EnableDebugLogs: true,
    	})
    
    	p.SetMITM(mc)
    
    	tr := &http.Transport{
    		TLSClientConfig: &tls.Config{
    			InsecureSkipVerify: true,
    		},
    	}
    	p.SetRoundTripper(tr)
    
    	l, err := net.Listen("tcp", "0.0.0.0:8080")
    	if err != nil {
    		log.Fatal(err)
    	}
    
    	if err != nil {
    		fmt.Printf("creating proxy: %v", err)
    		return
    	}
    
    	done := make(chan bool)
    	go func(done chan bool) {
    		p.Serve(l)
    		<-done
    	}(done)
    
    	fmt.Printf("serving on 0.0.0.0:8080\n")
    	<-done
    }
    
(Experimental) Go library for multi-platform clipboard.

clipboard This is a multi-platform clipboard library in Go. Abstract This is clipboard library in Go, which runs on multiple platforms. External clipb

Nov 20, 2022
Aegis is a library that allows you detect if your software is being debugged or not on Linux, FreeBSD, NetBSD, OpenBSD and Windows
Aegis is a library that allows you detect if your software is being debugged or not on Linux, FreeBSD, NetBSD, OpenBSD and Windows

Aegis is a library that allows you detect if your software is being debugged or not on Linux, FreeBSD, NetBSD, OpenBSD and Windows. You can use it natively from C or use the Go bind.

Aug 29, 2022
gproxy is a tiny service/library for creating lets-encrypt/acme secured gRPC and http reverse proxies
gproxy is a tiny service/library for creating lets-encrypt/acme secured gRPC and http reverse proxies

gproxy is a reverse proxy service AND library for creating flexible, expression-based, lets-encrypt/acme secured gRPC/http reverse proxies GProxy as a

Sep 11, 2022
:exclamation:Basic Assertion Library used along side native go testing, with building blocks for custom assertions

Package assert Package assert is a Basic Assertion library used along side native go testing Installation Use go get. go get github.com/go-playground/

Jan 6, 2023
HTTP proxy written in Go. COW can automatically identify blocked sites and use parent proxies to access.

COW (Climb Over the Wall) proxy COW 是一个简化穿墙的 HTTP 代理服务器。它能自动检测被墙网站,仅对这些网站使用二级代理。 English README. 当前版本:0.9.8 CHANGELOG 欢迎在 develop branch 进行开发并发送 pull

Jan 9, 2023
A simple Go HTTP server that proxies RPC provider requests

go-rpc-provider-proxy A simple Go HTTP server that proxies RPC provider requests.

Nov 21, 2021
Echo-server - An HTTP echo server designed for testing applications and proxies

echo-server An HTTP echo server designed for testing applications and proxies. R

Dec 20, 2022
Mar 21, 2022
An experiment building a custom binary protocol for a calculator

Overview Implementation of a calculator service built on a custom protocol on top of TCP Details The server is in main.go, and the client is in client

Nov 28, 2021
Custom generic HTTP handler providing automatic JSON decoding/encoding of HTTP request/response to your concrete types

gap Custom generic HTTP handler providing automatic JSON decoding/encoding of HTTP request/response to your concrete types. gap.Wrap allows to use the

Aug 28, 2022
Lightweight Router for Golang using net/http standard library with custom route parsing, handler and context.

Go-Lightweight-Router Lightweight Router for Golang using net/http standard library with custom route parsing, handler and context. Further developmen

Nov 3, 2021
WebAssembly for Proxies (Golang host implementation)

WebAssembly for Proxies (GoLang host implementation) The GoLang implementation for proxy-wasm, enabling developer to run proxy-wasm extensions in Go.

Dec 29, 2022
Standalone client for proxies of Opera VPN

opera-proxy Standalone Opera VPN client. Younger brother of hola-proxy. Just run it and it'll start a plain HTTP proxy server forwarding traffic throu

Jan 9, 2023
Standalone client for proxies of Windscribe browser extension

windscribe-proxy Standalone Windscribe proxy client. Younger brother of opera-proxy. Just run it and it'll start a plain HTTP proxy server forwarding

Dec 29, 2022
proxyd proxies data between TCP, TLS, and unix sockets

proxyd proxyd proxies data between TCP, TLS, and unix sockets TLS termination: Connecting to a remote application's unix socket: +---------+

Nov 9, 2022
A server that proxies requests and uses fhttp & my fork of CycleTLS to modify your clienthello and prevent your requests from being fingerprinted.

TLS-Fingerprint-API A server that proxies requests and uses my fork of CycleTLS & fhttp (fork of net/http) to prevent your requests from being fingerp

Jan 7, 2023
A wrapper for cloudflared that manages your local proxies for you

Cloudflared Tunnel Wrapper cfdtunnel is a wrapper for cloudflared access tunnel, designed to access multiple tunnels without having to worry about you

Dec 16, 2022
A pair of local reverse proxies (one in Windows, one in Linux) for Tailscale on WSL2

tailscale-wsl2 TL;DR Running two reverse proxies (one in Windows, one in the WSL2 Linux VM), the Windows Tailscale daemon can be accessed via WSL2: $

Dec 9, 2022
Crimson prober - Asynchronous TCP scanner through SOCKS5 proxies
Crimson prober - Asynchronous TCP scanner through SOCKS5 proxies

Crimson Prober v1 Alpha version of Asynchronous TCP scanner through SOCKS5 proxi

Feb 19, 2022