Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

>Would still like to know what's motivating Google's insistence on SNI...

The TLS WG is probably the place to ask this.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 17, 2018, at 11:27 PM, Salz, Rich  wrote:
> 
> So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client).  That 
> seems easy to code.

That might be a sensible work-around, with a bit of care to make sure that the 
user has not also disabled TLS 1.2 (i.e. try TLS 1.3 without SNI if that's all 
that is enabled).

Would still like to know what's motivating Google's insistence on SNI...
Sounds like a rather unnecessary downgrade.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client).  That 
seems easy to code.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Tue, 17 Apr 
2018 14:32:37 -0400, Viktor Dukhovni  said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 17, 2018, at 2:15 PM, Richard Levitte 
 wrote:
openssl-users> > 
openssl-users> > Depends on what "the best thing you know to do" is.  In my 
mind,
openssl-users> > simply refusing to run as before because the new kid in town 
didn't
openssl-users> > like the environment (for example a cert that's perfectly 
valid for
openssl-users> > TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the 
best thing
openssl-users> > you know to do".
openssl-users> > 
openssl-users> > But I get you, your idea of "the best thing you know to do" is 
to run
openssl-users> > the newest protocol unconditionally unless the user / 
application says
openssl-users> > otherwise, regardless of if it's at all possible given the 
environment
openssl-users> > (like said cert).
openssl-users> 
openssl-users> If there were a non-negligible use of certificates that work 
with TLS 1.2,
openssl-users> and that (implementation bugs aside) can't work with TLS 1.3, 
I'd support
openssl-users> your position strongly.  As it stands, I think you're right in 
principle,
openssl-users> but not yet in practice.  If we find no show-stopper issues, we 
should
openssl-users> allow TLS 1.3 to happen.

The troublesome thing with "but not yet in practice" is that we won't
know before 1.1.1 is finally released and has been deployed in a
larger scale.  In my mind, that's too late.  So my view is much more
black and white, like is it at all possible that there will be
certificates or other "stuff" out there that will have libssl fail
setting up communication because TLSv1.3?  If the answer is yes, I
find it hard to ignore this.

openssl-users> I'm far more concerned about lingering middle-box issues, than 
about some
openssl-users> edge-case certificates...

There's that too, yeah.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 17, 2018, at 2:15 PM, Richard Levitte  wrote:
> 
> Depends on what "the best thing you know to do" is.  In my mind,
> simply refusing to run as before because the new kid in town didn't
> like the environment (for example a cert that's perfectly valid for
> TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
> you know to do".
> 
> But I get you, your idea of "the best thing you know to do" is to run
> the newest protocol unconditionally unless the user / application says
> otherwise, regardless of if it's at all possible given the environment
> (like said cert).

If there were a non-negligible use of certificates that work with TLS 1.2,
and that (implementation bugs aside) can't work with TLS 1.3, I'd support
your position strongly.  As it stands, I think you're right in principle,
but not yet in practice.  If we find no show-stopper issues, we should
allow TLS 1.3 to happen.

I'm far more concerned about lingering middle-box issues, than about some
edge-case certificates...

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <87d0yxq0m7@fifthhorseman.net> on Tue, 17 Apr 2018 09:05:52 
-0700, Daniel Kahn Gillmor  said:

dkg> On Mon 2018-04-16 08:22:59 +0200, Richard Levitte wrote:
dkg> > Generally speaking, I don't necesseraly agree.  If the use of an API
dkg> > is perfectly valid for the conditions a program was built for, and
dkg> > then suddenly breaks down because the new kid in town wanna play,
dkg> > I find it hard to call that mis-use.  I would much rather have libssl
dkg> > do something along the lines of "oh, you're one of the old guys, let's
dkg> > use something that works for you".
dkg> 
dkg> But if that's the only API semantics, then there's no way for my project
dkg> that depends on libssl to say "do the best thing you know how to do", so
dkg> that i can get benefits from a simple upgrade.

Depends on what "the best thing you know to do" is.  In my mind,
simply refusing to run as before because the new kid in town didn't
like the environment (for example a cert that's perfectly valid for
TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
you know to do".

But I get you, your idea of "the best thing you know to do" is to run
the newest protocol unconditionally unless the user / application says
otherwise, regardless of if it's at all possible given the environment
(like said cert).

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 16, 2018, at 6:00 AM, Matt Caswell  wrote:
> 
> That's not entirely true. This works:
> 
> $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
> $ openssl s_client -no_tls1_3 -cipher ALL@SECLEVEL=0
> 
> This doesn't:
> 
> $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
> $ openssl s_client -cipher ALL@SECLEVEL=0
> 
> 139667082474432:error:14201076:SSL routines:tls_choose_sigalg:no
> suitable signature algorithm:ssl/t1_lib.c:2484:
> 
> We do not allow DSA certs in TLSv1.3.

It is largely time we did not allow them in TLS 1.2 either, nobody
uses them, but perhaps "nobody" == USG?

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

Tim and Viktor have convinced me that “it’s not worth it” is wrong.  Thanks, 
Richard, for testing 1.1.0 tests with 1.1.1 library. We do need to analyze the 
results and not say any failure means something 1.1.1 has to fix – it could be 
failing because of an assumption in the 1.1.0 tests.  Am I correct in saying 
that, so far, everything has been of that type?

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Tim Hudson]

Where we are stating that ABI compatibility is in place we should be
testing it.
i.e. the older release binaries should be run against the current release
libraries - and that should be put into CI in my view.

Going the other direction isn't something I have thought we have ever
guaranteed (i.e. downgrading) - but programs that don't use new APIs (i.e.
for the ABI) should also work - that is pretty much the definition of an
ABI.
If we are unable to provide the forward ABI then we need to change the
version number of the release going forward. If weare unable to provide
backwards ABI then we need to think about how we are defining things and
make that clear.

And we need to be clear about what we mean by ABI - I don't think we have
written down a clear definition - and then have in CI the tests to match
what we are saying we do.

When it comes to TLSv1.3 it is highly desirable that an existing 1.1.0
application gets TLSv1.3 without API changes - i.e. ABI provides this.
There will be some things where there are problems where assumptions are
invalidated - but we should work to minimise those (and I think we have
actually done so).
But again we should be testing this in CI - if we want old apps to all get
TLSv1.3 for zero effort (other than a shared library upgrade) then we
should test that in CI. Hoping it works or assuming it works and "manually"
watching for changes that might invalidate that is rather error prone.

What Richard is doing really helps add to the information for informed
decisions ... the more information we have the better in my view.

Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 15, 2018, at 12:59 PM, Salz, Rich  wrote:
> 
> Let me turn the question around because we'll never know "everything" just 
> works. Except for our tests, what programs work with 1.1.0 and *fail* to work 
> with 1.1.1?  Any? For various reasons that Viktor and I have detailed, *our 
> tests* do not count.

I would not go as far as that.  Our tests do count, and should be paid 
attention to, but we need to be careful about interpreting the results.  
Sometimes the answer is to tune the test to make it portable to later library 
versions.  So far, we've not seen issues that warrant a library version bump, 
but testing this is a good idea, and Richard is doing good work.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 15, 2018, at 12:55 PM, Salz, Rich  wrote:
> 
> Do our 1.1.0 tests work when linked against the 1.1.1 library?

Our tests don't, but Richard (valiantly I must say) went to the trouble
of doing just that.  And found some tests that failed, ...

> Even then, there might be some failures because some of those tests probably 
> say "pick any protocol" and they were written at a time when 1.3 was not 
> available so might explicitly test, for example, that "any protocol" meant 
> "got 1.2"

in particular this type of failure.

> It would be interesting to test 1.1.0 against the 1.1.1 library, and then 
> analyze the failures and see which, if any, indicate bugs in the 1.1.1 
> compatibility.

This is what Richard was doing, and I commend his efforts.

> Again, to repeat myself, we have datapoints that 1.1.0 programs can use 1.1.1 
> library with no problems. We do not have any datapoints that typical 1.1.0 
> programs fail when using 1.1.1 library. 

I think that tests of this sort are valuable, and should in some cases make the 
test's assumptions more explicit, so that they will also pass with later 
libraries.  Then we can focus on any "real" issues that come up, and decide 
whether they are bugs, significant incompatibilities or "artificial" issues not 
substantive for "real" applications.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

> I believe we were led into the current situation, because our tests don't 
completely work *going backwards.*  Do the 1.1.0 tests basically work *going 
forwards* ?

>It is unclear what you mean by forwards and backwards, but some 1.1.0
tests failed when using a 1.1.1 library.  However, the tests that I
read about failing were testing artificial expectations that are only
appropriate for the same library as the tests.  The tests can be fixed
to make their expectations more explicit (by e.g. setting the max protocol
version to the largest supported by the corresponding library).
  
Good point.  I meant our 1.1.1 tests don't completely work when linked with 
1.1.0 library.  I am not surprised about that as I am sure there are all sorts 
of hidden assumptions in the 1.1.1 tests.  Now it seems to turn out that there 
are only a couple of assumptions, and that maybe we can fix them.  As I said 
initially, I don't see that as worth any effort, but others are free to 
disagree and have.

Do our 1.1.0 tests work when linked against the 1.1.1 library?  Even then, 
there might be some failures because some of those tests probably say "pick any 
protocol" and they were written at a time when 1.3 was not available so might 
explicitly test, for example, that "any protocol" meant "got 1.2"  It would be 
interesting to test 1.1.0 against the 1.1.1 library, and then analyze the 
failures and see which, if any, indicate bugs in the 1.1.1 compatibility.

Again, to repeat myself, we have datapoints that 1.1.0 programs can use 1.1.1 
library with no problems. We do not have any datapoints that typical 1.1.0 
programs fail when using 1.1.1 library. 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 15, 2018, at 2:24 AM, Bernd Edlinger  wrote:
> 
> One possible example of application failure that I am aware of is #5743:
> A certificate that is incompatible with TLS1.3 but works with TLS1.2.
> Admittedly that I did come up with that scenario only because I saw
> a possible issue per code inspection.

[ Repeating in part my response to Richar's mesage also in this thread ]

This is a bug that needs to be fixed, the point format for TLS does not
have any provenance over X.509.  There's no such thing as a certificate
not compatible with TLS 1.3 (that is compatible with TLS 1.2).

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Sun, 15 Apr 
2018 13:27:15 +0200, Andy Polyakov  said:

appro> To summarize, failing tests in 110 should be revisited to see if they
appro> are actually representative, before one can consider as drastic measures
appro> as #5945.

At this point, I agree.  Viktor's look at several applications and
Kurt's report of successful did convince me that I might by crying
wolf a bit much.  I've started looking a bit deeper at the failing
tests, for exactly the reasons you mention.

Now, there was a point brought on by a couple of issues mentioned,
I'll take that in a separate email.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Andy Polyakov]

> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>programs linked with libssl 1.1.0.  This is what's done in this PR:
>https://github.com/openssl/openssl/pull/5945
>This makes sense insofar that it's safe, it works within the known
>parameters for the library these programs were built for.

Here is a thing. If we assume that 110/test/sslapitest.c is
*representative* example of an 1.1.0 application, then it's not at all
given that #5945 would actually solve anything. Indeed, observing the
first failing test, recompiled 110/test/sslapitest.c would still fail,
because it makes assumption that session id is available right after
negotiation, something that doesn't hold true for TLS 1.3. This gives
you either a) no 1.1.0 application goes safe, recompiled[!] or not; b)
110/test/sslapitest.c is not representative example. Well, as far as
first failing test goes, I'd say it's b), which means that it should be
adjusted in one way or another or failing check omitted. [It's b),
because it's unnatural to put session id you've just got back to id
cache, the test is ultimately synthetic.] This naturally doesn't answer
all the questions, but it does show that above mentioned premise is
somewhat flawed. I mean "programs were built for [1.1.0]" would still
work if recompiled with #5945.

