VistaLover

Well, the title of this thread (in the form of a question) is a tad misleading ; if the real question was Can you establish TLS 1.3 connections under Windows XP? then the answer, of course, is YES . Both UXP browsers (New Moon 28, Serpent 52.9.0), the Moebius fork (Serpent 55.0.0), the Tycho fork (New Moon 27) and probably other @roytam1's forks all support the final TLS 1.3 draft (RFC8446), as well as all three cipher suites associated with TLS 1.3: TLS_AES_128_GCM_SHA256 (0x1301) TLS_AES_256_GCM_SHA384 (0x1302) TLS_CHACHA20_POLY1305_SHA256 (0x1303) ; you can test TLS 1.3 support of these browsers with https://tls13.pinterjann.is/ https://swifttls.org/ https://cert-test.sandbox.google.com/ (and a few other test URLs...). BTW, the NSS library in these browsers was recently downgraded from v3.44 Beta to v3.43 stable release; perhaps @roytam1 could share a word (or two ...) why that was necessary ... Additionally, I was recently informed that the excellent project ProxHTTPSProxy by @heinoganda has indeed achieved TLS 1.3 support under XP for the type of browsers (IE8, Google Chrome 49 and, possibly, earlier) that don't come with their own TLS support but rely upon system libraries for secure connections; so TLS 1.3 in itself shouldn't be an issue... But what is indeed specific is the configuration of linked test server, https://tls13.1d.pw/ It is no coincidence that a Russian member of this forum brought this up, because, it turns out that, the administrator of said test server is a Russian guy, Александр Венедюхин ! In fact, he maintains a blog where he documents this project and the TLS 1.3 test configuration of the server; original articles can be found at: https://dxdt.ru/2018/08/05/8597/ https://dxdt.ru/2019/01/26/8672/ As I'm not at all fluent in Russian (), I had to enlist the help of (evil ) Google, but what the heck... : https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ I don't consider myself proficient in the field of cryptography and/or secure connections, but what I gathered from the translated text was that the server is configured to send a special HelloRetryRequest response to force a renegotiation of connection parameters; the implementation of Encrypted Server Name Indication (ESNI) along with non-ECDH manifested a bug in Mozilla's NSS library, so that is probably why the Firefox forks won't connect currently to that specific test server! (they yield a SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code ). Hopefully, the reported bug will be fixed in a future NSS version, if/when that is applied to UXP, we'll have successful connection in the UXP forks... Frankly, TLS 1.2 is still predominant, but with 1.3 steadily gaining ground; this specific connection test is but a margin case where 1.3 is involved, so I won't be losing any sleep over it...

IIRC, that was because Oracle decided they would no longer support the 32-bit OS architecture on JRE 9 and higher http://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-59701F80-5BB1-416D-835D-C39A9112FC1E

The latest version of Qihu's 360 Extreme Explorer (v11.0.2086.0, released May 16th 2019 - its default UA declares a Chromium 69.0.3497.100 compatibility ) will also pass the test : But this is on Windows Vista SP2 32-bit, not on XP SP3 32-bit (hence, one of you XP users would have to test... ) EDIT: Make sure in "flags" that chrome://flags/#tls13-variant is set to "Enabled (Final)"

Latest FileZilla 3.42.1 32-bit won't launch under Vista SP2 because of only one missing function in Vista's shell32.dll system file: ... and, actually, the very last Vista SP2 compatible version of FileZilla is 3.40.0-rc2, released on Jan 22nd 2019: You can download this Vista EoS version from the official repository at https://download.filezilla-project.org/client/ Final 3.40.0 was released three days later (Jan 25th 2019) but, as you've found out, it would run only on Win7+ FileZilla is open source, so perhaps one could recompile more recent source code to again target at least NT 6.0; here's hoping

This is most probably caused by the fact 4.6.2 Preview can be properly installed via the provided installer, while 4.6.2 Final can only be installed via a hack-ish way ; it is possible running just the .MSI (in the unpacked original setup) does not write all of the necessary registry keys and/or modify ENV VARs; most sadly, I'm not a coder so can't provide any substantial help, but googling the issue I found: https://stackoverflow.com/questions/5980847/visual-studio-2010-startup-type-initializer-for-module-threw-an-exception https://blogs.msdn.microsoft.com/rajakedar_ganta/2012/06/12/the-type-initializer-for-module-threw-an-exception/ Hope they make sense to you! Regards

... But I did say I stopped updating manually at the end of October 2017; also, some previous 4.6.1 updates were not included in my "Snipping Tool" screengrab (I would need to scroll down and take a second one to include all installed in chronological order.) ...

@Blados, @artomberus The best approach on (manually) updating a (manual) install of .NET FW 4.6.1/4.6.2/4.7.0/4.7.1/4.7.2 on Vista SP2 is to have access to a Windows 7 machine, where the exact .NET FW version is manually installed; you should then let WU check for .NET FW related updates and selectively hide upgrades to a higher version, if it's not what you have on the Vista machine (e.g. I understand that on Win7, MS will offer to upgrade you to 4.7.2 (4.8 maybe?) if you've got a previous version installed). Install only the patches offered for the .NET FW version you're interested in, then head to Control Panel => Installed Updates (for .NET FW) and write down the KB numbers of these patches. Track them down in MUC and then proceed to manually install on the Vista machine! My sister has a Win7SP1 x64 laptop, where I "froze" .NET FW to v4.6.1 and, to make a long story short, that was how I was updating my own 4.6.1 install on Vista!

4.7.2 belongs to the 4.7 family of .NET FW versions, comprising 4.7.0, 4.7.1 and 4.7.2; of course, 4.7 family isn't supported on WS2008SP2 (NT 6.0) , so, presumably, Microsoft don't test produced patch files on 4.7.x installed on WS2008SP2... However, Win7 SP1 is supported; it just so happens that the update mechanism of 4.7.x on Win7SP1 is similar to the one of patching 4.6.x under WS2008SP2, so that is why what @WinClient5270 stated above is correct To illustrate: By visiting Microsoft Update Catalog, latest updates for 4.7.2 on Win7 SP1 include, e.g. 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, and 4.7.2 for Windows 7 (KB 4495588) When you proceed to download, you are presented with file ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe Notice the ndp46-* prefix? This is exactly the same file you'd end up with if you wanted to fetch latest patch for 4.6 on WS2008SP2: 2019-05 Security and Quality Rollup for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495588) (Please also load and inspect https://www.catalog.update.microsoft.com/Search.aspx?q=KB4495588 ) On Win8+, the update mechanism of 4.7.x is different to both WS2008/Win7; there, the patches are being delivered in the form of "Windows" updates, i.e. .msu packages... 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 8.1 (KB4495585) => windows8.1-kb4495585-x86_14b43821fa547611902f85baac67e8f013c40613.msu So, we should really thank Windows 7 in this case!

If it was file dotnet-hosting-2.2.5-win.exe that you downloaded (96.3 MiB), you shouldn't have used 7-zip to unpack, but more specialised applications like Bioruebe's Universal Extractor 2 Result of extraction: I personally feel there's no way this would work under Vista, I merely wanted to point out what else to try when 7-zip fails to yield desired results...

api-ms-win-core-console-l1-1-0.dll (the module that couldn't be found and caused System.IO.FileNotFoundException) is actually part of KB2999226, aka Windows 10 Universal C Runtime (Win10UCRT), which itself is a prerequisite for Microsoft Visual C++ 2015+ on Vista SP2. Please install latest redistributable for MSVC2019 found here: https://visualstudio.microsoft.com/downloads/ (scroll down all the way to "Other Tools and Frameworks", expand, "Microsoft Visual C++ Redistributable for Visual Studio 2019", download files for both 32-bit & 64-bit and install; Windows6.0-KB2999226-x86.msu is included and will be co-installed if not found in the system). The only way to be definitive about that is if you inspect executables (*.exe & *.dll) with Dependency Walker (please do so after you've installed MSVC2019)

@UCyborg: many thanks indeed for your very erudite comment , am always keen to learn new things...

On their site (you linked to) they state: Do you reckon 7's SP1 + PU are just for .NET FW 4.7.2 compatibility reasons?

Neither could I , but here is some more test material: ShadowSocks is an application very popular in China, because it can be used to connect to specialised servers outside of the GFW and thus circumvent regime implemented censorship ; the windows binary is built on .NET Framework 4.x.x; the last executable that could be launched under Vista SP2 with 4.6.1 (Final) installed is v3.3.4 all the way back from Oct 2016 ; any more recent version will throw an error: Unlike ShareX, Shadowsocks.exe does not come with a *.config file we can patch, you do have to have 4.6.2+ installed to make it launch! In their Wiki it's noted (in Chinese) that .NET FW 4.6.2 is the minimum version required, along with latest Visual C++ 2015 Redistributable; also in their wiki they suggest So I think shadowsocks should be a perfect "test-bed" application for correctly functioning .NET FW 4.6.2/4.7.2[4.8.0?] under Vista SP2... People here with Vista SP2 VMs, the challenge is open!

