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

>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

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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.

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

> 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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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