View Single Post
  #12  
Old January 5th 20, 04:09 PM posted to microsoft.public.windowsxp.general,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows XP Update

Mayayana wrote:
"Paul" wrote

| a) Sure, it supports TLS 1.2 or TLS 1.3. Great.
| It would be nice to verify this, but the "ssllabs"
| site refused to work with the adulterated browser.
|
| b) A crypto algorithm has to go with the overall protocol.
| Microsoft liked their 40 bit and 128 bit methods a bit
| too much. 3DES is no longer recommended. You need stronger stuff.
| The SChannel update, it's Microsoft policy to "not improve things".
| They can't be adding CHACHA20 or the elliptic curve
| exxxxx item to the Schannel. Leaving the crusty old RSA
| entries and the like, is more their speed.
|

I don't know which is which with these, but are the
things you're talking about really necessary? The patch
is for support for TLS 1.1 and 1.2 on XP embedded. Why
would they offer that to businesses but not make it worth
having?

My own software that uses winhttp.dll couldn't use
TLS1.2 but does seem to use it fine with the patch
and Registry settings. (I haven't added the settings
LuWei is using. As far as I can tell those are designed
to allow one to disable a protocol.
As far as I can tell, only these are needed, and actually
the server settings shouldn't be:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]
"Installed"=dword:00000001

Interestingly, with my own software it was working fine to call
the Bing maps server but then I started getting certificate errors.
Assuming MS, like so many people, had let their cert lapse, I disabled
cert checks by default. Then it worked fine. But in my explorations
related to Unbound I came across a way to update certs. That
seems to work. I no longer have cert errors calling Bing maps
server over https, using TLS 1.2, through winhttp.dll.

I can't speak for IE8. I don't see any reason to do any of
this except to support better security in software (that wants
to use it) that depends on wininet.dll or winhttp.dll. What
kind of nut would use IE8 online when they can have FF,
New Moon, Pale Moon, etc?
I did try Acrylic with DoH after jumping through all the IE8
hoops because Acrylic is using wininet.dll. It didn't work. But
I can't tell why it didn't work. Acrylic? The update? My Acrylic
config? I gave up on that for now.

Certs update:
https://msfn.org/board/topic/175170-...or-windows-xp/

(The rundll business shouldn't be necessary. Just download
the two packages, update the SST files, and then run the
INF files.)


This is what I used, merging this in after the rest
of the updating was done.

IE8_TLS.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2]
"OSVersion"=-

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1]
"OSVersion"=-

[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet Settings]
"SecureProtocols"=dword:00000a80
"ShowPunycode"=dword:00000000
"EnablePunycode"=dword:00000001
"DisableIDNPrompt"=dword:00000000
"CertificateRevocation"=dword:00000000
"WarnOnPostRedirect"=dword:00000001
"WarnonBadCertRecving"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet Settings\Protocols\Mailto]
"UTF8Encoding"=dword:00000000

I would have blended in more crap, except without
feedback as to how much this improves things, I lack
the motivation to try yet more random things.

If the project felt like it was going places,
I'd have given it more of a chance.

*******

I put this in, to make the particular catalog.update.microsoft.com
download execute and install. Without this, the particular IE8 cumulative
wouldn't run (blocked by "OS check").

HKLM\SYSTEM\WPA\PosReady === New key
Installed DWORD 1 === New DWORD value

Putting that in, as far as I know, I was part of the
administrator group. But when I tried to remove it,
the XPMUser account could not remove it, I elevated
to SYSTEM using psexec and that didn't work either.
The only level left in my collection is TrustedInstaller,
and I wasn't going to bother with testing that.

Using the Kaspersky rescue CD (offline AV scanner),
it has a registry editor written for Linux that
edits some but not all registry files. But that
wasn't booting within Windows Virtual PC for some
reason. All I could see is the checksum error when
the SB16 virtual soundcard is probed, and there
were no further messages before it reset. While Kaspersky
claims that registry editor is open source, I haven't
located source for it elsewhere (to put it on some
other Linux disk or environment).

The Registry is a file system, and the entries have
permissions, and doing it from Linux, the expectation
is the permissions will be ignored.

If you leave the PosReady key, it just means that
Windows Update lists a lot of stuff that may or may
not be appropriate as a patch. Just as some newer
OS versions list patches intended for the Server
version, but matching on the consumer OS.

Paul
Ads