MITM module and MITM support

[jekh]

This PR adds a new LittleProxy MITM module and integrates it with BrowserMob Proxy.

[ganskef]

Hi @jekh, great work! MITM for BMP and LP. Some thoughts about:

• You've used javax.net.ssl.SSLContext instead of io.netty.handler.ssl.SslContext again (like me). I think, it would be better to use the Netty abstraction, which provides tools, builders, the OpenSSL alternative, a better Netty integration for the future.
• My simple implementation is half refactored after replacing the outdated Bouncy Castle implementation in http://mock-server.com/. Do you think it makes sense, if I port your implementation/structure back to LittleProxy-mitm? Update: It's a replacement. What are the differences/requirements, mentioned briefly?
• Do you think, it's possible to create a MITM module in LittleProxy one of these days? That was the intention of LittleProxy-mitm. Of course usable with BMP and my application.

[jekh]

Thanks, @ganskef! The BMP MITM module is a marriage of your LittleProxy-mitm work + the existing certificate impersonation that has been in BMP for years (which actually came from an ancient version of Selenium) + a some enhancements I made for EC certificates. There are a few key reasons I retained LP compatibility but didn't create a LittleProxy submodule:

• I wanted to require Java 7+, since it is much easier to deal with the JCA/JSSE in Java 7. LP's baseline is Java 6.
• Experiment with a fluent/builder interface that can evolve without breaking other LP clients
• Avoid a strict dependency on LittleProxy, so I could use the core impersonation code in the legacy BMP implementation

Eventually though I would like to see something integrated into LittleProxy core. I kind of like the current approach for now, with multiple MITM implementations that are all compatible with LP and interchangeable. That lets us experiment with the API and different implementations and take the best ideas from all of them.

The main difference to the LittleProxy-mitm module, besides requiring Java 7, is that I tried to abstract functionality into interfaces in order to allow for a lot of customization if needed, but also provide sensible defaults. It's still evolving though. I plan to write up some more details on the architecture as it matures. I documented the MITM code pretty well, but the "big picture" isn't explained anywhere yet.

Thanks for the suggestion about using the Netty SslContext, that seems like a great idea. I'm going to experiment with that and may open a PR on it soon.

[ganskef]

Hi Jason,

I like your ideas especially the separation of concerns. I would like to
have a single point to maintain the certificate handling aspect.

Please Note I evaluate the Netty 5 API to solve my offline and retry
handshake issues at last:

 https://github.com/ganskef/shortcircuit-proxy

Regards Frank

Am 07.01.2016 um 05:17 schrieb Jason Hoetger:

Thanks, @ganskef https://github.com/ganskef! The BMP MITM module is a
marriage of your LittleProxy-mitm work + the existing certificate
impersonation that has been in BMP for years (which actually came from
an ancient version of Selenium) + a some enhancements I made for EC
certificates. There are a few key reasons I retained LP compatibility
but didn't create a LittleProxy submodule:

• I wanted to require Java 7+, since it is much easier to deal with
  the JCA/JSSE in Java 7. LP's baseline is Java 6.
• Experiment with a fluent/builder interface that can evolve without
  breaking other LP clients
• Avoid a strict dependency on LittleProxy, so I could use the core
  impersonation code in the legacy BMP implementation

Eventually though I would like to see something integrated into
LittleProxy core. I kind of like the current approach for now, with
multiple MITM implementations that are all compatible with LP and
interchangeable. That lets us experiment with the API and different
implementations and take the best ideas from all of them.

The main difference to the LittleProxy-mitm module, besides requiring
Java 7, is that I tried to abstract functionality into interfaces in
order to allow for a lot of customization if needed, but also provide
sensible defaults. It's still evolving though. I plan to write up some
more details on the architecture as it matures. I documented the MITM
code pretty well, but the "big picture" isn't explained anywhere yet.

Thanks for the suggestion about using the Netty SslContext, that seems
like a great idea. I'm going to experiment with that and may open a PR
on it soon.

—
Reply to this email directly or view it on GitHub
#347 (comment).