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

[Reco <recoverym4n@gmail.com>]

	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