Jump to content

Web Browser + Proxomitron Reborn + PtronGUI --- A How-To Guide

Recommended Posts

9 hours ago, NotHereToPlayGames said:

(or what I like to call "The Matrix" because I changed my font color to green-on-black).   

JFYI, you need to also change the font to a suitable one to be allowed to call that "The Matrix" credibly.

Namely you want to use the White Rabbit font:



Link to comment
Share on other sites

Okay, I think I'm there. This post confirms what you have already said and it has a pretty comprehensive explanation of what happens.


"You will notice in all of the situations above, that the browser connects to Proxomitron using the same 8080 port as before. The only difference is in the data that flows through that port."

"Then what is HTTPS port for? It is so Proxomitron itself can act as HTTPS web server. You do not need it for just filtering HTTPS sites, but it can be useful if you want to host local resources that you want to embed, to avoid mixed-content warnings/errors from browsers."

"The summary is, set your ports in browser configuration to 8080 like before..."

This is also interesting:


"Get the cacert.pem from https://curl.haxx.se/docs/caextract.html, rename it to certs.pem, and put it in the same directory as proxo.exe"

I think this adds a layer of security when it comes to Proxomitron allowing sites using 'bad' certificates by first checking a list of trusted certificate authorities. I've done that without getting any errors.





Link to comment
Share on other sites

Here I'll highlight another usage for Proxomitron.
Here's an example web site to demonstrate  --  https://off-guardian.org/2021/09/22/30-facts-you-need-to-know-your-covid-cribsheet/
When you open that page, there are FIFTY ONE same-domain images and SEVENTY FIVE third-party images as pointed out by uMatrix -



My internet speed is pretty fast, but that's still a ton of unneeded internet traffic.
Especially considering those SEVENTY FIVE gravatar images are nothing but avatar images way down at the bottom in the "comments section".

Here are my three added filters to prevent these gravatar images from loading by default - but I can toggle them on by clicking the "F" (fetch) or open in a new tab/window using the "I" (image).

Disregard, will post again after further testing.

Edited by NotHereToPlayGames
Link to comment
Share on other sites

On 1/26/2022 at 1:05 PM, NotHereToPlayGames said:

For a more permanent solution, add this to your Exceptions-U.txt file then have Proxomitron reload the config so that it takes effect (the keylogger remains deactivated unless you manually activate using the "timer" button) -


Disregard , please delete. 

Edited by Dixel
Link to comment
Share on other sites

re: Just add $SET(0=a_track.i_script:0.) to the ublock filters.



Please do not do it that way.
That would basically break our entire reason for adding Proxomitron.
All internet traffic is seen by Proxomitron before any extension sees the internet traffic.
If we start creating extension rules to strip away at Proxomitron functions, then Proxomitron will not be for that user.

It is fair to set up Proxomitron as a "small net to catch a few fish" or as a "wide net to catch too many fish".
The i_script:0 in particular violates the very essence of intentionally using Proxomitron as a "wide net" then employing its "lists" to whitelist per user needs.
If the user prefers the "small net" then i_script:0 would never be needed because that user would not be using the 7.1 Block all Scripts option.

Edited by NotHereToPlayGames
Link to comment
Share on other sites

11 hours ago, NotHereToPlayGames said:

Please do not do it that way.
That would basically break our entire reason for adding Proxomitron.

No problem , sorry . The "easy way solution" comment has been removed a minute ago. I shall not interfere in the future.

Edited by Dixel
made a typo , lol
Link to comment
Share on other sites

Minor updates reserved for next update -

proxcss-menu.css  >>  added  >>  input.Pr0xMLink   --->>>   opacity: 1.0 !important;
proxcss-menu.css  >>  modified  >>  input.Pr0xMLink   --->>>   margin: 0 !important;    ---->>>>    margin: 0 4px 0 0 !important;
proxcss-menu.css  >>  added  >>  input.Pr0xM-Input   --->>>   border-radius: 0 !important;
proxcss-general.css  >>  modified  >>  input.Pr0xBtn-Input   --->>>  border-color: #FFD600;    ---->>>>    border-color: #FFD600 !important;
proxcss-general.css  >>  added  >>  input.Pr0xBtn-Input   --->>>   border-radius: 0 !important;
proxcss-general.css  >>  modified  >>  input.Pr0xBtn-Input   --->>>   border-width: 1px;    ---->>>>    border-width: 1px !important;

Link to comment
Share on other sites

