Jump to content

TLS 1.3 in Win'XP SP3 possible?

Bersaglio

By Bersaglio
in Windows XP

 Share

Recommended Posts


VistaLover

VistaLover

Posted
Posted (edited)

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 :whistle: ) will also pass the test :thumbup:

OZP54Zy.jpg

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)" :yes:

Edited by VistaLover
5
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted (edited)

Well, the title of this thread (in the form of a question) is a tad misleading :huh:; if the real question was

Can you establish TLS 1.3 connections under Windows XP?

then the answer, of course, is YES :thumbup. 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 :dubbio:...

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 (:lol:), I had to enlist the help of (evil :angry:) 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... :P

 

Edited by VistaLover
4
Link to comment
Share on other sites
roytam1

roytam1

Posted
Posted
5 hours ago, VistaLover said:

(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 :dubbio:...

because it crashes.

1
Link to comment
Share on other sites
Bersaglio

Bersaglio

Posted
  • Author
Posted (edited)

@VistaLover

Thanks for the info, just checked 360 Extreme Explorer 11.0.2086.0 (Chrome 69) on the XP SP3 virtual machine and TLS 1.3 passes the test via specified test server. But sadly it is not an option for me because I never trust Chinese browsers due to privacy concerns... :(

15 hours ago, VistaLover said:

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, Александр Венедюхин !

This is not correct. I used official Mozilla test server https://tls13.crypto.mozilla.org/

until it was taken down without any warnings or explanations. Then I started looking for a similar test server and found one linked in the first message of this topic. I didn't even know who is the administrator of this server, but its domain name doesn't look related to Russian Internet segment.

Edited by Bersaglio
typo
1
Link to comment
Share on other sites
Mathwiz

Mathwiz

Posted
Posted (edited)
15 hours ago, VistaLover said:

BTW, the NSS library in these browsers was recently downgraded from v3.44 Beta to v3.43 stable release;

Doesn't seem to matter though. @roytam1 rolled back to 3.43 in the 2019.04.27 builds due to the 64-bit version of NM 27 crashing on startup, so I downloaded the Serpent 52.9.2019.04.19 build, which AIUI has an earlier NSS v3.44b, to test with; unfortunately it still fails to open https://tls13.1d.pw with the SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code. :( That version does open the other TLS 1.3 test sites just fine though.

Edit: By the way it looks like NSS v3.44 is stable as of May 10, but I have no idea whether the issue causing NM 27 to crash was fixed at the last minute.

Edited by Mathwiz
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted (edited)
8 hours ago, Mathwiz said:

@roytam1 rolled back to 3.43 in the 2019.04.27 builds due to the 64-bit version of NM 27 crashing on startup,

... This doesn't add up; the New Moon 27 64-bit crash was first reported by @mockingbird in the following post:

The crash was indeed due to module nss3.dll, but the reporter specifically mentioned package:  

https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190427-a09f31062-xpmod.7z

as the one the crash occurs with... :dubbio:As you said, that build is the one where the NSS lib downgrade took place,

https://github.com/roytam1/palemoon27/commit/a09a17de63be6e059e60559e15cca3448d362428

but still that 64-bit build would crash for the reporter... Furthermore, @roytam1's fix for that crash was announced here:

soon after the 2019-05-10 New Moon 27.9.6 builds were announced; @mockingbird verified the fix:

... But looking at the posted changelog for these builds, I don't see a change in the NSS lib version, which I assume still remained at 3.43 (final), the same one inside the crashing build of 2019-04-27 ; am I missing something obvious here?

Edited by VistaLover
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted
7 hours ago, Mathwiz said:
23 hours ago, VistaLover said:

BTW, the NSS library in these browsers was recently downgraded from v3.44 Beta to v3.43 stable release;

Doesn't seem to matter though.

I never claimed (or implied) that staying at NSS 3.44 Beta (instead or reverting to 3.43 Stable) would have allowed for the UXP browsers to successfully connect to the linked test server, i.e. https://tls13.1d.pw
As I was already talking about the NSS library, I simply found an opportunity to mention the version downgrade I had observed; just that ... :)

23 hours ago, VistaLover said:

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...

7 hours ago, Mathwiz said:

unfortunately it still fails to open https://tls13.1d.pw with the SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code. :( That version does open the other TLS 1.3 test sites just fine though.

On 5/20/2019 at 3:44 PM, roytam1 said:

only chrome 70 or above can connect to it. https://www.ssllabs.com/ssltest/analyze.html?d=tls13.1d.pw

Today I borrowed briefly sister's Windows 7 SP1 64-bit laptop, where I updated stable Firefox (Quantum) to latest release 67.0 and Firefox ESR (Quantum) to latest release 60.7.0; to my great astonishment, both these Firefox versions connect successfully to the TLS 1.3 test server being discussed in this very thread; I dug around and found v60.7.0 comes with NSS 3.36.7, while v67.0 comes with NSS 3.43, the same one to be found inside the latest UXP forks released by Roy; so, despite my initial assessment, the "bug" observed here ("SSL_ERROR_RX_MALFORMED_SERVER_HELLO" error code when trying to connect to test server with latest New Moon 28/Serpent 52.9.0) doesn't appear to be only dependent on used NSS version and has been already fixed in latest Firefox Quantum releases!

I persevered with my searches and, in the end, I stumbled upon a similar issue that was also affecting the Waterfox fork:

https://github.com/MrAlex94/Waterfox/issues/783#issuecomment-458907249

So it looks as though the proper fix for this issue lies inside Bugzilla bug #1430268 fixed in mercurial commit:

https://hg.mozilla.org/mozilla-central/rev/fafb731

@roytam1: Do you think you can somehow backport bug #1430268
to the UXP platform and thus apply it to both NM28/St52? Is a test-build even possible? If yes, then the OP (@Bersaglio) won't have to use a Chinese browser to connect with... ;)

OT: I don't mistrust myself the Chinese browsers any more than I do American ones like Google Chrome or Russian ones like Yandex Browser; all government security agencies are pretty much the same in my eyes... :(; in this day and age, there's no such thing as privacy if you decide to connect to the live web... :realmad:

2
Link to comment
Share on other sites
Mathwiz

Mathwiz

Posted
Posted
58 minutes ago, VistaLover said:

the reporter specifically mentioned package:  

https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190427-a09f31062-xpmod.7z

as the one the crash occurs with... :dubbio:As you said, that build is the one where the NSS lib downgrade took place

Yes; I think what happened (@Roytam1 can either confirm or correct me) is that after the crash was reported @roytam1 reverted to NSS 3.43 and re-uploaded the 20190427 builds. Thus I think all NM 27 builds on his Web site are crash-free.

I think both the original 20190427 and the previous 20190419 builds were based on beta builds of NSS 3.44, but there were changes between the two; presumably one of those changes accounted for the NM 27 crash.

Link to comment
Share on other sites
Mathwiz

Mathwiz

Posted
Posted
1 minute ago, VistaLover said:

I never claimed (or implied) that staying at NSS 3.44 Beta (instead or reverting to 3.43 Stable) would have allowed for the UXP browsers to successfully connect to the linked test server, i.e. https://tls13.1d.pw

Didn't mean to imply otherwise. But I figured it was worth a try anyway....

Link to comment
Share on other sites
roytam1

roytam1

Posted
Posted
7 hours ago, VistaLover said:

@roytam1: Do you think you can somehow backport bug #1430268
to the UXP platform and thus apply it to both NM28/St52? Is a test-build even possible? If yes, then the OP (@Bersaglio) won't have to use a Chinese browser to connect with... ;)

seems possible, will have a look later.

1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...