Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Need help with HTTP::Proxy

by NetWallah (Canon)
on Dec 30, 2021 at 22:29 UTC ( [id://11140047]=note: print w/replies, xml ) Need Help??


in reply to Need help with HTTP::Proxy

the new() method in HTTP::Proxy has the following defaults:
my %defaults = ( agent => undef, chunk => 4096, daemon => undef, host => 'localhost', logfh => *STDERR, ...
By default, it will only listen on 'localhost' AKA 127.0.0.1.

If you specify

host=> your-fqdn-or-ip,
in your call to new(), it should work the way you expect (untested).

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

Replies are listed 'Best First'.
Re^2: Need help with HTTP::Proxy
by scorpio17 (Canon) on Dec 30, 2021 at 22:38 UTC
    Yep, that fixed it! I just added:
    $proxy->host("111.222.333.444");
    below the $proxy->port(8080) line (where 111.222.333.444 is my IP).
    Thanks!
      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.
        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."

        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". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11140047]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2024-03-19 05:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found