>It also makes sense if we view TLSv1.3 as new functionality, and
>new functionality is usually only available to those who
>explicitely build their programs for the new library version.
>TLSv1.3 is unusual in this sense because it's at least it great
>part "under the hood", just no 100% transparently so.

In such case it should rather be #ifdef OPENSSL_ENABLE_TLS1_3 instead of
#ifndef OPENSSL_DISABLE_TLS1_3. And we don't want that.

To summarize, failing tests in 110 should be revisited to see if they
are actually representative, before one can consider as drastic measures
as #5945.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Kurt Roeckx]

On Sun, Apr 15, 2018 at 07:38:48AM +0200, Richard Levitte wrote:
> In message  on Sat, 14 Apr 
> 2018 21:13:47 +, "Salz, Rich"  said:
> 
> rsalz> We have *no* data points, except our tests, that anything fails to 
> work.
> rsalz> In fact, we are increasingly collecting data that shows everything is 
> just fine.
> 
> Errr, are we?  Please inform me, because I cannot remember having seen
> tests that specifically targets the case of programs built with 1.1.0
> that get implicitly relinked with 1.1.1 libraries (that's what you
> call "going forward", isn't it?), or data collection for that matter.
> I may have missed something, but I am interested.

In Debian we've done a rebuild test of all source packages that link
to 1.1.0 to build against pre2 instead, and as far as I know only 1
package was found to fail because of that: #5637

This is of course slightly different than just upgrading the
library since it can pick up new header files, but I think this is
close enough. It also only covers those packages that have a test
suite.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Bernd Edlinger]

