>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
> 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
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
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> > simpl
> 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.
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 pro
> 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
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
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 t
> 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
& 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
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
> me
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 co
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. d
> 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
> tes
> 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 bec
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 A
> 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. Ho
> 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
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 app
> 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
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 everythi
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 li
> 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", i
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
> 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
te
> 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 mak
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
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 t
> 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
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
> 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 sugg
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:
open
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
> 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 say
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
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.
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. t
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 should
39 matches
Mail list logo
