http://bugs.winehq.org/show_bug.cgi?id=20653
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2009-11-16 11:10:53 --- (In reply to comment #15)
...but not with wine's code. Can wine provide keys used in cypher comunication which could be latter used for decyphering tcpdump's content? Thanks for advice.
No, because they're actually derived by GnuTLS, not by Wine. You'd have to hack the function I mentioned to trace the input before it's given to GnuTLS. (Or I could probably hack up a patch, when I find the time.)
Anyway i am still looking into the traces in comment #9 and comment #11. And i dont understand it at all... But still thinking about - you said that it's not in crypt32 (and did reset of component), so why:
- crypt32.CertVerifyCertificateChainPolicy returns 1 in "freezing" warcraft
vs
- crypt32.CertVerifyCertificateChainPolicy returns 0 in "working" warcraft
Because returning 1 results in warcraft doing something different. The freezing is happening within warcraft, not in Wine.
Before the change, warcraft figured the site it was trying to contact had a bogus certificate, so it didn't bother sending anything to it, and let you play as normal.
After the change, warcraft correctly decides that the site it's trying to contact has a valid certificate, so sends it some unknown, encrypted data, and waits for a response. The response never comes. Why is that? It's impossible to know with certainty without knowing the code on the server side. That's why I suggested looking at the data Wine wants to send: it might be possible to guess. For example, perhaps it's sending the version of Windows or some DLLs, and the server decides it's unsupported? But that's just a guess on my part.
You could also hack CertVerifyCertificateChainPolicy to return 0, but you've have to maintain that hack for every version of Wine going forward. There are other apps that depend on this working correctly, and the change was more correct than what it was doing before, so reverting it is not an option.