Problems accessing certain sites (Https aka TLS)

[Dave-H]

1 hour ago, heinoganda said:

Have new build generated by ProxHTTPSProxy v1.5 (Rev3a), with small changes script, various python modules updated, config.ini supplemented by some entries, CA certificates (cacert.pem) updated and alternativ cacert.pem from MSCerts (Cert_Updater) 11/28/2018.
If anyone has interest please write a PM to me.

Info:
At Python 3.44 the support ends in March 2018. With the latest cryptography module version 2.5 (Jan 22, 2019) ProxHTTPSProxy does not work on Windows XP anymore. Last working version 2.4.2 (Nov 21, 2018).

Working great!

Edited February 1, 2019 by Dave-H
Quote added as post has appeared on a new page

[heinoganda]

Have new build generated by ProxHTTPSProxy v1.5 (Rev3b), various python modules updated (cryptography-2.6.1_openssl-1.1.0j), config.ini supplemented by some entries, CA certificates (cacert.pem) updated and alternativ cacert.pem from MSCerts (Cert_Updater) 11/28/2018.
If anyone has interest please write a PM to me.

Info:
At Python 3.44 the support ends in March 2019. With the latest official cryptography module version 2.6.1 (Feb 28, 2019) ProxHTTPSProxy does not work on Windows XP anymore. Last official working version 2.4.2 (Nov 21, 2018).

Edited March 10, 2019 by heinoganda

[Bersaglio]

@heinoganda

Thank You very much for the new Rev3b release, works like a charm! But how did You managed to compile new cryptography 2.6.1 with XP compatibility? You previously mentioned that this is not possible...

[heinoganda]

8 minutes ago, Bersaglio said:

You previously mentioned that this is not possible...

I have created my own cryptography module with OpenSSL 1.1.0j. I would prefer the latest OpenSSL 1.1.1b, but this does not work in Windows XP.

More on this

[heinoganda]

Have new build generated by ProxHTTPSProxy v1.5 (Rev3c), python module cryptography-2.6.1 with openssl-1.1.1b (Thanks to @Mathwiz) updated.
If anyone has interest please write a PM to me.

Info:
At Python 3.44 the support ends in March 2019. With the latest official cryptography module version 2.6.1 (Feb 28, 2019) ProxHTTPSProxy does not work on Windows XP anymore. Last official working version 2.4.2 (Nov 21, 2018).

[Fritz_Geiger]

Is it possible to compile HTTPSProxy without SSE/SSE2?

Actually I tested only the version included with launcher (v1.5.2 2018-11-06) - it does not run on non-SSE Duron, but does on SSE2 Pentium M.

[Thomas S.]

@Fritz_Geiger

I don't really know. But I think no.

HTTPSProxy is not compiled.

It is built with pyInstaller, which combines the required runtime environment from Python, the required modules, and the Python script.

In this respect, support for older processors depends directly on the version of Python and the modules that still support it. These versions should be very old and support the functions required here no longer, certainly not safe nenough.

And I'm sorry, because of a lack of hope and low demand: I can't and won't test this case.

I don't even have an old machine...

 

[Fritz_Geiger]

On 11/4/2019 at 11:33 PM, Thomas S. said:

I don't even have an old machine...

Thanks for your attention and clear answer.

Now I plan to install the old-https-program (BTW, ReGet download manager)

to other WinXPSP3 computer in my LAN,

that has SSE2 and where HTTPSProxy can work.

When ReGet on my current computer will not download some files

(and the destination site uses https strictly, search&replace 'https' to 'http' in download list can not help),

I will move the remaining queue to the computer with HTTPSProxy.

It can be done effortless, and, in most cases, this is more time-effective

than trying to manually edit requests and read negative server responses one-by-one.

 

P. S. There are some proxy sites, that do conversion from "old" to "new" https,

taking "old" requests from user and sending "new" to destination site.

Like other free proxies, they do not last long.

I used two Japan IPs In ReGet proxy settings, but they stopped approximately a month ago,

and other free proxies provided by FireFox add-ons "One Click Proxy" and "Best Proxy Switcher",

do not do the mentioned "conversion".

So I started to search how implement "my own" proxy, "with blackjack and hookers" (c) Bender.

[loopypalm]

On 12/30/2016 at 10:38 PM, Mathwiz said:

There's some chance it'll work; probably a better chance than with the Win7 version (IIRC, that's been tried and didn't work).

The .dlls aren't very big, and ReactOS is free and open-source, so I think it's OK to post them here.

Just make sure you back up the schannel.dll that came with WinXP before you do anything with these!

You may need to shut down XP and copy them to your windows\system32 directory off-line. Also copy schannel.dll to the dllcache subdirectory if System File Checker is enabled; otherwise XP will just put the old schannel.dll back.

If you try it, let us know how it went, whether success or fail
 

system32.7z

your link is not working
any working link please ? i need this !

[Mathwiz]

That was from ReactOS 0.4.3 and it didn't work, so I deleted it. I'll upload a newer version soon; when I do, let us know if it works for you.

Edited November 21, 2019 by Mathwiz

