The Un-Official Proxomitron Forum
Proxomitron Reborn - Printable Version

+- The Un-Official Proxomitron Forum (https://www.prxbx.com/forums)
+-- Forum: Forum Related (/forumdisplay.php?fid=37)
+--- Forum: Proxomitron Program (/forumdisplay.php?fid=4)
+--- Thread: Proxomitron Reborn (/showthread.php?tid=2331)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

RE: Proxomitron Reborn - ProxRocks - Apr. 24, 2024 06:44 AM

(Apr. 11, 2024 12:45 AM)JJoe Wrote:  To test functionality, you can use an online service like
https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html.
The Proxomitron's Log Window may indicate TLS 1.3.

Updated to 4701R and so far everything looks good on my end.
I have noticed that "TLS_GREASE_0A (0xa0a)" is listed using Ungoogled Chromium v114 without Proxomitron.
But is not listed when using with Proxomitron.

I admit that I don't know if this is a "good thing" or a "bad thing".

RE: Proxomitron Reborn - JJoe - Apr. 24, 2024 01:10 PM

GREASE (Generate Random Extensions And Sustain Extensibility) is a proposal from Google. It isn't a cipher.

https://datatracker.ietf.org/doc/html/rfc8701 Wrote:a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

So, it could prevent GREASE enabled browsers from connecting to 'misconfigured' servers. Could be good or bad depending on the site.

It also adds another detail to your fingerprint. Which could be bad, if you needed to be recognized as Ungoogled Chromium v114, or good, if you were trying to mimic a GREASEless browser.

(Apr. 24, 2024 06:44 AM)ProxRocks Wrote:  I have noticed that "TLS_GREASE_0A (0xa0a)" is listed using Ungoogled Chromium v114 without Proxomitron.
But is not listed when using with Proxomitron.

I admit that I don't know if this is a "good thing" or a "bad thing".


RE: Proxomitron Reborn - Anno Domini - Apr. 24, 2024 02:52 PM

I updated to 4701R as well, and when I visit ebay.ca the certificate warning is gone. What a relief. To Amy et al, I don't know how you did it, but who's better than you ? Nobody !

RE: Proxomitron Reborn - amy - Apr. 29, 2024 04:46 AM

(Apr. 24, 2024 02:23 AM)JJoe Wrote:  Does Reborn generate a ECDSA certificate for the ECDSA cipher suites?
RSA only, no DSA/ECDSA support. Do you need it for some reason?

(Apr. 24, 2024 02:23 AM)JJoe Wrote:  Which OpenSSL binary would you prefer for testing?
https://wiki.openssl.org/index.php/Binaries
The ones I linked to in my release announcement post are the ones I've been using.

Regarding GREASE and other differences that Proxomitron's OpenSSL produces compared to a regular browser, other proxies are also noticing them too and working on solutions, e.g. https://github.com/bytedance/g3/issues/138; I'm thinking about how Proxomitron can solve it, probably via some sort of "pass-through ClientHello" with my own TLS/SSL layer client code.

RE: Proxomitron Reborn - JJoe - Apr. 30, 2024 04:16 AM

(Apr. 29, 2024 04:46 AM)amy Wrote:  ...RSA only, no DSA/ECDSA support. Do you need it for some reason?

No. Not yet anyway. It probably explains why the connection failed.

(Apr. 29, 2024 04:46 AM)amy Wrote:  
(Apr. 24, 2024 02:23 AM)JJoe Wrote:  Which OpenSSL binary would you prefer for testing?
https://wiki.openssl.org/index.php/Binaries
The ones I linked to in my release announcement post are the ones I've been using.

I'm wanting to use OpenSSL without the Proxomitron. In the past, the DLLs that Proxomitron used were not equivalent to the stand-alone binaries.

(Apr. 29, 2024 04:46 AM)amy Wrote:  Regarding GREASE and other differences that Proxomitron's OpenSSL produces compared to a regular browser, other proxies are also noticing them too and working on solutions, e.g. https://github.com/bytedance/g3/issues/138; I'm thinking about how Proxomitron can solve it, probably via some sort of "pass-through ClientHello" with my own TLS/SSL layer client code.

Well, if we apply the GREASE logic, all we need is for everybody to use a proxy... Sites can either let us all in or cease to exist. Wink

Got to wonder how much of this is actually about security. Is https-only at ????.??? about hiding your browsing history from outsiders or is it about only ????.??? having that info for sale or trade. ETC.

Anyway, thanks for your efforts. I hope you enjoy the puzzle.

RE: Proxomitron Reborn - ihbman - May. 11, 2024 07:22 AM

I used Proxomitron extensively a decade ago but now whatever site i get a "NET::ERR_CERT_AUTHORITY_INVALID" message. I have changed to incognito, the DNS server, flage to ignore localhost errors, firewall settings. Nothing works. What am I overlooking?

RE: Proxomitron Reborn - ProxRocks - May. 11, 2024 07:43 AM

What OS?
Are you running antivirus?
Are you on a VPN?

RE: Proxomitron Reborn - ihbman - May. 12, 2024 12:00 AM

No to both. Just MS firewall and added an exception for Prox. I used it on Win 7 and 8. Also through wine on Ubuntu.

RE: Proxomitron Reborn - JJoe - May. 13, 2024 01:03 AM

(May. 11, 2024 07:22 AM)ihbman Wrote:  I used Proxomitron extensively a decade ago but now whatever site i get a "NET::ERR_CERT_AUTHORITY_INVALID" message. I have changed to incognito, the DNS server, flage to ignore localhost errors, firewall settings. Nothing works. What am I overlooking?

Assuming you are using amy's Proxomitron Reborn...
Does http work?
https://prxbx.com/forums/showthread.php?tid=2331&pid=20956#pid20956 might help.
Did you start the Proxomitron with a cfg that enables the https server?

RE: Proxomitron Reborn - amy - May. 14, 2024 04:40 AM

That error suggests your browser doesn't trust Proxomitron's certificate. Did you forget to generate one or add it to the list of trusted roots?

RE: Proxomitron Reborn $RDIR and $JUMP - JJoe - May. 18, 2024 03:40 AM

$RDIR and $JUMP appear to be broken but not always.

Opera requests mtalk.google.com at start and frequently thereafter. I block that with list entry
"mtalk.google.com/ $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"

Correction 05/21: 4.6 was using"mtalk.google.com $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"

So far, 4.7 always misses. As It Should Note that there is an unusual port number.
4.7 Wrote:+++GET 2+++
CONNECT / HTTP/1.1
Host: mtalk.google.com:5228
Proxy-Connection: keep-alive
User-Agent:
Bad Request...
[)https://mtalk.google.com:5228˜

]

