iCE40/ghdl - clone of https://github.com/ghdl/ghdl

diff options

author	Tristan Gingold <tgingold@free.fr>	2019-04-27 10:14:26 +0200
committer	Tristan Gingold <tgingold@free.fr>	2019-04-27 10:21:30 +0200
commit	e857941acd16e3a678296b26e34b4bf330d5239c (patch)
tree	b0cd38523d2ee9509088aadcfe0c33bc5ec0b9a4 /src/vhdl/python
parent	c9174bea8a486faf265feae222593d4553572d7d (diff)
download	ghdl-e857941acd16e3a678296b26e34b4bf330d5239c.tar.gz ghdl-e857941acd16e3a678296b26e34b4bf330d5239c.tar.bz2 ghdl-e857941acd16e3a678296b26e34b4bf330d5239c.zip

vhdl: supports VHPIDIRECT in mcode backend.

src: add hash.ad[sb], interning.ad[sb] Automatically link with vhpidirect libraries.

Diffstat (limited to 'src/vhdl/python')

0 files changed, 0 insertions, 0 deletions

--- title: "How mitmproxy works" menu: concepts: weight: 1 --- # How mitmproxy works Mitmproxy is an enormously flexible tool. Knowing exactly how the proxying process works will help you deploy it creatively, and take into account its fundamental assumptions and how to work around them. This document explains mitmproxy's proxy mechanism in detail, starting with the simplest unencrypted explicit proxying, and working up to the most complicated interaction -transparent proxying of TLS-protected traffic[^1] in the presence of [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication). ## Explicit HTTP Configuring the client to use mitmproxy as an explicit proxy is the simplest and most reliable way to intercept traffic. The proxy protocol is codified in the [HTTP RFC](https://tools.ietf.org/html/rfc7230), so the behaviour of both the client and the server is well defined, and usually reliable. In the simplest possible interaction with mitmproxy, a client connects directly to the proxy, and makes a request that looks like this: {{< highlight http >}} GET http://example.com/index.html HTTP/1.1 {{< / highlight >}} This is a proxy GET request - an extended form of the vanilla HTTP GET request that includes a schema and host specification, and it includes all the information mitmproxy needs to proceed. {{< figure src="/schematics/how-mitmproxy-works-explicit.png" title="Explicit" >}} 1. The client connects to the proxy and makes a request. 2. Mitmproxy connects to the upstream server and simply forwards the request on. ## Explicit HTTPS The process for an explicitly proxied HTTPS connection is quite different. The client connects to the proxy and makes a request that looks like this: {{< highlight http >}} CONNECT example.com:443 HTTP/1.1 {{< / highlight >}} A conventional proxy can neither view nor manipulate a TLS-encrypted data stream, so a CONNECT request simply asks the proxy to open a pipe between the client and server. The proxy here is just a facilitator - it blindly forwards data in both directions without knowing anything about the contents. The negotiation of the TLS connection happens over this pipe, and the subsequent flow of requests and responses are completely opaque to the proxy. ### The MITM in mitmproxy This is where mitmproxy's fundamental trick comes into play. The MITM in its name stands for Man-In-The-Middle - a reference to the process we use to intercept and interfere with these theoretically opaque data streams. The basic idea is to pretend to be the server to the client,


context:
space:
mode: