Hi. On Fri, Sep 08, 2017 at 10:20:22AM +0100, Michael Grant wrote: > > 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?
Untested. Since I know next to nothing about MTAs - all that's required of me is to setup a smarthost and that's it - I can not setup a meaningful test environment. I could try to poke a dovecot though, but it will take time. My best understanding of this is if a TLS server does not specify an exact version of protocol used then "old" openssl just assumes that TLS1.0, TLS1.1 and TLS1.2 should be used at once. "New" openssl just provides TLS1.2 *unless* you find a way to specify exact version of TLS that's to be used (nginx can be told to do so for instance). LD_PRELOAD hack (please stop calling it mine - I've forsaken authorship of it) forces it to be TLS1.0 *only*. Unless you change the code, of course. > Second, reading the code, and I'm no expert with the openssl library, > does this cause "outbound" connections to be version 1.0? That was the original idea. The code was written to scratch a particular itch, and it was to force plain openssl and ncat (from nmap) to use TLS1.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. That's where an openssl expert is needed. I won't claim to be the one. > > '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. True. But by that time the dust should settle and the suitable workaround would be found. The difference between "stable" and "testing" is that the users of the latter need it now. The users of the former can afford to wait and see how it plays out. > 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. Interesting. Care to share which packages did you lack for *server* purposes? > 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. I don't know since I'm way too lazy to fork an openssl singlehandedly. I trust Debian project as I've installed their OS numerous times. Why should I trust some guy or gal (whom I don't acquainted with, no offence meant) to provide me with such security-sensitive package? Reco