armagaddon-2.0 bug (and fix) has to do with SIGNED extensions; uBlock-firefox-legacy-1.16.4.10 (from GitHub) is an UNSIGNED extension; to install it on FxESR 52.9.0[1], one must first flip (in about:config) xpinstall.signatures.required to false, restart the browser and then attempt to install; to remove warnings generated by installed unsigned extensions, read previous post in this page...

... As it finally turned out, it is yet again another case of intentional/artificial block of Vista by M$ ; the blocking code lies somewhere inside the compiled .EXE setup, but it's obviously absent in the unpacked .MSI installer.I do wonder if it's still possible to install 4.6.2 Final by running the Setup.exe file (86.1KB) that exists inside the (unpacked) directory; an inspection with Resource Hacker reveals it does indeed support Vista in its manifest: <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" /> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" /> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" /> </application> </compatibility> I guess if that doesn't work, on a 32-bit platform one should run netfx_Full_x86.msi (in the unpacked directory); as mentioned by Osman, in the root of the unpacked setup one can see prerequisite windows updates for Win8 (KB3151804), Win8.1 (KB3151864) and Win10 (KB3151900), but, surprisingly, not for Win7 (and, of course, none for WinVista, which the package doesn't officially support) - in any case, it should be stressed that the (somewhat unorthodox) 4.6.2 install shouldn't be attempted on a Vista system which isn't fully updated (SP1+SP2+all subsequent updates at least until EoS on April 2017), just for good measure... All in all, a very positive outcome from a joint effort, started by @Osman Kovan and joyfully concluded by @WinClient5270! Cheers PS: I couldn't help noticing how a 59.1 MiB file (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) blows up to more than 1.62 GiB (!) when expanded!

... Is there any specific reason you had not upgraded to the more secure 52.9.0esr version? 52.9.0esr is the last 52ESR build to have been officially released (and, of course, the last version of Firefox that would support XP/Vista), there shouldn't be any compatibility issues (extensions-wise or other) between what you now have (52.6.0esr) and the last of its breed, 52.9.0esr... Have you disabled application updates in Firefox? I was under the impression 52.6.0esr would auto-update to 52.9.0esr Best regards

You have (what I call) an "obsession" we've already witnessed in other threads to falsely report to all sites you're running Firefox 66, instead of adopting the default user agent of FirefoxESR 52.9.0[1] and only spoof that on sites broken in FxESR 52 (and I recollect @Mathwiz and possibly others advising you towards that direction ). Once again you fell prey to your "obsession"; the suitable "fix" you should install from AMO is found on https://addons.mozilla.org/el/firefox/addon/disabled-add-on-fix-52-56/ But if you pretend to be running Fx 66, AMO will think you are running Quantum (yes, Firefox 66.0 is of the Quantum "variety") and forbid you access to what it thinks is an incompatible extension! Please, for one last time, STOP this practice of adopting a global UA string of Fx 66.0 (sent to all sites) and return to the default value that comes with your actual browser; currently only few sites will nag you about Fx52 being outdated, use SSUAO just for these...

KB956250 was installed in my system through WU on June 23rd 2010; of course, Final 4.6.2 still refuses to install, as with the rest of Vista SP2 users From your findings, it looks that KB956250 is a prerequisite to 4.6.2 Preview under NT 6.0 (Vista+WS2008), but it isn't included anymore in the 4.6.2 Final setup, since that one has moved on to target NT 6.1+ İyi akşamlar

