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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread Viktor Dukhovni


> On Apr 14, 2018, at 5:13 PM, Salz, Rich  wrote:
> 
> 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).

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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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

2018-04-14 Thread 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