Unsure if this practice is still prevalent or not (companies were sued over it circa 2011 (hulu?)), basically there were web sites that could "recreate" / "respawn" a DELETED cookie by using the Etag http header.
This is the Proxomitron filter that us Proxomitron users were using to prevent that "respawning".
I still keep this in my config but I do not have any in-the-wild examples where "respawning" is known to still be employed or not - I keep it more as an err-on-the-safe-side approach.

Key = "ETag: Always Remove     11.08.16 [jjoe] (o.0) (In) [add++]"
Match = "\1&$LOG(CGET $DTM(c) : ETag removed: \1)"

Link to comment
Share on other sites

Minor updates reserved for next update -

proxcss-menu.css  >>  added   --->>>   form input[type="checkbox"]
proxcss-menu.css  >>  added   --->>>   form input[type="radio"]
proxcss-menu.css  >>  added   --->>>   form input[type="radio"]:checked:before


Minor-major update reserved for next update -   Reverted to previous

Header Top Add: Initial JS Code     19.02.23 (ccw!) [...] (d.r)    ---->>>>    Header Top Add: Initial JS Code w/o nonce     20.02.09 (ccw!) [...] (d.r) [add++]


proxjs-full.js  >>  modified own modification   --->>>   cd = " style=\"text-decoration: line-through !important; display: inline-table;\"";
proxcss-general.css  >>  added  >>  a.Pr0xCookie, span.Pr0xCookie   --->>>   display: inline-table;

Edited by NotHereToPlayGames
Link to comment
Share on other sites

I wouldn't say "normal" but I would say that it's "good".

Don't confuse SSL 3.0 and TLS 1.3.

SSL 3.0 should be disabled/deactivated/killed/blocked (it was called a "POODLE" [Padding Oracle On Downgraded Legacy Encryption] attack and it dates back to 2014) whenever possible and the error message you are showing indicates that an SSL 3.0 attempt was blocked (could also be TLS 1.1) - that's good!

Sites that even use SSL 3.0 are extremely rare nowadays.

If the site still "works", then it has other SSL encryption that it did "accept".

Why it tried to "fallback" to SSL 3.0 when nobody uses SSL 3.0 anymore is a mystery.

Link to comment
Share on other sites

Could anyone confirm that going to https://support.cloudflare.com triggers Cloudflare's "We are checking your browser..." protection?

For me this happens if I have Proxomitron set to intercept SSL traffic whereas if I have it disabled then there is no challenge and I arrive on the support page. Toggling off the various filters makes no difference.

This is the Proxomitron log:

+++GET 129+++
User-Agent: Null
Proxy-Connection: keep-alive
Connection: keep-alive
Host: support.cloudflare.com:443
Accept-encoding: gzip, deflate

+++SSL:GET 129+++
SSL cipher TLSv1.2 AES128-SHA (128 bits)
GET / HTTP/1.1
Host: support.cloudflare.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win32; x86; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Upgrade-Insecure-Requests: 1
Connection: keep-alive

+++SSL:RESP 129+++
SSL cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256 (128 bits)
HTTP/1.1 403 Forbidden <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< This?
Date: Fri, 04 Feb 2022 08:45:53 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
CF-Chl-Bypass: 1
Permissions-Policy: accelerometer=(),autoplay=(),camera=(),clipboard-read=(),clipboard-write=(),fullscreen=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()
X-Frame-Options: SAMEORIGIN
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Set-Cookie: __cf_bm=7Wd9iXmUM6O9FLtNg1102WA2zB_B6bMvEKvSqdvTC8w-1643964353-0-Ac/NnwpZFJXCz6eB88NDbRLuIl2IIQCQKxI+ph9PnbjYui80g3jMHOUFU2tElecV2MNwfnG7lGjD1sbZOxgE8oVsYrJjQCps+vOAdmgk10n2; path=/; domain=.support.cloudflare.com; HttpOnly; Secure; SameSite=None
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=Vkv8KqrFthnDwqvoKTvFsQ5L12aV%2BYmKmwtzWGUJhn1Wju5AFDR%2B3XlN%2FEvxKIjxVQshPKxr1u71LDmD5vfuEa2ycPb5UxZYNzHZ4KxC7CV5Jmu2qwjgPvJgtOM4ZZ31O%2B4oZctk3FY%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Vary: Accept-Encoding
Server: cloudflare
CF-RAY: 6d82a01bcccd3613-MAN
Content-Encoding: gzip
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
+++CLOSE 129+++

Obviously I can't produce the same log without Proxomitron intercepting SSL traffic but I'm pretty sure it's that HTTP/1.1 403 Forbidden that's the problem. But why does it occur?

It appears that the way Proxomitron connects to a web site is different to the way the browser connects and Cloudflare is seeing the difference as some kind of attack.


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...