but 4.6 always catches
4.6 Wrote:New Message Log Window....
RedirectTo: https://127.0.0.1:8443/killed.gif?1:https://mtalk.google.com:5228/
BlockList 1: in Exceptions-U, line 310

+++GET 1+++
CONNECT /killed.gif?1:https://mtalk.google.com:5228/ HTTP/1.1
Host: 127.0.0.1
Proxy-Connection: keep-alive
User-Agent:
+++CLOSE 1+++


***Correction*** for the above.
The list entries were *not* the same.
4.6 and 4.7 block the request with a correct list entry.
When the request is not blocked, "Bad request..."
Apologies for any wasted time. Small screen old eyes.
Dang it...D'oh!

Opera also frequently requests https://merchandise.opera-api2.com/ . No port number.
Both 4.6 and 4.7 block it with list entry "merchandise.opera-api2.com/ $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"

-----------------------------------------------------------------------------------------

Testing with these header filters, OUT = TRUE only:
Code:
[HTTP headers]
In = FALSE
Out = FALSE
Key = "!  test www.prxbx.com $RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"
URL = "www.prxbx.com   $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"

In = FALSE
Out = FALSE
Key = "!  test www.prxbx.com $RDIR(https://local.ptron/killed.gif?$DTM(c):\u)"
URL = "www.prxbx.com   $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://local.ptron/killed.gif?$DTM(c):\u)"

The browser first pauses and then complains NET::ERR_CERT_COMMON_NAME_INVALID. I think this is because the Proxomitron is using 127.0.0.1 or local.ptron for the common name in the cert.
If I tell the browser to continue, the Proxomitron replies:
"Error Opening Local File... The Proxomitron couldn't open the local file... \... Check that the name is correct and the file exists."
I think this is because the path has been lost. The file can be accessed with the link in the $RDIR command.
If I change to $JUMP, the path of the destination URL does not appear in opera's address bar.
These tests show the same results with 4.6 or 4.7.

