http://qs321.pair.com?node_id=11140048


in reply to Re: Need help with HTTP::Proxy
in thread Need help with HTTP::Proxy

Yep, that fixed it! I just added: 
$proxy->host("111.222.333.444");

[download]
below the $proxy->port(8080) line (where 111.222.333.444 is my IP).
Thanks!

Replies are listed 'Best First'.
Re^3: Need help with HTTP::Proxy
by scorpio17 (Canon) on Dec 30, 2021 at 22:57 UTC
    Opps! I spoke too fast. It's working now for HTTP, but not HTTPS.
    From the command line, curl gives me "(35) SSL Connect Error",
    and from a web browser (google chrome) I get "ERR_SSL_PROTOCOL_ERROR".
    I'm using "curl -k" thinking that would make it ignore certificate checking.
[reply]
      SSL diagnosis gets thorny quickly, and I'm no expert, and this is also OT for this site.

      That said - here are a few quick/easy items to start:

      • Check system Date/Time on both boxes - should be within a few seconds of each other.
      • Check SSL/cert info on your proxy via ssllabs.com.

                      "If you had better tools, you could more effectively demonstrate your total incompetence."

[reply]
      Opps! I spoke too fast. It's working now for HTTP, but not HTTPS.

      There are basically two ways to implement a proxy for HTTPS. Either make the HTTP proxy understand and accept the CONNECT verb, or have the proxy effectively do a man-in-the-middle attack, i.e. pretent to be the proxied server, including generating a fake SSL certificate.

      For CONNECT, see HTTP tunnel. As soon as the proxy has received a CONNECT line, it checks permissions, then establishes a TCP connection to the destination and forwards data in both directions, without any further inspection of the data, without caching, without anything a proxy typically does, except for not exposing the client's IP address to the server. Typically, CONNECT is restricted to connect to the default HTTPS port 443, because otherwise, it would allow bypassing the proxy for all protocols including HTTP.

      For the MITM way, you need to roll out a new SSL root certificate to all clients, which is then used to create fake SSL certificates for all intercepted SSL transfers. Furthermore, the proxy has to check the SSL certificates presented by the real server, because the client won't ever see the real server's SSL certificate. This setup is not trivial, it may cause a lot of security issues, and clients implementing certificate pinning won't work.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom