We had various examples in the past where new releases break mitmproxy completely. Just as of today, the lxml guys pushed a new release to pypi, but did not include wheels - you cannot install mitmproxy on Windows without a compiler installed now.
Updated utils.py using 2to3-3.4
Updated hexdump to use .format() with .encode() to support python 3.4
Python 3.5 supports .format() on bytes objects, but 3.4 is the current
default on Ubuntu.
samc$ py.test netlib/test/test_utils.py
= test session starts =
platform darwin -- Python 3.4.1, pytest-2.8.2, py-1.4.30, pluggy-0.3.1
rootdir: /Users/samc/src/python/netlib, inifile:
collected 11 items
netlib/test/test_utils.py ...........
= 11 passed in 0.19 seconds =
Keyboard interrupts bugger up Queues in some way, which causes a traceback on
exit in many of our tools. The issue seems easiest to reproduce with binary
builds on OSX.
This commit fixes netlib's optional (turned off by default)
certificate verification, which previously did not validate the
cert's host name. As it turns out, verifying the connection's host
name on an intercepting proxy is not really straightforward - if
we receive a connection in transparent mode without SNI, we have no
clue which hosts the client intends to connect to. There are two
basic approaches to solve this problem:
1. Exactly mirror the host names presented by the server in the
spoofed certificate presented to the client.
2. Require the client to send the TLS Server Name Indication
extension. While this does not work with older clients,
we can validate the hostname on the proxy.
Approach 1 is problematic in mitmproxy's use case, as we may want
to deliberately divert connections without the client's knowledge.
As a consequence, we opt for approach 2. While mitmproxy does now
require a SNI value to be sent by the client if certificate
verification is turned on, we retain our ability to present
certificates to the client which are accepted with a maximum
likelihood.