Both of these $RDIR or $JUMP
Code:
[HTTP headers]
In = FALSE
Out = FALSE
Key = "!  test www.prxbx.com  $RDIR(https://proxomitron.info/news/index.html)"
URL = "www.prxbx.com  $RDIR(https://proxomitron.info/news/index.html)"

In = FALSE
Out = FALSE
Key = "!  test www.prxbx.com $RDIR(https://proxomitron.info/)"
URL = "www.prxbx.com   $RDIR(https://proxomitron.info/)"

cause the browser to load https://proxomitron.info/index.html .
Again, the path, "news/index.html", appears to have been lost.

---------------------------------------------------------------------------------------------

This works as it should
Code:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "!  test securepubads.g.doubleclick.net/tag/js/gpt.js $RDIR(https://proxomitron.info/)"
URL = "securepubads.g.doubleclick.net/tag/js/gpt.js   $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://local.ptron/killed.gif?$DTM(c):\u)"

This, however,
Code:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "!  test securepubads.g.doubleclick.net/tag/js/gpt.js $RDIR(https://proxomitron.info/)"
URL = "[^/]++.doubleclick.net/ $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(https://127.0.0.1:8443/killed.gif?$DTM(c):\u)"
4.7 gets a 400 with a correct common name:
"The Proxomitron couldn't open the local file... \tag\js\gpt.js... Check that the name is correct and the file exists."
4.6 has correct common name but
"SSLeay couldn't establish a secure connection to... 127.0.0.1:8443/tag/js/gpt.js Try placing Proxomitron in bypass mode."

As a list entry, [^/]++.doubleclick.net/..., 4.7 works as it should, while 4.6 gives the browser the wrong common name and receives NET::ERR_CERT_COMMON_NAME_INVALID nag.

I haven't checked http or "In = TRUE".

When you have some spare time and curiosity...
Thanks

Edit: Added $RDIR and $JUMP to subject
Edit: 05/21/24 Added correction for mtalk.google.com:5228.

RE: Proxomitron Reborn Very Long URLs - JJoe - May. 18, 2024 09:18 PM

Some requests are using very long URLs. The Proxomitron limit appears be 2065.
Can this limit be increased?

