Re: Rewriting CONNECT header

Thank you very much for taking the time to test this.  The user error
on my part turned out to be something else: I think the certificate
generation was failing because `certificate-directory' did not
exist. and this was causing the connection to be dropped.

*  Fabian Keil <[email protected]>
Wrote on Thu, 7 Mar 2024 16:48:06 +0100
> Madhu <[email protected]> wrote on 2024-02-23 at 17:52:48:
[snip]
>> ``` use.filter
>> CLIENT-HEADER-FILTER: use-ip-for-example-com
>> s@^(HEAD|GET|POST) /([^ ]*) (HTTP/.*)$@$1 https://192.168.20.10/$2 $3@i
>> s@^(CONNECT)\s*example.com(.*)$@$1 192.168.20.10@i
>
> This line seems to eat the "HTTP/1.1" resulting in an invalid line.

I had made a typo when posting, my filter file had
s@^(CONNECT)\s*example.com(.*)$@$1 192.168.20.10$2@i
                                                ^^^
and this was reflected in the log [snip]

>>  Re-Filter: filtering 'CONNECT example.com:443 HTTP/1.1' (size) with 'use-ip-for-example' ...
>>  Header: Transforming "CONNECT example.com:443 HTTP/1.1" to "CONNECT 192.168.20.10:443 HTTP/1.1"
>>  Redirect: Rewrite detected: CONNECT 192.168.20.10:443 HTTP/1.1
>>  Connect: Closing client socket 4. Keep-alive: 0. Socket alive: 1. Data available: 1. Configuration file change detected: 0. Requests received: 1.
>> ```
>> and curl gets an EOF reply.

I should have investigated further before posting. I think the EOF was
because the certificate directory didn't exist and https introspection
was failing. (Perhaps the debug variable can be converted to a bignum
and tls/certificate debugging could be alotted debug numbers:))

> For testing I changed your filter to:
>
> CLIENT-HEADER-FILTER: use-ip-for-example-com
> s@^(HEAD|GET|POST) /([^ ]*) (HTTP/.*)$@$1 https://95.211.138.51/$2 $3@i
> s@^(CONNECT)\s*example.com(.*)$@$1 95.211.138.51 HTTP/1.1@i
>
> This seems to "work" but Privoxy generates a certificate for
> 95.211.138.51 instead of example.com to show the client.

[snip]

> If curl is instructed to ignore the problem the content is shown as expected.
>
> It could be argued that Privoxy should generate a certificate
> for example.com instead.

I'm inclined to think the client should accept insecure certificates.
Of couorse it may not be possible to do that with Modern Browsers, but
this may not work with "modern servers". (I've forgotten the details
on SNI and TLS version restriction), but this facility is probably
useful against ISPs that inspect the hostname and reset tcp
connections.  --- Best Regards, Madhu