Netlib SChannel usage

[Martok]

Hi,

most plugins (i.e. Jabber) use the netlib-builtin SSL for their SSL/TLS connections, and that uses Microsofts SChannel. While this works perfectly fine, there's one issue: Miranda officially supports XP, and SChannel there only has TLS1.0. With the past year's issues, no sane server operator should still be using that (and more and more start enforcing TLS1.2), so effectively Miranda has no SSL support on XP and can't connect to some services (jabber.ccc.de is one example). Trac tickets #396 and #545 have been about exactly that.
Before that was centralized, some protocols used OpenSSL, so... why SChannel? Things like MS14-066 don't really spark trust in that...

regards,
Martok

[Wishmaster]

Well, just my opinion :
1) Talking about MS14-066, what about Heartbleed?
2) I'm just against to rewrite big parts of the code (especially security-relevant ones) to support Windows XP,not even Microsoft provides any more security patches.
3) Ticket #396 is about a pre-release version of Windows 8.1, and it couldn't be reproduced with the release version, so it was closed. Doesn't have to do anything with Windows XP.

[Martok]

1) Talking about MS14-066, what about Heartbleed?

Well, yes. Probably another reason why you want a library that gets fixes relatively soon. And while we're at it, this thread is more or less about avoiding BEAST (and to a lesser extent, POODLE), and you know how old that already is.

2) I'm just against to rewrite big parts of the code (especially security-relevant ones) to support Windows XP,not even Microsoft provides any more security patches.

Actually, it seems to be very little code for that kind of change, someone obviously thought about modularization there. The SSL_API struct would of course be unchanged, so no plugin would even notice.

If someone, theoretically, implemented a binding in netlibssl, would you accept a patch?

[ghazan]

I strongly disagree against using OpenSSL. it's not only buggy, it has serious problems with threads, that's why it was exterminated in Miranda and replaced with the core services.

You're right, though, considering TLS 1.2/SSL 3.2 support for Windows XP, it might be the only choice...
Okay, I will review a patch, if someone sent it to me

[Wishmaster]

Well, yes. Probably another reason why you want a library that gets fixes relatively soon.

Two years are "relatively soon"? 
Well, just the fact that such a bug was undiscovered for more then two years sparks my trust in OpenSSL, and it wasn't the only bug with OpenSSL.
Microsoft usually fixes such things very fast too, and users can install it on regular patchdays.
If another bug like Heartbleed is found, all Miranda NG binaries would have to be recompiled and released as an emergency release, all users would have to update Miranda NG. That leaves a greater risk for users to be unprotected.

And while we're at it, this thread is more or less about avoiding BEAST (and to a lesser extent, POODLE), and you know how old that already is.

Yes, but it is just a problem of Windows XP not being supported any longer. Windows Vista or newer are safe.

Actually, it seems to be very little code for that kind of change, someone obviously thought about modularization there. The SSL_API struct would of course be unchanged, so no plugin would even notice.

If someone, theoretically, implemented a binding in netlibssl, would you accept a patch?

Well, I wouldn't, but thats just my opinion. In fact, the security issues in Windows XP are the only advantage in switching to OpenSSL, while there are a lot of disadvantages for users of Windows Vista or newer, and those users are the major target .

[Martok]

If that's really your argument, we might as well use GnuTLS, that never had a broken hearbeat. Only issue is that the official windows binaries come in about a billion DLLs instead of two...

Microsoft usually fixes such things very fast too, and users can install it on regular patchdays.

The ones they tell you about on that patchday, yes.

If another bug like Heartbleed is found, all Miranda NG binaries would have to be recompiled and released as an emergency release, all users would have to update Miranda NG.

Erm, no? That's the point of DLLs, just update them and leave the rest alone. Only thing needed would be to push new files to the updater repository and you're done. Users with auto-updates turned off could just update the SSL library themselves.

Yes, but it is just a problem of Windows XP not being supported any longer.

Indeed. The reason I originally posted here in the first place instead of just accepting it: Miranda officially supports XP and I've seen other threads specifically testing on XPSP3, so it would make sense to have the basic net code work there as well.

Alright, I have the current source revision building now, let's see what I can do about this.

EDIT: preliminary report: it works, but lacks all error handling and logging. Certificate verification against Windows' certstore is going to be "interesting", but should, in theory, work.
Post Merge: 01 12 2014, 16:20:53Well, that was easier than I expected. (Github, I'll create a pull request once it's done).
Built against OpenSSL 1.0.1j (Package from Shining Light).