[siria]

No idea if already mentioned here (probably, but no harm if repeated)
Just rediscovered in an older K-Meleon macro (servers2 on kmext.sf.net) two workarounds to load broken TLS pages from -gasp- Google directly:
Google Cache (had wrongly thought for years it would only work from search results!) and
Google Weblight (all new to me, cripples most pages to save 80% bandwidth for 2G phones)
So at the moment am mainly trying those 3 quick macro-redirects if not wanting to fire up a fallback browser, which would be best of course, or if those fail too:

1) wayback machine without javascript, access page which is closest to cropped date:
https://web.archive.org/web/2019/http://www....(URL)

2) Google Cache:
https://webcache.googleusercontent.com/search?q=cache:https%3A%2F%2Fwww...(encoded URL)

3) Google Weblight:
needs a MOBILE useragent string, and ATTENTION: all links in such a page will open weblight too:
https://googleweblight.com/i?u=http://www....(URL)

[heinoganda]

@All

Have new build generated by ProxHTTPSProxy v1.5 (Rev3e),  python module cryptography-2.8 with openssl-1.1.1d (Thanks to @Mathwiz), cacert.pem, alternativ cacert.pem from MSCerts (Cert_Updater) 11/12/2019 and various modules updated.

If anyone has interest please write a PM to me.
 

 

@Mathwiz

Thank you that you made the effort because openssl v1.1.1d for XP. With the files libcrypto_static.lib and libssl_static.lib (renamed libcrypto.lib and libssl.lib) it worked this time. 

cryptography 2.8 module with OpenSSL -1.1.1d for Python 3.4.4 on WXP, I have tested so far with the following modules:

altgraph==0.16.1
appdirs==1.4.3
asn1crypto==1.2.0
cffi==1.13.2
colorama==0.4.1
cryptography==2.8
future==0.18.2
idna==2.8
macholib==1.11
packaging==19.2
pefile==2019.4.18
pyasn1==0.4.8
pycparser==2.19
PyInstaller==3.4
pyOpenSSL==19.1.0
pyparsing==2.4.5
PySocks==1.7.1
pywin32==221
pywin32-ctypes==0.2.0
six==1.13.0
urllib3==1.25.7

For Installing:

Uninstall the older cryptography module beforehand (pip uninstall cryptography), then simply unpack the two directories in the python directory
python34\lib\site-packages.

Download:
here

Note:
The manually installed cryptography module can be uninstalled the usual way (pip uninstall cryptography)!

Edited November 26, 2019 by heinoganda

[genieautravail]

On 11/26/2019 at 1:58 AM, heinoganda said:

@All

Have new build generated by ProxHTTPSProxy v1.5 (Rev3e),  python module cryptography-2.8 with openssl-1.1.1d (Thanks to @Mathwiz), cacert.pem, alternativ cacert.pem from MSCerts (Cert_Updater) 11/12/2019 and various modules updated.

If anyone has interest please write a PM to me.

Hello,

Can you reduce the memory footprint of ProxHTTPSProxy ?

After only one hour of surf on internet, the process take 100 Mb of memory! 

[Dave-H]

That does look a bit excessive, mine takes about 3 Mb when it's idle, and about 6 Mb while I have a Firefox tab open!
Is the memory use still high with your browsers and/or e-mail programs closed?

 

Edited December 13, 2019 by Dave-H
Amendment

[siria]

GRRR.... sorry must vent. As was reported already a few days somewhere (?) Wikipedia now completely blocks old browsers too, by accepting ONLY TLS1.2 ciphers. Which makes IMO absolutely no sense if a reader's browser just isn't able to use it, and the reader only wants to see a public page, but have already ranted a bit about that in another topic.

But to add insult to injury, and what makes Wikipedia now even much WORSE as github, twitter, sourceforge, developer.mozilla.org and countless other blocked public sites:
Wikipedia immediately REDIRECTS old browsers to a fix URL warning page:

https://en.wikipedia.org/sec-warning
That means they even destroy the original target URL!
And that means in old browsers it's not even possible anymore to copy the target URL from the blocked page for copy/pasting into a fallback browser.

> Wikipedia is making the site more secure. You are using an old web browser that will not be able
> to connect to Wikipedia in the future. Please update your device or contact your IT administrator.

> We are removing support for insecure TLS protocol versions, specifically TLSv1.0 and TLSv1.1,
> which your browser software relies on to connect to our sites. This is usually caused by using
> some ancient browser or user agents like old Android smartphones.
> Also it could be interference from corporate or personal "Web Security" software which
> actually downgrades connection security.

For now my only lousy workaround will be to make my kmeleon redirecting macro to automatically replace all wikipedia links with something like xxxwikipedia on middle-click, in order to retain at least the URL. The other alternative would be to redirect them all to googlecache or googleweblight automatically too, but want to decide that case-by-case.

Then again, perhaps they'll remove that killer redirect again next year? This sounds like it:

> You must upgrade your browser or otherwise fix this issue to access our sites.
> This message will remain until Jan 1, 2020.
> After that date, your browser will not be able to establish a connection to our servers at all.