Feature request: Allow disabling certificate validation on the sites you visit when an HTTP(S) proxy is set Topic is solved

[jobbautista9]

Instead, make Pale Moon validate only the TLS certificate of the proxy server itself instead of the website in the address bar.

Currently in order for forward proxies to be useful in terms of caching websites in this era of an almost HTTPS-only and everywhere web, the proxy essentially needs to act as an MitM and break HTTPS, as otherwise they won't be able to see the resource you request and therefore serve a cached copy if available (and if not then cache it itself). This means if you don't want to break HTTPS the only thing forward proxies can do is become a relay (via the HTTP CONNECT method). But even in that front they're practically obsolete for general browsing due to low-cost VPNs which are much safer (because they try to proxy everything, not just HTTP or TCP).

If one doesn't care about breaking HTTPS then setting up a forward proxy to splice/bump the TLS is still a pain. You have to create a self-signed CA which you install to your browser and use proxy software like Squid which can dynamically create certificates for each domain, so you don't get stuck in endless TLS errors as you browse with your trusted MitM. It's also a lot more fragile because now you have to make sure your CA doesn't get compromised (or else you get an MitM on your MitM)... If we instead only validate the TLS certificate of our proxy then we only need a valid DV cert installed in our forward proxy. It can be issued by any already trusted CA; even just a free Let's Encrypt cert should do it.

But you may already be asking at this point, why are we breaking HTTPS? Why do you want to break the end-to-end principle of making sure only the other party on that website you're visiting knows your communications? Well.. because they've already been broken anyway. You see even though "HTTPS Everywhere" had pretty much succeeded in making sure almost every part of the web is encrypted, it didn't mean there are no longer third-parties who are privy to your private communications. CDNs/gateways like Cloudflare and Fastly already have to break HTTPS in order to cache the websites they serve but they don't control. Turns out webmasters never really cared about the "end-to-end" or "authentication/validation" part of HTTPS; they only want encryption and nothing more.

So if we are able to turn a blind eye on reverse proxies splicing your HTTPS, or Let's Encrypt not doing proper validation on the DVs they issue (further proof that most webmasters only care about encryption), then I don't see why we can't do the same for forward proxies. Caching forward proxies are obsolete now because we still think HTTPS is being taken seriously by 90% of the web. Well it's not and we should allow forward proxies to properly adapt to this new reality as we did for gateways. Make caches and proxies great again!

Think about it; it would be another unique feature that no other browser out there (AFAIK) offers yet. The IT of organizations' internal networks now have an alternative to installing a CA in each of their computers and could instead deploy a browser that has this option enabled. A power user who's on multiple devices could save some latency and data by setting up a Squid of their own. It's also one arena we can allow ourselves to be faster at than the mainstream browsers who have to rely solely on websites using CDNs. Even the big CDNs like Cloudflare could join in on the fun if they want by offering their own forward proxy; they just have to accept that it is no longer only the origin server which can decide how fast and cached its website wants to be. User choice!

(I am also willing to offer a bounty here if that motivates someone here who is familiar with the source code of the NSS and HTTP proxying to work on this request)

[Moonchild]

If you're happy to break TLS in the same way antivirus proxies do, then just create a certificate for "*" and import/trust that, and install it in the proxy. There's no need to make a change in the browser, as it will effectively see "*" and trust every domain with that. On top, you as a user get to control which proxy you trust by installing the cert; your proposal would just trust everything that presents a "valid" cert (and since let's encrypt and 0ssl have pretty much made DV a joke, your indicated risk of an attack on your proxy chain trust would be very real)...

I really don't see a reason to break fundamental TLS behaviour here. Just because https has been greatly devaluated by low-threshold services to "encrypt everything at all cost", doesn't mean I'll be wanting to toss any semblance of secure connectivity out the window.

[jobbautista9]

That still means I have to generate a certificate with a tool like openssl and install it on both the proxy and browser, which is what I'm trying to avoid... I don't like doing hacks like that.

But you know, I've tried setting up the ssl splice and bump (with dynamic hostname certificate generation) in a Squid proxy. It was a pain to get it all working, but I was able to in the end. Unfortunately the performance is not really good and the proxy was not able to keep up with all of my requests despite being the only user and not doing too much (it's just normal browsing), which isn't what I expected. Perhaps it could be my VPS where I host the proxy. After all it's only 2 GB RAM and has a single virtual CPU. But the latency is very low at around 5-7ms, and looking at htop while using the proxy the resource usage doesn't go anywhere near maxing out, so I don't think it's the available resources of the VPS being the bottleneck.

It could also be Squid itself being the bottleneck, since it can only pipeline up to 2 requests by default. Still not as advanced as Polipo somehow...

But I'm suspecting it's both the browser's proxying and the ssl bumping that are most at fault. Since browsers will always use the CONNECT method when proxying https, it means all requests to the proxy will have an extra RTT in it (because the proxy will need to establish a tunnel and return a response code to the client before the relaying can begin). That means there's going to be a painfully high latency penalty when a website is using a lot of subdomains, since you need a separate CONNECT for each of them. Which also means each domain needs its own TLS handshake too. Combine that with the fact that Squid's ssl bumping means there isn't really a single tunnel connection between the client and the target server, but two tunnel connections (one for the client <--> proxy and one for the proxy <--> server), well, no wonder my UX is just horribly slow...