On 04/15/18 07:53, Viktor Dukhovni wrote:
> 
> 
>> On Apr 15, 2018, at 1:38 AM, Richard Levitte  wrote:
>>
>> Errr, are we?  Please inform me, because I cannot remember having seen
>> tests that specifically targets the case of programs built with 1.1.0
>> that get implicitly relinked with 1.1.1 libraries (that's what you
>> call "going forward", isn't it?), or data collection for that matter.
>> I may have missed something, but I am interested.
> 
> It think it is most prudent to not fall into the trap of debating this
> particular side-issue.  I commend your initiative of running the 1.1.0
> tests against the 1.1.1 libraries, that's fantastic.  And I further
> commend attention to the failure cases.  Thank you.
> 
> With that out of the way, it seems to me that apart from some fixes in
> the test framework, and tests that did not expect protocol versions
> higher than TLS 1.2, no *interesting* issues have turned up.
> 
> If such issue did or will turn up let's fix them, but there should not
> be fundamental obstacles to an ABI-compatible 1.1.1 library with the
> same SONAME as its 1.1.0 predecessor.  The new library may negotiate
> TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility
> that requires an SONAME version bump.
> 
> Which is not to say I could not be convinced otherwise, but at present
> I don't see a need for the bump, or for work-arounds to limit the
> negotiated protocols for code compiled against 1.1.0 that happens to
> run against 1.1.1.
> 
> Let's stay alert, but not overreact to minor issues we can resolve.
> 

One possible example of application failure that I am aware of is #5743:
A certificate that is incompatible with TLS1.3 but works with TLS1.2.
Admittedly that I did come up with that scenario only because I saw
a possible issue per code inspection.


Bernd.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 15, 2018, at 1:38 AM, Richard Levitte  wrote:
> 
> Errr, are we?  Please inform me, because I cannot remember having seen
> tests that specifically targets the case of programs built with 1.1.0
> that get implicitly relinked with 1.1.1 libraries (that's what you
> call "going forward", isn't it?), or data collection for that matter.
> I may have missed something, but I am interested.

It think it is most prudent to not fall into the trap of debating this
particular side-issue.  I commend your initiative of running the 1.1.0
tests against the 1.1.1 libraries, that's fantastic.  And I further
commend attention to the failure cases.  Thank you.

With that out of the way, it seems to me that apart from some fixes in
the test framework, and tests that did not expect protocol versions
higher than TLS 1.2, no *interesting* issues have turned up.

If such issue did or will turn up let's fix them, but there should not
be fundamental obstacles to an ABI-compatible 1.1.1 library with the
same SONAME as its 1.1.0 predecessor.  The new library may negotiate
TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility
that requires an SONAME version bump.

Which is not to say I could not be convinced otherwise, but at present
I don't see a need for the bump, or for work-arounds to limit the
negotiated protocols for code compiled against 1.1.0 that happens to
run against 1.1.1.

Let's stay alert, but not overreact to minor issues we can resolve.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Sat, 14 Apr 
2018 21:13:47 +, "Salz, Rich"  said:

rsalz> We have *no* data points, except our tests, that anything fails to work.
rsalz> In fact, we are increasingly collecting data that shows everything is 
just fine.

Errr, are we?  Please inform me, because I cannot remember having seen
tests that specifically targets the case of programs built with 1.1.0
that get implicitly relinked with 1.1.1 libraries (that's what you
call "going forward", isn't it?), or data collection for that matter.
I may have missed something, but I am interested.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 14, 2018, at 5:09 PM, Richard Levitte  wrote:
> 
>> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
>> library against a TLS 1.2 server and it worked fine.
> 
> Does this answer the whole question, or do they just do the most basic
> stuff that our public headers make available?

No mere test constitutes a formal proof of correctness.  I'm just saying
that compile-time 1.1.0 runs fine in routine SSL sessions with 1.1.1 as
the underlying library.  The posttls-finger program is comparatively
sophisticated in its use of SSL, but by no means tests the entire API.

> To put it another way, I would absolutely hate it if, after 1.1.1
> (assuming that's what we go for) is released, people came back
> screaming at us because their program toppled over or bailed out in a
> virtual panic attack just because of a shared library upgrade.

When support for TLS 1.2 appeared in OpenSSL, some Postfix users ran
into some trouble, with middle-boxes or some such and had to cap the
TLS version at TLS 1.0.  This happened some time between 1.0.0 and
1.0.2 IIRC, with the library ABI at 1.0.  This is to be expected.
No matter what we do some users will upgrade their applications and/or
OpenSSL library and find that they run into some friction with TLS 1.3.
None of our work-arounds will make the problem go away.  They'll just
have to deal with it.

> openssl-users> What version of OpenSSL is Postfix linked against on 
> mta.openssl.org?
> openssl-users> Care to upgrade it to 1.1.0 if not already?  Then replace the 
> libraries
> openssl-users> with the 1.1.1 versions?  I can then retest...
> 
> But tell you what, there's a test machine as well, which I did set up
> specifically for trying this sort of thing.  I can certainly screw
> around with all of that there.

A test machine would be great.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

We have *no* data points, except our tests, that anything fails to work.
In fact, we are increasingly collecting data that shows everything is just fine.

I believe we were led into the current situation, because our tests don't 
completely work *going backwards.*  Do the 1.1.0 tests basically work *going 
forwards* ?


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 14, 2018, at 4:40 PM, Richard Levitte  wrote:
> 
> Would you say that it's an application bug if it stumbles on a change
> in API behavior that isn't due to a bug fix?  (and even better, if it
> worked according to documentation?)

Negotiating a new version of TLS is not a change in API behaviour.  The
application asks for a TLS session (of no particular maximum version),
and it gets one that both the client library and the peer support.

I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
library against a TLS 1.2 server and it worked fine.

What version of OpenSSL is Postfix linked against on mta.openssl.org?
Care to upgrade it to 1.1.0 if not already?  Then replace the libraries
with the 1.1.1 versions?  I can then retest...

Running an MTA built for 1.1.0 against 1.1.1 libraries might be a reasonable
way to "eat our own dog food".

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <44fe0745-31df-41c3-b697-97025643c...@dukhovni.org> on Sat, 14 Apr 
2018 16:24:56 -0400, Viktor Dukhovni  said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte 
 wrote:
openssl-users> > 
openssl-users> >> Will real applications run into any meaningful problems?
openssl-users> > 
openssl-users> > This is an argument that I find *terribly* frustrating.  Are 
you
openssl-users> > suggesting that we have no test that tries to do what can be 
expect
openssl-users> > from a "real" application?
openssl-users> 
openssl-users> I am suggesting that we ignore test failures that test for rather
openssl-users> artificial conditions.  If our test negotiates TLS with our own
openssl-users> server and tests that it got exactly TLS 1.2 (because that's the
openssl-users> highest version our test expected to support by default) that's 
an
openssl-users> artificial test, and its failure is fine.

Do all the tests do that, i.e. actually check that they got nothing
higher than TLSv1.2?  This is an open question, I haven't dived enough
into the TLS stuff to know (but will next week unless someone can say
for sure).  If that is the case, then I agree that it's quite
artificial.  Otherwise, not so much.

openssl-users> Real applications that want no more than TLS 1.2 need
openssl-users> to set the max version, or not expect that maximum.
openssl-users> Anything else is an application bug.

Would you say that it's an application bug if it stumbles on a change
in API behavior that isn't due to a bug fix?  (and even better, if it
worked according to documentation?)

openssl-users> Do we have any meaningful test failures that are not
openssl-users> artificial like the above?  If so, we should fix them,
openssl-users> if not we possibly need more tests, but are otherwise
openssl-users> fine as best we know.

I disagree with us being fine, unless the possible issue I'm raising
can be disqualified with certainty.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <352ebaa2-b2d4-4a2e-adc4-1033a1735...@dukhovni.org> on Sat, 14 Apr 
2018 16:01:42 -0400, Viktor Dukhovni  said:

openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available 
for
openssl-users> >   programs linked with libssl 1.1.0.  This is what's done in 
this PR:
openssl-users> >   https://github.com/openssl/openssl/pull/5945
openssl-users> >   This makes sense insofar that it's safe, it works within the 
known
openssl-users> >   parameters for the library these programs were built for.
openssl-users> >   It also makes sense if we view TLSv1.3 as new functionality, 
and
openssl-users> >   new functionality is usually only available to those who
openssl-users> >   explicitely build their programs for the new library version.
openssl-users> >   TLSv1.3 is unusual in this sense because it's at least it 
great
openssl-users> >   part "under the hood", just no 100% transparently so.
openssl-users> 
openssl-users> This should NOT be necessary.  What it is about enabling TLS 1.3
openssl-users> that breaks existing code?  Let's fix that.

I'm not savvy enough to answer that properly.  I'm mostly observing
from the exterior.

openssl-users> > 3.   I dunno, please share ideas if you have them.
openssl-users> 
openssl-users> We need to make sure that the introduction of TLS 1.3 is 
transparent,
openssl-users> aside from occasionally leading to a connection that uses TLS 
1.3.
openssl-users> 
openssl-users> If all that's failing is our test-suite, which is too sensitive 
to the
openssl-users> underlying implementation details, that's fine, not all the 
tests are 
openssl-users> designed to run cross-library.
openssl-users> 
openssl-users> Will real applications run into any meaningful problems?

This is an argument that I find *terribly* frustrating.  Are you
suggesting that we have no test that tries to do what can be expect
from a "real" application?  What do you expect a "real" application to
limit itself to?  Do you expect a "real" application to always set a
maximum TLS version?  Do you expect a "real" application to expect
failure because it hasn't?  Was any of the limitations you might think
of advertised?  In the 1.1.0 manual pages?  Elsewhere?

Also, I imagine that test_ssl_old, test_ssl_new and test_sslapi are
three tests that do try to mimic "real world" use of libssl.

openssl-users> While can artificially limit the max protocol in applications 
compiled
openssl-users> for 1.1.0, I don't think that's a compelling design choice.  We 
have
openssl-users> support in 1.1.0 for min/max protocol, applications can use those
openssl-users> controls explicitly.

Yes, they can, but they won't necessarely.  Just as an example, our
1.1.0 test programs didn't before I stoopidly made them do so (I'm
reverting that with https://github.com/openssl/openssl/pull/5947,
because it was an enormously stoopid move that only showed that an
upgrade to 1.1.1 *required* at least the addition of such controls)

openssl-users> In any case in order of preference, I'd like to see:
openssl-users> 
openssl-users>   1. Fix any issues so that it is safe to upgrade.
openssl-users>   2. Make the library version 1.2
openssl-users>   3. Hack the API to cap the protocol version based on 
compile-time
openssl-users>  maximum.
openssl-users> 
openssl-users> -- 
openssl-users> -- 
openssl-users>  Viktor.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Salz, Rich]