1.16.20 (probably installed from GitHub) is UNSIGNED; as such, it can only be installed while in Developer Mode and yes, stable Chrome branch will alert you about this at every browser (re-)launch You should have been stuck at the signed version 1.16.18 on Chrome 49; BTW, 1.16.18=1.16.20 for Chromium based browsers; please read following post: Export first your 1.16.20 settings to a file, then uninstall 1.16.20, manually install 1.16.18 (by dropping onto chrome://extensions) and then manually re-import your previous settings; have done this many times, it just WORKS!

I agree that the management of already installed Search Engines can be performed quite fine by New Moon's native functions/tools; using the extension I mentioned comes very handy in the cases one wants to add a rather obscure search engine not to be found on the official PM Search Plugins page that you linked to, or when a page does not provide an easy way to add its search among the browser's Search Engines set... E.g. with "Add to Search Bar" I can easily add our own forum's search utility, or BBC iPlayer's, etc : The extension itself appears to be using minimal resources: (via about:addons-memory, extension to be found on GitHub)

... Yes, that is indeed the case - it appears that all three 4.6.x flavours (4.6.0 [final], 4.6.1 [final], 4.6.2 [final]) are being patched by the same .exe files! I can only speculate, but, as feared, the 4.6.2 Preview has an internal version number different to the stable/final release of 4.6.2, which renders it not eligible for further 4.6.x patches (that is if the patch files check for some sort of version ID of the installed 4.6.x package); in fact, inspecting the setup files, one sees: 4.6.2 Preview setup: NDP462-KB3120735-x86-x64-AllOS-ENU.exe => File version 4.6.1532.0 4.6.2 (Final) setup: NDP462-KB3151800-x86-x64-AllOS-ENU.exe => File version 4.6.1590.0 Of course, the real puzzle here is what was actually changed by MS so that 4.6.1532.0 installs under Vista SP2, but 4.6.1590.0 doesn't ; is it just an artificial block for NT < 6.1 ? So, the prudent thing here is to stay on Final 4.6.1, for which compatible Security and Performance Updates are being rolled-out by MS and which can be manually downloaded (& installed) from their Update Catalog . Let me, once more, thank you immensely for your precious time spent conducting those tests for me (and, of course, other Vista users); I have a 12 year old low-end Vista laptop (and the OS has already started kicking the bucket last February ), no VM software installed (and my total RAM is only 3 GB), so no practical way I could test myself - I would also hate to lose 4.6.1 and all its manually applied updates for the sake of testing the 4.6.2 Preview - I hope you understand... )

... Yes, that is indeed true if you have 4.6.0 installed and you expect to receive updates via Windows Update With 4.6.1 (manually) installed, I have always found that the updates for 4.6 made for WS2008SP2 would still apply to 4.6.1, too: (around November 2017 I stopped manually patching my OS, but that's a different story... ) Yes, you shouldn't be trying to install a Win7 specific .NET FW 4.6.x update, but its WS2008SP2 counterpart; the actual "payload" should be the same; from Microsoft Update Catalog: 1. 2019-05 Security and Quality Rollup for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495588) => ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe vs. 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 7 (KB4495588) => ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe 2. 2019-05 Security Only Update for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495587) => ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe vs. 2019-05 Security Only Update for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 7 (KB4495587) => ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe Are you able to spot that the corresponding KB numbers are identical and that, when clicking the download button (a pop-up window appears with content to fetch), you are presented with identical .exe binaries for either W7/WS2008SP2 ? My gut feeling is (based on experience) that e.g. file "ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe" will apply successfully to a 4.6.1 32-bit install under Vista SP2 x86; when your spare time permits, can you please test this hypothesis in your Vista SP2 VM (I understand it's 64-bit, so perhaps you need 4.6.1 64-bit and the 64-bit equivalent of ndp46-kb4495587-*.exe) ??? If you indeed tried to apply "ndp46-kb4495588-x64_cd387e77d1f73443776c35dd9cfa8f5581b93277.exe" on a 4.6.2 Preview 64-bit installation and failed (as pictured), then my suspicions are confounded; the "Preview" can't be patched (but "Final" 4.6.1 should be)

The first Firefox Quantum version in the release (stable) channel was v57.0; 60.0esr was the first Quantum version in the ESR branch (update channel); latest ESR build is now 60.6.3esr, to be soon followed by 60.7.0esr (currently in the "candidates" stage) ...

According to this, latest version is v1.5 Rev 3c; sadly, I haven't been following very closely the progress of that project lately, but was under the impression it could only go as far as TLS 1.2; @heinoganda, would you be so kind as to verify that actual support for TLS 1.3 Final has been indeed achieved? Best wishes and congratulations for your efforts

... Actually, this statement is not entirely accurate; the site does indeed support TLS protocol versions down to even v1.0: https://www.ssllabs.com/ssltest/analyze.html?d=comedonchisciotte.org&s=104.24.109.160 However, adding TLS 1.2 protocol support to an OS (XP in this case) is one thing, but adding support for needed Cypher Suites to match that protocol is, sadly, another thing! If you inspect closely the supported cypher suites for even TLS 1.0 (natively supported in XP's IE8), you'll see that only Elliptic Curve (ECDHE) Suites are accepted by that site, but, unfortunately, ECC is NOT supported under Windows XP, thus the secure connection can't be established! Under Vista SP2, I have also enabled TLS 1.2 protocol in IE9 (via a set of MS updates - Server 2008 intended - and hacks similar to those available under XP) and there IE9 has no issues connecting with TLS 1.2: FWIW, it even connects with plain TLS 1.0 (when I manually disable 1.1 & 1.2): So, in this specific case, it's all about the OS, not the protocol only...