Dynamically loads all required libraries, header is only used for type declarations and constants. Certificate verification is unchanged, the code constructs a CryptAPI-Context from OpenSLL X509 data to do that. Handshake uses TLS1.0...1.2, works with all protocols I currently use in Miranda.
OpenSSL is a bit more highlevel than the SChannel methods used before, so there's no traffic logging - we simply don't see it anymore. I do however log the chosen cipher suite, it's actually quite interesting to see who can provide some security and who just barely has something like SSL (hello, ICQ...).

What's still missing: license note for OpenSSL and installer script changes, I don't know enough about the release procedure to do that.

One question I have right away: why was crypt32.dll not unloaded originally? I've kept it like that, but I wonder...

[Wishmaster]

Sounds good! We could just move the default SSL implementation to a standard module Core\StdSSL.dll and allow it to be replaced by third-party-plugin. Let's talk about releases later.

PS: You are also invited to our jabber-channel: miranda-ng-int@conference.jabber.ru

[Martok]

Had the version we discussed in active use for two weeks now, seems stable to me, including the cert store translation .

I've split the changes in two parts: the patch against Miranda and the OpenSSL implementation as a separate repository. Makes it easier to see what's what.

[AnrDaemon]

Two years are "relatively soon"? 

Two years since what? As soon as the error was discovered, it was fixed.

Well, just the fact that such a bug was undiscovered for more then two years sparks my trust in OpenSSL, and it wasn't the only bug with OpenSSL.
Microsoft usually fixes such things very fast too, and users can install it on regular patchdays.

Microsoft fix things as they are discovered. So I don't see your reasoning against OpenSSL based on "speed of patching" very valid.

If another bug like Heartbleed is found, all Miranda NG binaries would have to be recompiled and released as an emergency release, all users would have to update Miranda NG.

Very unlikely. ABI of OpenSSL is rarely changed. All they will need to do is to update libraries. And you already have infrastructure in place to push them upon your users. Many are even stupid enough to let their systems update automatically.

That leaves a greater risk for users to be unprotected.

No more than in any other scenario.

Yes, but it is just a problem of Windows XP not being supported any longer. Windows Vista or newer are safe.

Only as long as M$ keep them updated.
While with OpenSSL, you know it will be updated regardless of M$'s mood.

Well, I wouldn't, but thats just my opinion. In fact, the security issues in Windows XP are the only advantage in switching to OpenSSL, while there are a lot of disadvantages for users of Windows Vista or newer, and those users are the major target .

Major target for whom? For me, many of my surounding despise anything Vista or newer as unusable crap. It impede their ability to use their PC's.

[Martok]

Agreed (at least partly).

Something that occured to me the other day: XP support ended April 2013, and the highest available TLS revision is TLS 1.0. RFC 4346 (TLS1.1) was released in 2006, RFC 5246 (TLS1.2) in 2008. Windows 7 was released in 2009. What became known as BEAST in 2011 was in principle known in 2002, and the only proper fix to that was always "don't use anything below TLS 1.1".
This means that for 7 resp. 5 years, microsoft did not bother to update their library (or, actually, just deploy it - we know they had the code since it is in newer Windows versions) even though it was still in the official support cycle.

I'm pretty sure 5 years unfixed known vulns beat a 2 years unfixed unknown vuln which got fixed within days after discovery.

Just seen that the Git mirror has updated, I'll rebase my changes then. (EDIT: it's current now)

[ghazan]

Martok, the whole external ssl plugin infrastructure is committed
you may proceed

[Martok]

Cool!

This won't work with the current loader though, since when iterating over the DLLs in \Plugins\, it tries to load the OpenSSL libs (as plugins), causing the dynlinker to bail because ssleay32 can't find libeay32 (which is correct, since Plugins isn't in the searchpath). Is there a real point in loading plugins that already have PCLASS_FAILED set on them in the last loop in LoadNewPluginsModule? Legacy plugins?

Although I suppose I could just put the externals in a subdirectory (if that is acceptable). They're loaded dynamically anyway.

I'm sorry I can't join the jabber room these days, someone thought it would be incredibly funny to DDoS jabber.ccc.de, it's still recovering.

Oh, and by the way, the StdSsl version.rc needs fixing.

EDIT: and I really need to check the SVN for changes instead of the Git mirror. You may disregard most of that post... and also the fact that I just updated my plugin to work with that interface.

[watcher]

Oh, and by the way, the StdSsl version.rc needs fixing.

I fixed it - but it really not in use.

[ghazan]

Martok, OpenSSL installer places dlls into the Windows system32 folder, so there's no need to put them near Miranda.
if you want, you can store libeay/ssleay right near Miranda32.exe, in this case they will be loaded by any plugin (like zip.dll)

[Martok]

Makes sense.

One thing I found: the plugin needs to be static (as in UNICODE_AWARE | STATIC_PLUGIN), unloading after the API struct has been filled doesn't work.

Edit after r11774: Yup, works.