I have not heard that any application program -- NOT COUNTING OUR TESTS -- that 
break.  The one counterpoint we have is that s_client/s_server work.

 

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Viktor Dukhovni]

> On Apr 14, 2018, at 3:32 PM, Richard Levitte  wrote:
> 
> So regarding assumptions, there's only one assumption that I'm ready
> to make: a program that worked correctly with libssl 1.1.0 and uses
> its functionality as advertised should work the same with libssl
> 1.1.1.  Note that I'm not saying that this excludes new features
> "under the hood", but in that case, those new features should work
> transparently enough that a program doesn't need to be changed because
> of them.  Also, note again that I'm not talking about recompilation,
> but the implicit relinking that is what happens when a shared library
> is upgraded but keeps the same library version number (no "bump").
> (mind you, explicit relinking would make no different in this regard).
> 
> Does anyone disagree with that assumption?

It must be possible to upgrade from 1.1.0 to 1.1.1 without source
code changes, or relinking the program.  From what you describe,
it seems that source code changes might be needed to adapt to
a TLS-1.3-capable library.  That should not happen.

> 1. There's the option of making the new release 1.2.0 instead of 1.1.1.
>   I think most of us aren't keen on this, but it has to be said.

This does not address the issue of yet another compatibility break, with
many distributions not yet done adopting 1.1.0.  So I don't see that
as a solution.

> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>   programs linked with libssl 1.1.0.  This is what's done in this PR:
>   https://github.com/openssl/openssl/pull/5945
>   This makes sense insofar that it's safe, it works within the known
>   parameters for the library these programs were built for.
>   It also makes sense if we view TLSv1.3 as new functionality, and
>   new functionality is usually only available to those who
>   explicitely build their programs for the new library version.
>   TLSv1.3 is unusual in this sense because it's at least it great
>   part "under the hood", just no 100% transparently so.

This should NOT be necessary.  What it is about enabling TLS 1.3
that breaks existing code?  Let's fix that.

> 3.   I dunno, please share ideas if you have them.

We need to make sure that the introduction of TLS 1.3 is transparent,
aside from occasionally leading to a connection that uses TLS 1.3.

If all that's failing is our test-suite, which is too sensitive to the
underlying implementation details, that's fine, not all the tests are 
designed to run cross-library.

Will real applications run into any meaningful problems?

While can artificially limit the max protocol in applications compiled
for 1.1.0, I don't think that's a compelling design choice.  We have
support in 1.1.0 for min/max protocol, applications can use those
controls explicitly.

In any case in order of preference, I'd like to see:

  1. Fix any issues so that it is safe to upgrade.
  2. Make the library version 1.2
  3. Hack the API to cap the protocol version based on compile-time
 maximum.

