ProxHTTPSProxy and HTTPSProxy in Windows XP for future use

[VistaLover]

On 5/21/2024 at 7:57 PM, Anbima said:

Yes, that is the problem.
With "*." all third-level domains are recorded.
Can several different domains be entered in the IF query,
or do I have to make a separate query for each domain?

... Consult previously linked documentation, e.g. 
https://findproxyforurl.com/pac-functions/

Quote

dnsDomainIs
Evaluates hostnames and returns true if hostnames match. Used mainly to match and exception individual hostnames.
...
shExpMatch
Will attempt to match hostname or URL to a specified shell expression, and returns true if matched.

In your sample case, and to include all subdomains, something like: 

if (dnsDomainIs(host, ".example.com")

or (the one you found yourself): 

if (shExpMatch(host, "*.example.com")

Both two above will include, of course, "www.example.com" as hostname, but won't include just "example.com" ; in such a case: 

if (dnsDomainIs(host, "example.com") ||
  dnsDomainIs(host, ".example.com")

For a set of completely different domains, use the sample syntax above (using either "dnsDomainIs(host," or "shExpMatch(host," for your included hostnames) ...

FWIW, below is a PAC script I was using in ca. 2010 to access UK TV channels (BBC iPlayer, ITV, Ch4 and some UK radio stations owned by Bauer): 

function FindProxyForURL(url, host) {
  alert('url: \'' + url + '\', host: \'' + host + '\'');
  if (
    shExpMatch(host, "fig.bbc.co.uk") ||
    shExpMatch(url, "*.edgesuite.net/*") ||
    shExpMatch(url, "*.akamaized.net/*") ||
    shExpMatch(url, "*.bbcfmt.vo.llnwi.net/*") ||
    shExpMatch(url, "*.llnwd.net/*") ||
    shExpMatch(url, "*playlists.bbc.co.uk/*") ||
    shExpMatch(url, "*.bbc.co.uk/mediaselector/*") ||
    shExpMatch(host, "*.bidi.bbc.co.uk") ||
    shExpMatch(host, "*.bidi.live.bbc.co.uk") ||
    shExpMatch(url, "*ais.channel4.com/*") ||
    shExpMatch(url, "*mercury.itv.com/*") ||
    shExpMatch(url, "*mediaplayer.itv.com/flash/playlists/*") ||
    shExpMatch(url, "*magni.itv.com/*") ||
    shExpMatch(url, "*tx.whatson.com/*")
  ) {
    return "PROXY 86.25.218.xxx:3128";
  } else {
    return "DIRECT";
  }
}

BTW, it's totally worthless today, so, hopefully, I won't get in trouble by just posting it here  ; just a small note, though: 

shExpMatch(url, "*.bbc.co.uk/mediaselector/*") ||

At some point, Chromium and Firefox, for security/privacy reasons (  ), stopped supporting URL subdirectories inside the url RegExp syntax, so this filter isn't correct by recent PAC/browser standards  ...

On 5/21/2024 at 8:35 PM, Anbima said:

I have noticed that it sometimes causes problems if the website integrates external content that does not have SSL.
In this case, the external website must also be recorded.

... In those cases, the sites are serving mixed content (some over HTTPS and some over plain HTTP) and this is considered bad web practice today (e.g., recent Chrome will block the insecure content by default) - if the insecure content (HTTP) is being served on the page from a third party domain, I don't see where your problem lies ; if they're indeed serving mixed content from the same first party domain, then what "external website" are you talking about there?
In the last case, you could forward only the secure content over to ProxyMII via, e.g. 

if (shExpMatch(url, "https://*.example.com/*") ||

etc,, whereas non-secure content from "http://*.example.com/*" will be fetched directly through browser...

On 5/21/2024 at 8:35 PM, Anbima said:

Be aware and careful! Use a direct connection when you don't want any mistakes made.

Is the proxy not secure, or what does this mean?

... What he meant was that non-tech users should be extra careful how they install+configure HTTPSProxy (basically, the user custom rules inside its config.ini file), because any potential errors there may and will result in loss of connection for the client app (browser) ... 

If you do want to talk about security per se, you are running Windows XP, aren't you? ... And a browser (360EEv13.5) based on old Chromium core (86), aren't you? In the same vein, ProxyMII uses a deprecated CPython version and also deprecated Python modules (because their current versions aren't compatible with that older Python and/or XP itself) to achieve its functions, so do you get the drift  ?

On 5/22/2024 at 2:14 PM, Anbima said:

You have to register on the following page.
And this data would then be transmitted unprotected.
https://teccat.carparts-cat.com/

When I try the "legacy" login page, I'm redirected to a 
https://web1.carparts-cat.com/Login.aspx
page; as I said, under Vista SP2 32-bit, ALL appear correct vis-à-vis the secure connection: 

What does an XP SP3 x86 user see in the above scenario? FWIW, "http://web1.carparts-cat.com/" ALWAYS redirects to HTTPS here, so what makes one believe the connection succeeds but data is transferred unencrypted? 

Edited May 24 by VistaLover

[Anbima]

17 hours ago, VistaLover said:

What does an XP SP3 x86 user see in the above scenario? FWIW, "http://web1.carparts-cat.com/" ALWAYS redirects to HTTPS here, so what makes one believe the connection succeeds but data is transferred unencrypted? 

It looks like this for me:

 

[w2k4eva]

16 hours ago, Anbima said:

It looks like this for me:

Does your chrome360 include the root cert ISRG Root X2 ??? This could be as a root cert, or in the older case it used to be an intermediate cert cross signed by ISRG Root X1, which in turn could have been either a root itself, or cross signed by DST Root CA X3.

If that/those is missing you might have a problem...

it DOES appear to be properly encrypted, just to a root cert that itself is not trusted.

edit: you can download the cert from https://letsencrypt.org/certificates/

scroll down to "Root CAs", then "ISRG Root X2", then "Certificate details (self-signed)"

choose your format, since I do not use chrome360 I'm not sure whether it  prefers *.der or *.pem, someone on here who uses it can give better instructions on how to add it for your browser, or if it uses the system store

Edited May 25 by w2k4eva
add DL link

[Anbima]

6 hours ago, w2k4eva said:

it DOES appear to be properly encrypted, just to a root cert that itself is not trusted.

Does this mean that the data is transmitted encrypted?

I was told in another thread that it's because 360Chrome Elliptic Curve key algorithm certificates are not compatible:
https://msfn.org/board/topic/175170-root-certificates-and-revoked-certificates-for-windows-xp/page/41/

6 hours ago, w2k4eva said:

choose your format, since I do not use chrome360 I'm not sure whether it  prefers *.der or *.pem, someone on here who uses it can give better instructions on how to add it for your browser, or if it uses the system store

I've already done that too.
This is displayed for me at the intermediate certification bodies.

 

Maybe we can continue it in the other thread, where it fits better:
https://msfn.org/board/topic/175170-root-certificates-and-revoked-certificates-for-windows-xp/page/41/

Edited May 25 by Anbima

[w2k4eva]

5 hours ago, Anbima said:

Maybe we can continue it in the other thread

Seems this question could fit in any of 3 threads. Since the screenshots are already in this thread, I'll try here, though if forum admins ask and/or move the posts with screenshots I'll be happy to move there.

But looking more at your previous screen shot, leaves me more confused too, it gives conflicting information. On the heading "Insecure connection" it says "Your connection to web1.carparts-cat.com is not encrypted" but 2 sentences later says the connection is encrypted, plus the "security overview" thing has the 2 items of green text saying ""the connection to the site is encrypted" and "All resources on this page are served securely" ... rather contradictory. Does anyone have access to source code for chrome360 who can tell us what this combination of messages might actually mean?

Also from the previous screen shot, it says "Certificate - missing". Your second screen shot shows the ISRG Root X2 cert, but not as a root cert - that looks like the cross signed version (actually an intermediate cert, not a root cert), which depends on also having the X2 cert signed by the X1 cert. So, does your chrome360 have a root cert for ISRG Root X1 (probably listed on a different tab in the certificate manager, I don't really read German so can't suggest the tab title)?

Part of the confusion is that there are multiple versions of these certs, having the same names. That's why I mentioned "Certificate details (self-signed)", it seems you have the cross signed version.

If you need the X1 root cert, it can be downloaded from the same page I linked before (again, look for the "self signed" variant). So if that is present (as a root cert, it too has a cross signed intermediate form that would require yet another root cert that signed it), it might come down to whether chrome360 can handle the ECC type encryption, or if not, whether you can get the proxy to do that for you.

[Anbima]

I am also surprised that it shows unencrypted and encrypted. Hence my question.
X1 is listed among the trusted root certification authorities, even twice:

 

[w2k4eva]

7 hours ago, Anbima said:

X1 is listed among the trusted root certification authorities, even twice:

Okay... it looks like that should have covered it in terms of having the certs. So what is left is whether chrome360 can handle the certs it has. Which is a different question than whether they are missing. For the two X1 root certs, are they indeed the same? Or does one use ECC type encryption while the other uses RSA? You would need to examine both of those certs in detail to see that. Could you look at which certs that site is actually using, and check each one in the chain to see if they are using the possibly problematic ECC versions?

For some versions of some browsers, if a given website had multiple possible paths to chain to a trusted root cert, they would try the first path encountered and if that failed they would not try any of the other paths even if that would have worked if the first path tried had not been there. For that situation one would have to figure out the failing path and eliminate some certs so that path would not be possible, forcing the browser to use another path that would work. I do not know whether your version of chrome360 has this issue, or if eliminating such a duplicate path might help for your case.

Some other users are posting screenshots of such ECC certs working in XP with MyPal, is trying that an option for you?

Otherwise you are back to making the proxy handle it for chrome360, which does indeed belong in this thread.

[AstroSkipper]

@Anbima and @w2k4eva!

Any in-depth consideration of certificate issues in 360Chrome are browser-specific issues and are actually rather off-topic here. 

In any case, this here is not a 360Chrome browser thread.  Such issues should be discussed in one of the countless Arctifoxie 360Chrome threads. And just for clarification, this has happened several times there in the past, without any real solutions. 360Chrome 13.x had problems with certain sites and their certificates from the very first. This will never be solved as this ported browser has not been developed further for years. The only way to solve certificate problems in these browser versions is to use ProxHTTPSProxy. On some problematic sites, the Windows 2000 compatibility mode also helps to show the padlock and green, secure HTTPS connection under Windiws XP. I have tested all this myself, and it works. Or use a more modern Chrome browser in Windows XP as, for example, Thorium which does not show such issues! 

Edited May 27 by AstroSkipper
Update of content

[Anbima]

I have already done Windows 2000 compatibility mode.
It has always worked until now. But now there are pages that no longer work.

I have tested Thorium, but it runs very slowly on my system, so you can't work with it.
My system is too weak.

The green padlock wouldn't be so important to me if the data is still transmitted in encrypted form.
The screenshot shows that it is transmitted in encrypted form and then that it is not encrypted.

Which is correct?

[AstroSkipper]

Your comment is again offtopic.  Read carefully what I have written here:

7 hours ago, AstroSkipper said:

Any in-depth consideration of certificate issues in 360Chrome are browser-specific issues and are actually rather off-topic here. 

In any case, this here is not a 360Chrome browser thread.  Such issues should be discussed in one of the countless Arctifoxie 360Chrome threads. And just for clarification, this has happened several times there in the past, without any real solutions. 360Chrome 13.x had problems with certain sites and their certificates from the very first. This will never be solved as this ported browser has not been developed further for years.

No further discussions about 360Chrome issues in this thread. 
Post your 360Chrome issues in one of the corresponding Arctifoxie threads!  A solution has been provided for you here in detail. And that means use ProxHTTPSProxy! And thus, we are finally on-topic again! 

Edited May 27 by AstroSkipper
Update of content

[w2k4eva]

On 5/27/2024 at 7:06 AM, AstroSkipper said:

The only way to solve certificate problems in these browser versions is to use ProxHTTPSProxy.

Yes, this is my conclusion as well:

On 5/26/2024 at 8:06 PM, w2k4eva said:

you are back to making the proxy handle it for chrome360, which does indeed belong in this thread.