Following code box shows requested URL on first line, contents of \u on second line.
Code:
https://www.google.com/xjs/_/js/k=xjs.s.en_US.X3-GnylHzAo.O/am=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAEICQQAAACgAAAABAAAAAAAAgBAAAEIAQADeA1AhgAAQGABgAIggwM9_AgAAAABAwAAAIIAJAAAAgAsACAQAggAAQAAAAIACAAAAAAAAAAAAAAAcQAD6AQAAAAAAAAAAAAAAGBB-AIAAACAEDhAEAIAAAAAA8gDwPGA4SGEBAAAAAAAAAAAAAEAAEgRzIP0FAUAAAAAAAAAAAAAAAABS0onLGwAgAQ/d=1/ed=1/dg=2/br=1/rs=ACT90oF0qS7nKTKgPlom_KxAHh1GxX1b6g/ee=ALeJib:B8gLwd;AfeaP:TkrAjf;Afksuc:wMx0R;BMxAGc:E5bFse;BgS6mb:fidj5d;BjwMce:cXX2Wb;CxXAWb:YyRLvc;DM55c:imLrKe;DULqB:RKfG5c;Dkk6ge:wJqrrd;DpcR3d:zL72xf;EABSZ:MXZt9d;ESrPQc:mNTJvc;EVNhjf:pw70Gc;EmZ2Bf:zr1jrb;EnlcNd:WeHg4;Erl4fe:FloWmf,FloWmf;F9mqte:UoRcbe;Fmv9Nc:O1Tzwc;G0KhTb:LIaoZ;G6wU6e:hezEbd;GleZL:J1A7Od;HMDDWe:G8QUdb;HqeXPd:cmbnH;IBADCc:RYquRb;IoGlCf:b5lhvb;IsdWVc:qzxzOb;JXS8fb:Qj0suc;JbMT3:M25sS;JsbNhc:Xd8iUd;KOxcK:OZqGte;KQzWid:ZMKkN;KcokUb:KiuZBf;KpRAue:Tia57b;LBgRLc:SdcwHb,XVMNvd;LEikZe:byfTOb,lsjVmc;LsNahb:ucGLNb;Me32dd:MEeYgc;NPKaK:SdcwHb;NSEoX:lazG7b;Np8Qkd:Dpx6qc;Nyt6ic:jn2sGd;OgagBe:cNTe0;Oj465e:KG2eXe,KG2eXe;OohIYe:mpEAQb;Pjplud:EEDORb,PoEs9b;PqHfGe:im2cZe;Q1Ow7b:x5CSu;Q6C5kf:pfdZCe;QGR0gd:Mlhmy;R2kc8b:ALJqWb;R4IIIb:QWfeKf;R9Ulx:CR7Ufe;RDNBlf:zPRCJb;SLtqO:Kh1xYe;SMDL4c:fTfGO,fTfGO;SNUn3:ZwDk9d,x8cHvb;ShpF6e:N0pvGc;TxfV6d:YORN0b;U96pRd:FsR04;UDrY1c:eps46d;UVmjEd:EesRsb;UyG7Kb:wQd0G;V2HTTe:RolTY;VGRfx:VFqbr;VN6jIc:ddQyuf;VOcgDe:YquhTb;VsAqSb:PGf2Re;VxQ32b:k0XsBb;WCEKNd:I46Hvd;WDGyFe:jcVOxd;Wfmdue:g3MJlb;XUezZ:sa7lqb;YV5bee:IvPZ6d;YkQtAf:rx8ur;ZMvdv:PHFPjb;ZSH6tc:QAvyLe;ZWEUA:afR4Cf;Zen4yb:jMF88c;a56pNe:JEfCwb;aAJE9c:WHW6Ef;aCJ9tf:qKftvc;aZ61od:arTwJ;af0EJf:ghinId;bDXwRe:UsyOtc;bFZ6gf:RsDQqe;bcPXSc:gSZLJb;cEt90b:ws9Tlc;cFTWae:gT8qnd;coJ8e:KvoW8;dIoSBb:ZgGg9b;dLlj2:Qqt3Gf;daB6be:lMxGPd;dtl0hd:lLQWFe;eBAeSb:Ck63tb;eBZ5Nd:VruDBd;eHDfl:ofjVkb;eO3lse:nFClrf;fWLTFc:TVBJbf;g8nkx:U4MzKc;gaub4:TN6bMe;gtVSi:ekUOYd;h3MYod:cEt90b;hK67qb:QWEO5b;heHB1:sFczq;hjRo6e:F62sG;hsLsYc:Vl118;iFQyKf:QIhFr,vfuNJf;imqimf:jKGL2e;io8t5d:sgY6Zb;jY0zg:Q6tNgc;k2Qxcb:XY51pe;kCQyJ:ueyPK;kMFpHd:OTA3Ae;kbAm9d:MkHyGd;lkq0A:JyBE3e;nAFL3:NTMZac,s39S4;oGtAuc:sOXFj;oSUNyd:fTfGO,fTfGO;oUlnpc:RagDlc;okUaUd:wItadb;p2tIDb:tp1Cx;pKJiXd:VCenhc;pNsl2d:j9Yuyc;pXdRYb:JKoKVe;pj82le:mg5CW;qGV2uc:HHi04c;qZx2Fc:j0xrE;qaS3gd:yiLg6e;qavrXe:zQzcXe;qddgKe:d7YSfd,x4FYXe;rQSrae:C6D5Fc;sP4Vbe:VwDzFe;sTsDMc:kHVSUb;tH4IIe:Ymry6;tosKvd:ZCqP3;trZL0b:qY8PFe;uY49fb:COQbmf;uknmt:GkPrzb;uuQkY:u2V3ud;vGrMZ:lPJJ0c;vfVwPd:lcrkwe;w3bZCb:ZPGaIb;w4rSdf:XKiZ9;w9w86d:dt4g2b;wQlYve:aLUfP;wR5FRb:O1Gjze,TtcOte;wV5Pjc:L8KGxe;whEZac:F4AmNb;xBbsrc:NEW1Qc;xbe2wc:uRMPBc;yGxLoc:FmAr0c;yxTchf:KUM7Z;z97YGf:oug9te;zOsCQe:Ko78Df;zaIgPb:Qtpxbd/m=attn,cdos,gwc,hsm,jsa,mb4ZUb,d,csi,cEt90b,SNUn3,qddgKe,sTsDMc,dtl0hd,eHDfl
https://www.google.com/xjs/_/js/k=xjs.s.en_US.X3-GnylHzAo.O/am=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAEICQQAAACgAAAABAAAAAAAAgBAAAEIAQADeA1AhgAAQGABgAIggwM9_AgAAAABAwAAAIIAJAAAAgAsACAQAggAAQAAAAIACAAAAAAAAAAAAAAAcQAD6AQAAAAAAAAAAAAAAGBB-AIAAACAEDhAEAIAAAAAA8gDwPGA4SGEBAAAAAAAAAAAAAEAAEgRzIP0FAUAAAAAAAAAAAAAAAABS0onLGwAgAQ/d=1/ed=1/dg=2/br=1/rs=ACT90oF0qS7nKTKgPlom_KxAHh1GxX1b6g/ee=ALeJib:B8gLwd;AfeaP:TkrAjf;Afksuc:wMx0R;BMxAGc:E5bFse;BgS6mb:fidj5d;BjwMce:cXX2Wb;CxXAWb:YyRLvc;DM55c:imLrKe;DULqB:RKfG5c;Dkk6ge:wJqrrd;DpcR3d:zL72xf;EABSZ:MXZt9d;ESrPQc:mNTJvc;EVNhjf:pw70Gc;EmZ2Bf:zr1jrb;EnlcNd:WeHg4;Erl4fe:FloWmf,FloWmf;F9mqte:UoRcbe;Fmv9Nc:O1Tzwc;G0KhTb:LIaoZ;G6wU6e:hezEbd;GleZL:J1A7Od;HMDDWe:G8QUdb;HqeXPd:cmbnH;IBADCc:RYquRb;IoGlCf:b5lhvb;IsdWVc:qzxzOb;JXS8fb:Qj0suc;JbMT3:M25sS;JsbNhc:Xd8iUd;KOxcK:OZqGte;KQzWid:ZMKkN;KcokUb:KiuZBf;KpRAue:Tia57b;LBgRLc:SdcwHb,XVMNvd;LEikZe:byfTOb,lsjVmc;LsNahb:ucGLNb;Me32dd:MEeYgc;NPKaK:SdcwHb;NSEoX:lazG7b;Np8Qkd:Dpx6qc;Nyt6ic:jn2sGd;OgagBe:cNTe0;Oj465e:KG2eXe,KG2eXe;OohIYe:mpEAQb;Pjplud:EEDORb,PoEs9b;PqHfGe:im2cZe;Q1Ow7b:x5CSu;Q6C5kf:pfdZCe;QGR0gd:Mlhmy;R2kc8b:ALJqWb;R4IIIb:QWfeKf;R9Ulx:CR7Ufe;RDNBlf:zPRCJb;SLtqO:Kh1xYe;SMDL4c:fTfGO,fTfGO;SNUn3:ZwDk9d,x8cHvb;ShpF6e:N0pvGc;TxfV6d:YORN0b;U96pRd:FsR04;UDrY1c:eps46d;UVmjEd:EesRsb;UyG7Kb:wQd0G;V2HTTe:RolTY;VGRfx:VFqbr;VN6jIc:ddQyuf;VOcgDe:YquhTb;VsAqSb:PGf2Re;VxQ32b:k0XsBb;WCEKNd:I46Hvd;WDGyFe:jcVOxd;Wfmdue:g3MJlb;XUezZ:sa7lqb;YV5bee:IvPZ6d;YkQtAf:rx8ur;ZMvdv:PHFPjb;ZSH6tc:QAvyLe;ZWEUA:afR4Cf;Zen4yb:jMF88c;a56pNe:JEfCwb;aAJE9c:WHW6Ef;aCJ9tf:qKftvc;aZ61od:arTwJ;af0EJf:ghinId;bDXwRe:UsyOtc;bFZ6gf:RsDQqe;bcPXSc:gSZLJb;cEt90b:ws9Tlc;cFTWae:gT8qnd;coJ8e:KvoW8;dIoSBb:ZgGg9b;dLlj2:Qqt3Gf;daB6be:lMxGPd;dtl0hd:lLQWFe;eBAeSb:Ck63tb;eBZ5Nd:VruDBd;eHDfl:ofjVkb;eO3lse:nFClrf;fWLTFc:TVBJbf;g8nkx:U4MzKc;gaub4:TN6bMe;gtVSi:ekUOYd;h3MYod:cEt90b;hK67qb:QWEO5b;heHB1:sFczq;hjRo6e:F62sG;hsLsYc:Vl118;iFQyKf:QIhFr,vfuNJf;imqimf:jKGL2e;io8t5d:sgY6Zb;jY0zg:Q6tNgc;k2Qxcb:XY51pe;kCQyJ:ueyPK;kMFpHd:OTA3Ae;kbAm9d:MkHyGd;lkq0A:JyBE3e;nAFL3:NTMZac,s39S4;oGtAuc:sOXFj;oSUNyd:fTfGO,fTf

