search

sonertari / SSLproxy

Transparent SSL/TLS proxy for decrypting and diverting network traffic to other programs, such as UTM services, for deep SSL inspection
BSD 2-Clause "Simplified" License
385 stars 100 forks source link

Simple example listening program? ICAP support? [feature request] #57

Closed qpwo closed 1 year ago

qpwo commented 1 year ago

Is there sample code for a bare-minimum listening program implementation available anywhere? I was trying to use some code from your tests but had trouble and switched to the patched e2guardian from UTMFW. I would prefer some simple C code if possible.

Please only open issues for bug reports or feature requests.

If there's no such code, I'd be happy to write it and open a PR. I think that would make it a bit easier to pick up and use SSLproxy. I would just need a pointer to get started.

sonertari commented 1 year ago

I think the simplest C code is what you've already found: https://github.com/sonertari/SSLproxy/tree/master/tests/testproxy/lp. Perhaps a Python or Rust program might look simpler.

qpwo commented 1 year ago

Excuse the newbie question, but how does the sslproxy line (in first packet in connection) scheme compare with ICAP? A normal ICAP server wouldn't work out of the box with sslproxy right? (Couldn't find answer in docs)

sonertari commented 1 year ago

Yes, I remember considering ICAP when I first started working on SSLproxy back in 2017. For example, E2Guardian did support ICAP in those years too. It may still be a good idea to add support for ICAP in SSLproxy, acting as an ICAP client, but at that time I decided to implement the current SSLproxy solution. I don't remember the exact reasons, but I think some of them were:

  1. Inserting an SSLproxy line into the first packet was very simple, and sufficient for my purposes (see UTMFW).
  2. It's simple to implement the SSLproxy line, and it's expected to run very fast. Whereas ICAP runs over TCP on a dedicated port 1344 (seems like a bottleneck to me), and its protocol is quite complicated (https://datatracker.ietf.org/doc/html/rfc3507), hence would be harder to implement, and be slower.
  3. The SSLproxy solution simply passes all of the packets to listening programs. Whereas, in ICAP, HTTP bodies are encapsulated by ICAP clients before sending to ICAP servers, so refer to the reason 2 above. Therefore, AFAIK, ICAP clients need buffering (and processing) before sending ICAP messages to ICAP servers (for example, due to encapsulated headers and bodies, and chunking and preview messages seem complicated to me).
  4. SSLproxy is as dumb as possible, whereas an ICAP client should be smart enough and converse with ICAP servers (the OPTIONS method).
  5. The SSLproxy solution is completely transparent and invisible (to the server at least, but the client can detect SSLproxy due to the forged SSL certificates, but that's same with any ICAP support too), but ICAP may insert X-ICAP headers to HTTP requests, hence the origin server can tell that there is an ICAP client in the middle.
  6. ICAP is for HTTP, but SSLproxy supports protocols other than HTTP/S: TCP, SSL, POP3/S, SMTP/S (see again UTMFW). I know someone using SSLproxy with a proprietary and binary protocol too.
  7. Last but not least, the SSLproxy solution over networking sockets provides a natural way of intrusion prevention via an active inline IPS (see Snort IPS on UTMFW). AFAIK, Snort and Suricata do not support ICAP.

I am not an expert on ICAP, so some of the comments I have above may be wrong. But I think above were enough reasons to prefer my simple SSLproxy line (and the associated design/implementation) over ICAP.

qpwo commented 1 year ago

Makes a lot of sense, particularly supporting non-HTTP/S protocols

qpwo commented 1 year ago

Don't think I'll have time to implement this soon unfortunately. Will reopen if I get a chance.