-- 
-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Kurt Roeckx]

On Sat, Apr 14, 2018 at 09:54:41PM +0200, Richard Levitte wrote:
> Yes, I agree that the TLSProxy tests aren't the most important in this
> regard.  Also note that this part was a side note.

Can you then find examples of what a normal user of the library
might be expected to do that fails?

I know some other libraries have tests to see if version
negiotation works properly. I expect those tests to fail, but I
don't see this as a problem because the tests don't know about
TLSv1.3 yet, and the library itself and it's users will work
without problems.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <20180414194244.ga27...@roeckx.be> on Sat, 14 Apr 2018 21:42:45 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
kurt> > 
kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
kurt> >that are meant to fail (i.e. if the individual tests fail, the
kurt> >recipe is successful).  When run against 1.1.1 libraries, the
kurt> >recipe fails, i.e. the injection of double hellos didn't get the
kurt> >communication to fail, or so it seems...
kurt> 
kurt> This seems to be a test that is very aware of the protocol, and
kurt> what should fail and what shouldn't. If you introduce a new
kurt> protocol, the things it check might need to be updated. This is
kurt> not something a normal application will be doing, so I don't see
kurt> this as a problem.

Yes, I agree that the TLSProxy tests aren't the most important in this
regard.  Also note that this part was a side note.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Kurt Roeckx]