The Proxomitron's log window showed
Code:
BlockList 1597: in Bypass-List, line 46

+++SSL:GET 1597+++
SSL cipher TLSv1.3 TLS_AES_128_GCM_SHA256 (128 bits)
GET /xjs/_/js/k=xjs.s.en_US.X3-GnylHzAo.O/am=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAEICQQAAACgAAAABAAAAAAAAgBAAAEIAQADeA1AhgAAQGABgAIggwM9_AgAAAABAwAAAIIAJAAAAgAsACAQAggAAQAAAAIACAAAAAAAAAAAAAAAcQAD6AQAAAAAAAAAAAAAAGBB-AIAAACAEDhAEAIAAAAAA8gDwPGA4SGEBAAAAAAAAAAAAAEAAEgRzIP0FAUAAAAAAAAAAAAAAAABS0onLGwAgAQ/d=1/ed=1/dg=2/br=1/rs=ACT90oF0qS7nKTKgPlom_KxAHh1GxX1b6g/ee=ALeJib:B8gLwd;AfeaP:TkrAjf;Afksuc:wMx0R;BMxAGc:E5bFse;BgS6mb:fidj5d;BjwMce:cXX2Wb;CxXAWb:YyRLvc;DM55c:imLrKe;DULqB:RKfG5c;Dkk6ge:wJqrrd;DpcR3d:zL72xf;EABSZ:MXZt9d;ESrPQc:mNTJvc;EVNhjf:pw70Gc;EmZ2Bf:zr1jrb;EnlcNd:WeHg4;Erl4fe:FloWmf,FloWmf;F9mqte:UoRcbe;Fmv9Nc:O1Tzwc;G0KhTb:LIaoZ;G6wU6e:hezEbd;GleZL:J1A7Od;HMDDWe:G8QUdb;HqeXPd:cmbnH;IBADCc:RYquRb;IoGlCf:b5lhvb;IsdWVc:qzxzOb;JXS8fb:Qj0suc;JbMT3:M25sS;JsbNhc:Xd8iUd;KOxcK:OZqGte;KQzWid:ZMKkN;KcokUb:KiuZBf;KpRAue:Tia57b;LBgRLc:SdcwHb,XVMNvd;LEikZe:byfTOb,lsjVmc;LsNahb:ucGLNb;Me32dd:MEeYgc;NPKaK:SdcwHb;NSEoX:lazG7b;Np8Qkd:Dpx6qc;Nyt6ic:jn2sGd;OgagBe:cNTe0;Oj465e:KG2eXe,KG2eXe;OohIYe:mpEAQb;Pjplud:EEDORb,PoEs9b;PqHfGe:im2cZe;Q1Ow7b:x5CSu;Q6C5kf:pfdZCe;QGR0gd:Mlhmy;R2kc8b:ALJqWb;R4IIIb:QWfeKf;R9Ulx:CR7Ufe;RDNBlf:zPRCJb;SLtqO:Kh1xYe;SMDL4c:fTfGO,fTfGO;SNUn3:ZwDk9d,x8cHvb;ShpF6e:N0pvGc;TxfV6d:YORN0b;U96pRd:FsR04;UDrY1c:eps46d;UVmjEd:EesRsb;UyG7Kb:wQd0G;V2HTTe:RolTY;VGRfx:VFqbr;VN6jIc:ddQyuf;VOcgDe:YquhTb;VsAqSb:PGf2Re;VxQ32b:k0XsBb;WCEKNd:I46Hvd;WDGyFe:jcVOxd;Wfmdue:g3MJlb;XUezZ:sa7lqb;YV5bee:IvPZ6d;YkQtAf:rx8ur;ZMvdv:PHFPjb;ZSH6tc:QAvyLe;ZWEUA:afR4Cf;Zen4yb:jMF88c;a56pNe:JEfCwb;aAJE9c:WHW6Ef;aCJ9tf:qKftvc;aZ61od:arTwJ;af0EJf:ghinId;bDXwRe:UsyOtc;bFZ6gf:RsDQqe;bcPXSc:gSZLJb;cEt90b:ws9Tlc;cFTWae:gT8qnd;coJ8e:KvoW8;dIoSBb:ZgGg9b;dLlj2:Qqt3Gf;daB6be:lMxGPd;dtl0hd:lLQWFe;eBAeSb:Ck63tb;eBZ5Nd:VruDBd;eHDfl:ofjVkb;eO3lse:nFClrf;fWLTFc:TVBJbf;g8nkx:U4MzKc;gaub4:TN6bMe;gtVSi:ekUOYd;h3MYod:cEt90b;hK67qb:QWEO5b;heHB1:sFczq;hjRo6e:F62sG;hsLsYc:Vl118;iFQyKf:QIhFr,vfuNJf;imqimf:jKGL2e;io8t5d:sgY6Zb;jY0zg:Q6tNgc;k2Qxcb:XY51pe;kCQyJ:ueyPK;kMFpHd:OTA3Ae;kbAm9d:MkHyGd;lkq0A:JyBE3e;nAFL3:NTMZac,s39S4;oGtAuc:sOXFj;oSUNyd:fTfGO,fTf HTTP/0.9
O;oUlnpc: RagDlc;okUaUd:wItadb;p2tIDb:tp1Cx;pKJiXd:VCenhc;pNsl2d:j9Yuyc;pXdRYb:JKoKVe;pj82le:mg5CW;qGV2uc:HHi04c;qZx2Fc:j0xrE;qaS3gd:yiLg6e;qavrXe:zQzcXe;qddgKe:d7YSfd,x4FYXe;rQSrae:C6D5Fc;sP4Vbe:VwDzFe;sTsDMc:kHVSUb;tH4IIe:Ymry6;tosKvd:ZCqP3;trZL0b:qY8PFe;uY49fb:COQbmf;uknmt:GkPrzb;uuQkY:u2V3ud;vGrMZ:lPJJ0c;vfVwPd:lcrkwe;w3bZCb:ZPGaIb;w4rSdf:XKiZ9;w9w86d:dt4g2b;wQlYve:aLUfP;wR5FRb:O1Gjze,TtcOte;wV5Pjc:L8KGxe;whEZac:F4AmNb;xBbsrc:NEW1Qc;xbe2wc:uRMPBc;yGxLoc:FmAr0c;yxTchf:KUM7Z;z97YGf:oug9te;zOsCQe:Ko78Df;zaIgPb:Qtpxbd/m=attn,cdos,gwc,hsm,jsa,mb4ZUb,d,csi,cEt90b,SNUn3,qddgKe,sTsDMc,dtl0hd,eHDfl HTTP/1.1
Host: www.google.com
Code:
+++SSL:RESP 1597+++
SSL cipher TLSv1.3 TLS_AES_256_GCM_SHA384 (256 bits)
HTTP/0.9 400 Bad Request
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Content-Length: 1555
+++CLOSE 1597+++

