omjadas / hudsucker

Intercepting HTTP/S proxy
https://crates.io/crates/hudsucker
Apache License 2.0
206 stars 35 forks source link

accessing local website prompt: certificate(net::ERR_CERT_COMMON_NAME_INVALID). and page display: HTTP ERROR 502 #125

Open Q15438643 opened 3 weeks ago

Q15438643 commented 3 weeks ago

HI: I am running hudsucker/examples/openssl.rs and setting the internet proxy to 127.0.0.1:3000 to test the performance under local Windows 10 https://192.168.1.11:8766 When on the website, the page prompts: Your connection isn't private Attackers might be trying to steal your information from 192.168.1.11 (for example, passwords, messages, or credit cards). Edge's devtool/Security prompt: This page is not secure (broken HTTPS). Certificate - missing,This site is missing a valid, trusted certificate(net::ERR_CERT_COMMON_NAME_INVALID). After clicking the Advanced button on the page and selecting 'Continue to 192.168.1.11 (unsafe)', the page will display: This page isn’t working right now192.168.1.11 can't currently handle this request. HTTP ERROR 502 By the way, I haven't run openssl.rs and haven't set up an internet proxy to access it https://192.168.1.11:8766 Although the page will also prompt 'Your connection is not private...', But after clicking 'Continue to 192.168.1.11 (unsafe)', the website can be accessed normally. I usually have no problem accessing HTTPS websites on the internet after running openssl.rs. Why does accessing local websites report HTTP ERROR 502? How can I solve this problem?

omjadas commented 3 weeks ago

I'm not sure where that file came from or what it is. In regards to your original question, is 192.168.1.11:8766 being served over HTTPS?

Q15438643 commented 3 weeks ago

yes,That's right.

---Original--- From: @.> Date: Tue, Aug 27, 2024 10:35 AM To: @.>; Cc: @.**@.>; Subject: Re: [omjadas/hudsucker] accessing local website prompt:certificate(net::ERR_CERT_COMMON_NAME_INVALID). and page display: HTTP ERROR502 (Issue #125)

I'm not sure where that file came from or what it is. In regards to your original question, is 192.168.1.11:8766 being served over HTTPS?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

omjadas commented 3 weeks ago

In that case you will need to customise the client being used so that it trusts the certificate that 192.168.1.11:8766 uses. Assuming the cert is already trusted by your system you could do something like this:

let https = hyper_rustls::HttpsConnectorBuilder::new()
    .with_native_roots()
    .unwrap()
    .https_or_http()
    .enable_http1()
    .enable_http2()
    .build();

let client = hyper_util::client::legacy::Client::builder(TokioExecutor::new()).build(https);

let proxy = hudsucker::Proxy::builder()
    .with_addr(std::net::SocketAddr::from(([127, 0, 0, 1], 3000)))
    .with_client(client)
    .with_ca(ca)
    .build();
Q15438643 commented 2 weeks ago

I tried your method and it still has the same problem.

Maybe you can help me try this HTTPS website. If you can open and decompress the attachment, after running bid.exe, you can access it https://localhost:7070 bid.zip

omjadas commented 2 weeks ago

I'm not going to run a random exe. You will have to ensure that the cert used by your local site is trusted by your system.

Q15438643 commented 2 weeks ago

You can try this website using Hudsucker proxy: https://101.89.113.4:7070/login?type=individual

omjadas commented 2 weeks ago

When you visit the site without using the proxy, does your browser let you visit the site, or do you get a net::ERR_CERT_AUTHORITY_INVALID error?

Q15438643 commented 2 weeks ago

Is there any way to ignore issues such as net:: ERR_CERT_SUTHORITY-INVALID when using Hudsucker proxy? I must visit this website to complete some testing work.

Q15438643 commented 2 weeks ago

image

omjadas commented 2 weeks ago

As I have previously said, my suggested solution would be to ensure that your system trusts the certificate used by the site and then use a custom hyper client with the native roots. If you really can't do that then with rustls you can specify custom certs using with_root_certificates, or with native_tls you could use danger_accept_invalid_certs.