The proxy can now sit between a client and a https web server. It does
this by looking for a CONNECT request that conventional proxies use to
open a tunnel between a client and an https server. Instead of opening
an opaque tunnel, yaip immediately sends bacck a "connection
established" response. This tells the client (browser normally) to
proceed and initiate an HTTPS connection.
I use the host that was send in the connect request to set up a fake SSL
server. If we have seen the domain before, we re-use the certificate,
otherwise we generate a new one and sign it using YAIP's built in
certificate authority.
I still need to do work on forwarding the request upstream. This is my
next job. Currently, yaip responds with a valid response of "it worked".
```
$ curl https://example.com --cacert ~/.config/yaip/cert.pem
It worked
```
Notice, we don't get any certificate errors because we are telling curl
to trust the authority that yaip uses
I now start the listener in the main.c file rather than proxy given that
I didn't feel proxy was the right place if a normal (non-proxied)
request came in. webserver.{c,h} and proxy.{c,h} had some changes
relating to this.
The config changed slightly - we now create a folder in ~/.config/
called yaip. This is where certificates and so on will be stored along
with the user configuration
I created a helper function to get files inside this directory (it
changes based on xdg_config_home) and updated relevant tests.
In ssl.{c,h} I have started work. If they don't exist, the tool now
creates and stores a key and certificate for the CA that this tool will
need to pretend to be. I still need to write tests for this.
making requests to something like example.com over a non-encrypted
connection now works. Binary files are unlikely to work at the moment
although I haven't tried. Also, non-encrypted doesn't work.
I have also changed a little about how tests work. Requests tests now
display much better.
Jonathan Hodgson