This bad request explains some of the browser hangs.

RE: Proxomitron Reborn 4.7: 1 $RDIR gets 2 GETS - JJoe - May. 21, 2024 03:37 AM

Exceptions-U contains
Code:
example.com/ $USEPROXY(false)$SET(keyword=i_proxy:0.)$RDIR(http://127.0.0.1:8080/killed.gif?$DTM(c):\u)

Log window for 4.6 is as expected.
Log window for 4.7 shows 2 request-response pairs for one $RDIR from http://www.example.com/
Note that the connection number, $DTM(c), in the generated query string, 2867:http://www.example.com/, is 2867 for both.
Similar results for https
Code:
RedirectTo: http://127.0.0.1:8080/killed.gif?2867:http://www.example.com/
BlockList 2867: in Exceptions-U, line 1510

+++GET 2867+++
GET /killed.gif?2867:http://www.example.com/ HTTP/1.1
Host: 127.0.0.1
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

+++GET 2868+++
GET /killed.gif?2867:http://www.example.com/ HTTP/1.1
Host: 127.0.0.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

+++RESP 2868+++
HTTP/1.1 200 Local file
Date: Tue, 21 May 2024 02:40:44 GMT
Server: Proxomitron
Connection: close
Last-Modified: Fri, 08 Jan 1999 09:47:22 GMT
Content-Length: 55
Content-type: image/gif
Cache-Control: public, max-age=86400
+++CLOSE 2868+++

+++RESP 2867+++
HTTP/1.1 200 Local file
Date: Tue, 21 May 2024 02:40:44 GMT
Server: Proxomitron
Last-Modified: Fri, 08 Jan 1999 09:47:22 GMT
Content-Length: 55
Content-type: image/gif
Cache-Control: public, max-age=86400
+++CLOSE 2867+++

Edit: Corrected Exceptions-U entry. It was http not https

RE: Proxomitron Reborn - rasczak - Jun. 07, 2024 06:23 AM

Reborn 4.7.0.1 + Amy's OpenSSL v1.3 dlls stopped ddg from serving me duck captchas and archive.is is now working. Thank you Amy!


Curiously, I had to rewrite a webpage filter with a bounds match that used $NEST(). For reference, in this old thread $NEST command behavior sidki stated
Quote:at some time at Arne's board everyone started to use $NEST(<a\s,[/url]) instead of <a\s*[/url] because of the speed gain. Scott said several times that that isn't a good idea. We didn't understand why and didn't know about that quote problem either, but silently went back to the old bounds.
and Scott on NEST
Quote:Normally NEST ignores anything within quotes - this prevents tags in quoted strings from affecting it. Very useful for parsing through or around JavaScripts especially. Unfortunately, random unmatched quotes in the body text of a web page can cause trouble. it'll ignore any quote if it can't find a match to it on the same line - this helps, but isn't perfect.


OLD filter (works in proxo 4.5.0.0, but fails using Reborn with the same config)
$NEST(<[a-z][a-z]+\s,*INNERMATCH*,>)
NEW filter (works using Reborn)
$NEST(<,[a-z][a-z]+\s*INNERMATCH*,>)

Been using NEST like this for a while and using the new filter with Reborn for a month and haven't noticed anythng funny. The quote issue is the only thing I could find that was relevant to NEST and I don't know if it is or not. I welcome any insights/suggestions.

RE: Proxomitron Reborn start match of $NEST doesn't use all of the matching language - JJoe - Jun. 07, 2024 08:56 PM

(Jun. 07, 2024 06:23 AM)rasczak Wrote:  OLD filter (works in proxo 4.5.0.0, but fails using Reborn with the same config)
$NEST(<[a-z][a-z]+\s,*INNERMATCH*,>)
NEW filter (works using Reborn)
$NEST(<,[a-z][a-z]+\s*INNERMATCH*,>)

It looks like the start match of $NEST doesn't use all of the matching language. Your new filter works around the problem by moving the expression to the the inner match.
Code:
[Patterns]
Name = "Test matching expressions in $NEST start match"
Active = FALSE
Limit = 256
Match = "$NEST(<[a-z][a-z]+\s,\1,>)"
Replace = "**\1**"

Tested in test window against
Code:
<enter test HTML here>
...some HTML...
<table name="outer table">
  ...
  <table name="inner table">
    ...
  </table>
  ...
</table>
...some more HTML..

works in proxo 4.5.0.0, but fails using Reborn

as does
Code:
[Patterns]
Name = "Test matching expressions in $NEST start match"
Active = FALSE
Limit = 256
Match = "$NEST(<(table|enter),\1,>)"
Replace = "**\1**"

However
$NEST(<\w,\1,>)
and
$NEST(<*\s,\1,>)
did work in reborn.

I haven't checked the previous version of reborn or tested the end match.

Edit: grammar changed 'or' to 'of'.