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. 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
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> > 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
> 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
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
> 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
On 15/04/18 17:18, Viktor Dukhovni wrote: > > >> 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). > 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. Matt ___ 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 <877ep8s738@fifthhorseman.net> on Sun, 15 Apr 2018 10:38:35 -0700, Daniel Kahn Gillmor said: dkg> Ideally, the semantics of the OpenSSL API for *most* users of the dkg> library should be roughly "give me the best TLS session you can give". dkg> There's no breakage in that API if the underlying library suddenly dkg> starts negotiating TLS 1.3. I generally agree. dkg> An application which uses that API and then breaks because it got a dkg> version of TLS or a ciphersuite that it didn't expect is mis-using the dkg> API (or, is part of the test suite, which is actually testing the dkg> internals of the library it was built against and we should expect a dkg> failure if the library used is changed out from under it). Generally speaking, I don't necesseraly agree. If the use of an API is perfectly valid for the conditions a program was built for, and then suddenly breaks down because the new kid in town wanna play, I find it hard to call that mis-use. I would much rather have libssl do something along the lines of "oh, you're one of the old guys, let's use something that works for you". dkg> I'm all for making a breaking changes in the OpenSSL API to discourage dkg> use of bad/legacy API. That calls for a major version change (in OpenSSL versioning, that would be 1.2.0). I think we've all come to some kind of agreement that doing this isn't desirable at this point... 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
> That said, I have to wonder if doing things like reverting old changes that we don't have CLAs for Just to comment on this one item in your very thoughtful note. We did discuss things within the OMC, and we decided to do this because we really want to change the license with this release. ___ 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
I’m for ABI compatibility going forward (but not necessarily backwards) and for testing it, preferably in a CI loop. I know I’m late to the discussion but it has been enlightening and it looks like a good outcome. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Tim Hudson [mailto:t...@cryptsoft.com] Sent: Monday, 16 April 2018 3:13 AM To: openssl-project@openssl.org Subject: 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. 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
On Sun, Apr 15, 2018 at 01:49:29PM +0200, Richard Levitte wrote: > 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. I'll echo the thanks going around for looking into the tests more closely, and note that I'm happy to see that you are stepping back a bit from the initial report -- it seems good be concerned, but I don't think we have reason to panic quite yet. Having said that, I'll step back a bit and try to speak to the "philosophy" question from the start of the thread. I think it is good philosophy to worry about this sort of ABI stability, and agree with Tim that it's good release engineering practice to have automated tests for it (to the extent that we can). What I'd like us to think more about, though, is our release engineering in general. Don't get me wrong; we've made huge progess since the 1.0.2 era already, adding much more comprehensive test suite (including external tests) and insisting that new features come with tests and documentation. But I still wonder if we could/should be more aware of the release engineering consequences of our more daily changes, at least when master is intended to be on a "stable ABI" branch. In the following examples, I'm not trying to point fingers or say that we made mistakes; so far as I know these were all consistent with our current policy and procedures. That said, I have to wonder if doing things like reverting old changes that we don't have CLAs for, or introducing additional churn into the RNG, are the best idea in this stage of the release cycle. True, we're only in feature freeze and not some final release freeze, but there is risk/reward analysis to be done, and I just don't know how much we've been thinking about that sort of tradeoff. (I believe there are other examples in a similar vein, but don't remember them off the top of my head.) I guess this can be summarized as "I don't have a good understanding for what scale/size of change we as a group are comfortable making during various stages of ABI compatibility and release planning" -- I don't want to dictate policy, just start a discussion (or at least gain a better understanding of existing consensus). I will note, though, that if we want to be very contemplative about the release engineering and ABI stability consequences of changes landing on an "ABI-stable" branch, that may end up leading to a stronger argument for having master never be the "ABI-stable" branch, so that it's always open for development work and we need not do exhaustive analysis for *all* commits during some months+-long period of time. (There would then be a separate stable branch, of course, and we'd do the extra "thinking" when merging to it.) -Ben ___ 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 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
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
> 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
> 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
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? Our s_client and s_server just work. Viktor said postfix just works. I have seen reports that Apache just works. Someone reported python crypto just works. 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. ___ 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
> 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
> 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
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
> 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
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
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
> 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
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
> 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
> 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
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
In message on Sat, 14 Apr 2018 16:46:56 -0400, Viktor Dukhovni said: openssl-users> > On Apr 14, 2018, at 4:40 PM, Richard Levitte wrote: openssl-users> > openssl-users> > Would you say that it's an application bug if it stumbles on a change openssl-users> > in API behavior that isn't due to a bug fix? (and even better, if it openssl-users> > worked according to documentation?) openssl-users> openssl-users> Negotiating a new version of TLS is not a change in API behaviour. The openssl-users> application asks for a TLS session (of no particular maximum version), openssl-users> and it gets one that both the client library and the peer support. openssl-users> openssl-users> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1 openssl-users> 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? 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. I would prefer if we treated this with *certainties* rather than *probabilities*, and for the moment, it feels like I'm being fed with the latter rather than the former. 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... mta.openssl.org runs Ubuntu 16.04 and the as up to date packages as I get. I prefer to run things with vendor packages, so we have an easy path for updates, and considering that's our central mail hub, I'm not at all keen on potentially screwing things up there. 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. openssl-users> Running an MTA built for 1.1.0 against 1.1.1 libraries openssl-users> might be a reasonable way to "eat our own dog food". Yeeehhh, ya know, I do believe in eating your own dog food, but only to a level. Central production machinery that we all depend on is a big no-no in my admin brain. 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
> 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
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
> On Apr 14, 2018, at 4:18 PM, Richard Levitte wrote: > >> 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? I am suggesting that we ignore test failures that test for rather artificial conditions. If our test negotiates TLS with our own server and tests that it got exactly TLS 1.2 (because that's the highest version our test expected to support by default) that's an artificial test, and its failure is fine. Real applications that want no more than TLS 1.2 need to set the max version, or not expect that maximum. Anything else is an application bug. Do we have any meaningful test failures that are not artificial like the above? If so, we should fix them, if not we possibly need more tests, but are otherwise fine as best we know. -- 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
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
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
> 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
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
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
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
