> First, this LD_PRELOAD library does exactly one thing - it downgrades > default TLS version to TLS1.0. If your users have the trouble connecting > to your mailserver because their clients cannot do TLS1.2 and that's the > only thing your mailserver advertizes - your users still won't be able > to connect after downgrading *their* end to TLS1.0. > Second, I somehow doubt that your users' MUAs are based on openssl. > Third, since then LD_PRELOAD works on Windows?
First, using your LD_PRELOAD hack on the Debian server, if a client connects and DOES support TLSv1.2, will use 1.2 or 1.0? Second, reading the code, and I'm no expert with the openssl library, does this cause "outbound" connections to be version 1.0? If I understand you and your code properly, that's what it's going to do. I don't know if there's a mechanism in TLS to start with 1.2 and fail back to a lesser version if the other end doesn't support it. > What you *can* do with this library is to deploy it on your *server* and > LD_PRELOAD cirrus/dovecot/exim/postfix/whatever you have there. It may > even work (I haven't tried it though). Yes of course! I had no intention of trying to install this on the clients! I have not tried your hack yet either. > 'if you have to do a > server - you use Debian stable'. Why am I using Debian Testing? I have been using Testing for several years now and this is the first such issue I've had where it wasn't clear what to do. And as stated, this issue will probably find it's way into Stable too, this is just a preview. Several years ago I was running Stable but I found that there were many packages that did not make it into back-ports. I was constantly in situations where packages I needed to install simply were not available in stable and they had dependencies which I could not easily resolve. I did not want to start building my own packages. After frustration upon frustration, I finally moved to testing and all my problems like this disappeared. I have been delighted with the Testing branch. It's very very stable and in the odd case where it isn't, pinning a package for a while has not caused me problems. However, this situation is different as this package might need to be pinned for YEARS. And as we've said, it's probably going to affect Stable as well at some point and then I may be forced to do something different. What about publicly forking the libssl1 package (like Sven did privately) and having a version of this that tracks all the bug fixes and improvements except the 1.2 requirement? Once you install it, it over-rides/replaces the original. There is probably a right way to do this. Ok so I'm not running a university or a large business. I'm just doing this for a bunch of professional friends and family, still I treat it like real infra since we all have livelihoods that depend on this infra.