So please consider this as another justification for disabling certificate validation for every server you visit. If instead we have an option to do practically in the entire session only a single TLS handshake with the proxy (which means instead of using CONNECT and establishing a tunnel, we use regular methods like GET, the same as how it's being done when proxying plain http), I'd imagine it could be just as fast as proxying plain http. I could even switch to using nginx (with out-of-the-box build configuration) for this purpose; I've already tested that you can make nginx a forward proxy (but as expected you can only proxy http and not https because nginx doesn't implement CONNECT), and with it having far better pipelining I'd imagine it could beat Squid too in its own game.

I also think this option would be safer and less hacky than importing a certificate, one because there's lesser chances of screwing up getting a good TLS certificate generated and deployed in both the proxy and clients, and two I think it's certain that a new indicator in the address bar as well as the Page Info window being revamped will need to be done anyway if this option will be implemented, which means an opportunity to make it clear and obvious to the end-user that they have an MitM active. Importing a certificate won't make that obvious (unless you click the padlock). I'd rather have the clear indicator than a false semblance of an "end-to-end secure connectiion".

[Moonchild]

I'm not considering this, sorry. It's something I don't even want to have as an option in the browser or platform because it goes straight against every fibre of my IT security education. Disabling domain verification as a whole is just absolutely wrong and considerably less secure than wildcard certificates (as any cert will be accepted, regardless, without even the guard rail of having to install the wildcard as trusted). Encryption without at least some form of authentication is totally pointless.

Perhaps it could be my VPS where I host the proxy. After all it's only 2 GB RAM and has a single virtual CPU. But the latency is very low at around 5-7ms, and looking at htop while using the proxy the resource usage doesn't go anywhere near maxing out, so I don't think it's the available resources of the VPS being the bottleneck.

I happen to have used squid a good while back and it does require multiple cores to do its work properly, but above all it requires good I/O -- you may be saturating the storage as well as the single CPU thread. I do think your bottleneck is with the VPS somewhere if it's slow. I don't know how this generating of certs is done in squid, exactly, but I would assume it involves some cryptography which is, by design, slow to mitigate timing attacks and brute-forcing.

All that being said though, you may just want to use a different kind of proxy, instead. But if you want caching of http requests at the proxy you MUST have a MitM setup, there just isn't any other way. Cloudflare does this as well through NginX and requires website owners to submit their cert and key to them for the site OR have CF be the CA for generated certs. The only difference there is that they are a CA and can sign any cert they create in a way that is trusted by browsers by default.

If caching isn't a strict requirement then there are plenty other options like tunneling (stunnel), OpenVPN or similar, SOCKS, etc.

[jobbautista9]

I'm not considering this, sorry. It's something I don't even want to have as an option in the browser or platform because it goes straight against every fibre of my IT security education. Disabling domain verification as a whole is just absolutely wrong and considerably less secure than wildcard certificates (as any cert will be accepted, regardless, without even the guard rail of having to install the wildcard as trusted). Encryption without at least some form of authentication is totally pointless.

Understandable. Admittedly I did kinda know before I submitted this feature request that you're probably not going to want this in the browser, or at least not be the one to implement it and have it be very low priority... Well, at least I tried ¯\_(ツ)_/¯

I happen to have used squid a good while back and it does require multiple cores to do its work properly, but above all it requires good I/O -- you may be saturating the storage as well as the single CPU thread. I do think your bottleneck is with the VPS somewhere if it's slow.

I see. I still have 20G of free space in this VPS and I've made sure the disk cache for Squid is not too high, so not sure if storage is an issue. Though I suppose I should try it someday in a localhost setup or another computer in my LAN (where I've multiple cores and way more storage) to see for myself if it's the threading and storage being the primary factor. I still wanted it to be a low-latency personal proxy I can access from anywhere and have as little maintenance as possible though, which is why I went with this very low-spec VPS in Manila. Unfortunately upgrading that VPS to be actually decent in specs and keeping that upgrade is not within my budget... I'm already spending 7 USD per month for this VPS and I don't seem to have any other cheaper choice if I want a Philippine-based VPS

I don't know how this generating of certs is done in squid, exactly, but I would assume it involves some cryptography which is, by design, slow to mitigate timing attacks and brute-forcing.

Squid has a wiki page for the dynamic cert generation you can look into. I just generated my own CA (the cert + private key) and dhparam, then passed that to the proxy. I did switch from 2048-bit RSA to a 256-bit elliptic curve during generation of root CA to try minimize the impact of crypto though. It might however not be enough since I have made the proxy listen on an Yggdrasil IPv6 address (I don't really want to expose this to the clearnet) which has its own cryptography too (and it does add a bit of latency, but only like 1 ms)...

If caching isn't a strict requirement then there are plenty other options like tunneling (stunnel), OpenVPN or similar, SOCKS, etc.

If I wasn't aiming for the caching then I wouldn't post this feature request in the first place. HTTP proxy with end-to-end CONNECT for https is enough for me when I just need a quick way to show a website that I'm from another country. I know it's quite antiquated these days but old habits die hard