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

[jaclaz]

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:

https://www.dafont.com/white-rabbit.font

jaclaz 

[Ben Markson]

Okay, I think I'm there. This post confirms what you have already said and it has a pretty comprehensive explanation of what happens.
https://prxbx.com/forums/showthread.php?tid=2331&pid=19523#pid19523

Quote

"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:
https://prxbx.com/forums/showthread.php?tid=2331&pid=19530#pid19530

Quote

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

Ben.


 

 

 

[NotHereToPlayGames]

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 January 27, 2022 by NotHereToPlayGames

[Dixel]

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) -

# MSFN
msfn.org/
    $SET(0=a_track.i_script:0.)

Disregard , please delete. 

Edited January 27, 2022 by Dixel

[NotHereToPlayGames]

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 January 27, 2022 by NotHereToPlayGames

[NotHereToPlayGames]

1 hour ago, NotHereToPlayGames said:

All internet traffic is seen by Proxomitron before any extension sees the internet traffic.

This includes incognito mode!

Which to me is a gigantic PLUS  

[Dixel]

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 January 27, 2022 by Dixel
made a typo , lol

[NotHereToPlayGames]

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;

[NotHereToPlayGames]

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.

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

[NotHereToPlayGames]

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 February 11, 2022 by NotHereToPlayGames

[LowLander]

Hi

in HTTP Log i have this...(see picture) is this normal ?

Edited February 3, 2022 by LowLander

[NotHereToPlayGames]

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.

[LowLander]

i'm not talking about the SSL but the Referer it repeat in loop

 

[NotHereToPlayGames]

Yes, that is normal.

Proxomitron fakes a referer by default if none is already present or if it is a third-party referer.

You can turn this filter off if you don't wish to fake the referer -

[Ben Markson]

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+++
CONNECT / HTTP/1.1
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.

Ben.