On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
> 
> a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
>that are meant to fail (i.e. if the individual tests fail, the
>recipe is successful).  When run against 1.1.1 libraries, the
>recipe fails, i.e. the injection of double hellos didn't get the
>communication to fail, or so it seems...

This seems to be a test that is very aware of the protocol, and
what should fail and what shouldn't. If you introduce a new
protocol, the things it check might need to be updated. This is
not something a normal application will be doing, so I don't see
this as a problem.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

Hi,

First, a note: I don't want this discussion to be just about technical
details, but also about philosophy, and guidance for policy making in
the long run.  My feeling is that we've been...  well, a bit lax with
regards to library upgrade and program relinking (explicit or
implicit, that shouldn't really matter).

Some time ago, I engaged in the exercise to see how well the test
programs from the 1.1.0 branch would do if linked with the 1.1.1
libraries (i.e. simulating a shared library upgrade from 1.1.0 to
1.1.1).  See https://github.com/openssl/openssl/issues/5661

The conclusion drawn from this exercise is that TLSv1.3 has introduced
a behaviour in libssl 1.1.1 that is incompatible with libssl 1.1.0.
Not in every function, so for example, running basic s_server or
s_client without any special options will work without issues, but
just the fact that some amount of 1.1.0 tests fail when faced with
libssl 1.1.1 tells me that there are some incompatibilities to deal
with.

Of course, one might argue that one can assume that a program that
can't deal with certain details will tell libssl to stick with TLSv1.2
or older...  but I'm unsure if such assumptions are realistic, and I'm
again looking at the 1.1.0 test failures.  Obviously, *we* didn't work
along such assumptions.

So regarding assumptions, there's only one assumption that I'm ready
to make: a program that worked correctly with libssl 1.1.0 and uses
its functionality as advertised should work the same with libssl
1.1.1.  Note that I'm not saying that this excludes new features
"under the hood", but in that case, those new features should work
transparently enough that a program doesn't need to be changed because
of them.  Also, note again that I'm not talking about recompilation,
but the implicit relinking that is what happens when a shared library
is upgraded but keeps the same library version number (no "bump").
(mind you, explicit relinking would make no different in this regard).

Does anyone disagree with that assumption?

So, how to deal with this?

1. There's the option of making the new release 1.2.0 instead of 1.1.1.
   I think most of us aren't keen on this, but it has to be said.

2. Make TLSv1.2 the absolutely maximum TLS version available for
   programs linked with libssl 1.1.0.  This is what's done in this PR:
   https://github.com/openssl/openssl/pull/5945
   This makes sense insofar that it's safe, it works within the known
   parameters for the library these programs were built for.
   It also makes sense if we view TLSv1.3 as new functionality, and
   new functionality is usually only available to those who
   explicitely build their programs for the new library version.
   TLSv1.3 is unusual in this sense because it's at least it great
   part "under the hood", just no 100% transparently so.

3.   I dunno, please share ideas if you have them.


Side discussion:  Some of the failing 1.1.0 tests shows that we've
made some changes in 1.1.1 that we might not have thought would
disrupt anything.

a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
   that are meant to fail (i.e. if the individual tests fail, the
   recipe is successful).  When run against 1.1.1 libraries, the
   recipe fails, i.e. the injection of double hellos didn't get the
   communication to fail, or so it seems...

b. 1.1.0's test/recipes/80-test_ssl_new.t fails in the second test
   (protocol version checks) because it expects an InternalError
   alert, but gets ClientFail instead.  So the question here is, what
   if some program actually pays attention to them?  ...  and it also
   begs the question if the alert type change was a bug fix, and in
   that case, why didn't it propagate to 1.1.0?  Should it?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project