[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )



> 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.


Reply to: