Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Ninho

Problems accessing certain sites (Https aka TLS)

Recommended Posts

1 hour ago, jaclaz said:

:thumbup Which was what the OP was told initially, but decided to ignore ... :whistle:

Not at all. The question is whether it's possible to fix XP's native crypto libraries in order to accept the ECC (or whatever fancy) certs, not whether non-native crypto such as in Qtweb, Opera-Presto support them. The OP even asserted Firefox on XP does support the otherwise offending certs - which you decided to ignore :=)

In addition, what Heinoganda said and you quoted here is in doubt:«The actual problem is the Windows XP no ECC certificates can be administrated or not registered and these are recognized as invalid.»

This was certainly true of XP until SP2, but... isn't native support for ECC crypto one of the touted addidtions in XP-SP3 ? I guess it's more subtle than support versus no-support, the issue may be one of incomplete/buggy support for some flavor of ECC...

Off-topic rant : why are ECC-based certs seemingly gaining wider use ? Of course they sport smaller key-lengths, but ISTM their security against progress in cryptanalysis is even less assured than RSA, whose mathematics are much better understood.

Edited by Ninho
added remark/question about ECC crypto and XP-SP3

Share this post


Link to post
Share on other sites

Do not hold much ECC-based certificates (the NSA has helped in the development), but it is of no use if the access to web pages is dealt with. Here should first find a solution that also Windows XP with these can deal. Afterwards it can then be thought about further implantations like TLS 1.2 et cetera (With the IE8 I definitely no longer on the Internet).

:)

Share this post


Link to post
Share on other sites

@Ninho

Look :), as I see it, the issue with that specific site should be connected with ECC (and NOT with TLS 1.2).

It would have probably cost you nothing (or next to nothing) doing the tests I suggested to make sure that my (educated) guess was right (or utterly wrong), instead you just ignored it (which is entirely OK, of course).

I should know better than attempting to help people that know more than I do, my bad :(.


 

jaclaz


 

Forrestreversedisappear_version1.gif

Share this post


Link to post
Share on other sites
6 hours ago, heinoganda said:

The problem is not TLS 1.2, which is supported on Google Chrome, as well as ECC certificates. The actual problem is the Windows XP no ECC certificates can be administrated or not registered and these are recognized as invalid.

:)

It's true that the problem connecting to www.aidanwoods.com isn't TLS 1.2. Www.aidanwoods.com supports TLS 1.0, and according to ssllabs.com it will connect using TLS 1.0 to IE 7 (!) on Vista. Apparently that site does support one cipher suite which is compatible with TLS 1.0, so I no longer think TLS 1.2 will help connect to it.

And ssllabs.com reports that even Chrome 49 won't connect to that site on XP. The only cipher suites supported by www.aidanwoods.com use elliptic curve cryptography for key exchange, and stock XP doesn't support ECC.

(To see what www.aidanwoods.com will and won't connect to, you can go to https://www.ssllabs.com/ssltest/ and enter www.aidanwoods.com. Takes a few minutes to run all the tests.)

MbedTLS.dll does support ECC, however, which is why I suggested the ReactOS schannel.dll: it was originally the Wine version of schannel.dll but was rewritten use MbedTLS.dll for its cryptography functions. So there was at least a chance it would work. But apparently additional .dll's are needed for full ECC support.

Sorry it didn't work out; nevertheless, it would still be useful to get native TLS 1.2 support on XP. (Sfor, for example, has a need for TLS 1.2 support for some of his software.) So I still plan to investigate.
 

Share this post


Link to post
Share on other sites

@Jacklaz : I don't know where you got this idea that I ignored your suggestions nor thought I "knew more than you", God forbid ! But I was not going to (re)install the QTweb or Opera 12 just for a check at most peripheral to the question...  Happy new year !

Share this post


Link to post
Share on other sites
17 minutes ago, Ninho said:

@Jacklaz : I don't know where you got this idea that I ignored your suggestions nor thought I "knew more than you", God forbid ! But I was not going to (re)install the QTweb or Opera 12 just for a check at most peripheral to the question...  Happy new year !

You posted about a problem.

I attempted to have you test if the problem had Cause #1 (TLS as you thought and hinted in the title) or Cause #2 (ECC as I believed).

The cause is seemingly #2.

TLS != ECC

https://support.globalsign.com/customer/portal/articles/1995283-ecc-compatibility

Happy New Year!

jaclaz


 

Share this post


Link to post
Share on other sites




 

3 hours ago, Ninho said:

[/I]sn't native support for ECC crypto one of the touted addidtions in XP-SP3? I guess it's more subtle than support versus no-support, the issue may be one of incomplete/buggy support for some flavor of ECC...

Off-topic rant : why are ECC-based certs seemingly gaining wider use ? Of course they sport smaller key-lengths, but ISTM their security against progress in cryptanalysis is even less assured than RSA, whose mathematics are much better understood.

 

I'll try to explain, but it's going to be a long post.

My understanding is that SP3 (plus post-SP3 POSReady '09 updates) added support for AES, not ECC. The AES cipher was an important addition, because all the other supported ciphers are now known to have weaknesses. But there are two parts to TLS encryption: the cipher itself, and the key exchange algorithm. (The combination is called the cipher suite. Actually there's a third part: the hash algorithm used for digital signatures, but I'll ignore that for now.) The cipher is used to encrypt and decrypt the data being transmitted, but the key exchange algorithm is needed so that a randomly-generated cipher key can be shared between the client and server secretly.

The traditional key exchange algorithm used in SSL and TLS is based on the RSA public-key cryptography algorithm. But the Snowden revelations showed there was a weakness in RSA: an eavesdropper (whether the NSA or just some hacker group) could record all encrypted traffic with a given server, then, if they were later able to steal or extort the server's private key, they could go back and figure out all the different random keys that were used, and therefore could decrypt all the prerecorded traffic.

As a result, sites have been switching to a different key exchange algorithm called "Diffie-Hellman Ephemeral." With this algorithm, even if an eavesdropper steals a server's private key, they can't go back and decrypt any prerecorded encrypted traffic. The best they can do is a man-in-the-middle attack to decrypt future encrypted traffic.

The only problem with the DHE algorithm is that it takes a lot of server CPU, unless elliptic-curve cryptography is used. So sites have been switching to "ECDHE" for performance reasons. (Personally, I think most sites should still support RSA as a fall-back for those of us with older software; as long as we're aware of the risk. But that's just me.)

AFAIK the latest schannel.dll added support for the AES cipher but didn't add any new ECC key exchange algorithms, so it only has half of what's needed to connect to www.aidanwoods.com. I was hoping the ReactOS schannel.dll would add the other half, as explained above. I really didn't mean to open such a huge can of worms, though! But I'll keep working on it, on my own; maybe I'll eventually come up with something, maybe not.
 Oh, man; sorry about all those italics! I was just trying to put a bracketed "I" in the quote, and the forum software thought I wanted everything in italics :o

Edited by Mathwiz
  • Upvote 1

Share this post


Link to post
Share on other sites

@Mathwiz

The root certificate updates are also supplied with ECC certificates, which are not included in the certificate management for Windows XP. At this point should be set up first, especially since more and more virus scanners (known to me at Avast and Kaspersky) initiate a cross-check of the certificates with the result that even with Firefox web pages with ECC encryption are blocked. Download the file updroots.sst from the root certificates, just open it and look for an ECC certificate (for example COMODO ECC Certification Authority), double click and invalid. Any attempt to install this failed.

:)

Edited by heinoganda

Share this post


Link to post
Share on other sites

I see; but in the absence of such AV products, doesn't the lack of a trusted root cert. normally cause the browser to only pop up a warning (the site's identity cannot be confirmed; you may be getting MITM'ed; proceed at your own risk, etc.), which can be ignored?
 

Share this post


Link to post
Share on other sites

@Mathwiz

No, that is another problem, with the virus scanner from Avast or Kaspersky, the network traffic to the web browser is actively checked (something like an intermediary proxy) and here there is no question but the website is locked, which can not be opened except the active certificate check Is switched off in the virus scanner. According to the motto what MS does not have appropriate root certificates, then Firefox can not open even though he can.

:)

Edited by heinoganda

Share this post


Link to post
Share on other sites

OK, but in post #1, Ninho said the site would open in FF (which supports ECC and has its own trusted root certificate store). So either he isn't using a virus scanner with an "Active Certificate Check" feature, or that feature is turned off.

I should've asked Ninho what error he gets in Chrome 34! (IE 8 is no help; it just says "Cannot connect to the site." Duh.) But Chrome's error might give us a clue.

Share this post


Link to post
Share on other sites
19 minutes ago, Mathwiz said:

OK, but in post #1, Ninho said the site would open in FF (which supports ECC and has its own trusted root certificate store). So either he isn't using a virus scanner with an "Active Certificate Check" feature, or that feature is turned off.

I should've asked Ninho what error he gets in Chrome 34! (IE 8 is no help; it just says "Cannot connect to the site." Duh.) But Chrome's error might give us a clue.

In Opera (12.15 or 12.17, i.e before the ECC addition in 12.18) it would be Error 40.

jaclaz
 

Share this post


Link to post
Share on other sites

@Mathwiz: thank you, very nice and clear explanation of the varieties and nuances of key-exchange and en/decryption algos. 

@Jacklaz, MathW, Heinoganda :

- I am not running real-time AV scanners, much less TLS proxies (mitm things!)

- Chrome's Error code : Inaccessible Web page  ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

The Web page at address https://www.aidanwoods.com/blog/faulty-login-pages/ may be momentarily inaccessible or it might have been moved permanently.

Edited by Ninho
removed unwanted italics !

Share this post


Link to post
Share on other sites

Error 40 would mean a cipher suite mismatch, which I'm pretty sure is the main problem (no ECDHE support). But what heinoganda was pointing out is that he'll also have an issue with the certificate (XP doesn't understand the ECDSA algorithm for verifying the certificate's signature, so it can't consider the cert. valid), so I wanted to see if Chrome was complaining about that first.

Up to now I'd been thinking the cipher suite issue is the important one to address, because the certificate issue could probably be bypassed (it works with FF, so Ninho doesn't appear to be using an AV program that's blocking access entirely). But I just rechecked www.aidanwoods.com, and they're even setting HSTS 8-), which may turn the certificate issue into a show-stopper too. If so, that's a lot harder to fix; so much so it's probably best to give up on Chrome 34 and try another browser. So I wanted to check whether Chrome was complaining about the cert. too. (No worries; if Ninho doesn't reply back; I'll check it myself soon enough.)

Ninho would need a browser that has ECC built in, that also runs on older non-SSE2 processors. FF 3.5 works, but it's very old and doesn't properly render a lot of modern Web sites. I think that's why he's been trying to get Chrome 34 to work.

I haven't tried Opera 12.18 on my oldest PC because 12.18 doesn't run on Win98, even with KernelEx, so I don't know whether it'll run on a non-SSE2 processor.

Edit: Just saw Ninho's reply. Looks like Chrome is complaining about the cipher suite, not the cert. (I know it isn't the SSL version, as TLS 1.0 is supported on both ends), so we may still be in business.

 

Edited by Mathwiz

Share this post


Link to post
Share on other sites

I don't like Mozilla FF, at all. I'm still keeping an FF 10 ESR for cases like this;  the FF 3.5 I mentionned in O.P. is normally reserved for basic Tor browsing here.

Re Opera 12\\ no worky in Win 98 even w/ KernelEx say you ? Surprises me, I think that's the versions I have (on another PC). (Edit) Strike that, that's Opera 10.63. Not too useful at many modern web sites... (/Edit)

While at it, I tried navigating to https://aidanwoods.com/blog ...

not unexpectedly, Opera 10 / Win 98 have been "unable to locate remote server".

Edited by Ninho

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...