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

[Viktor Dukhovni]

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

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

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

-- 
Viktor.

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

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

[Salz, Rich]

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

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

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

[Richard Levitte]

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

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

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

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

There's that too, yeah.

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

[openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

[Viktor Dukhovni]

Applications that have hitherto used TLS <= 1.2 have often not needed to use 
SNI.  The extension, though useful for virtual-hosting on the Web, was optional.

TLS 1.3 has raised the status of SNI from optional to "mandatory to implement".
What this means that is that implementations must support it, but it stops of
mandating SNI outright.  Clients SHOULD send SNI, when applicable, and servers
MAY require SNI:

  https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

  -  The "server_name" [RFC6066] and "certificate_authorities"
 extensions are used to guide certificate selection.  As servers
 MAY require the presence of the "server_name" extension, clients
 SHOULD send this extension, when applicable.

  [...]

  Additionally, all implementations MUST support use of the
  "server_name" extension with applications capable of using it.
  Servers MAY require clients to send a valid "server_name" extension.
  Servers requiring this extension SHOULD respond to a ClientHello
  lacking a "server_name" extension by terminating the connection with
  a "missing_extension" alert.

In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all.  Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS.  This has worked
acceptably well with TLS <= 1.2

Along comes 1.3, and suddenly some server operators have become
particularly keen on enforcing all sorts of constraints that at
first blush look rather aggressive.  Specifically, the Google
SMTP servers serving millions of domains (including gmail.com),
now only do TLS 1.3 when SNI is presented, and when SNI is missing,
not only negotiate TLS 1.2, but use an unexpected self-signed cert
chain that validating senders will fail to authenticate, and others
may find perplexing in their logs.  (Thanks to Phil Pennock, Bcc'd
for reporting this on the exim-dev list).

When I link posttls-finger with the OpenSSL 1.1.1 library, I see:

  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 
CommonName invalid2.invalid
  posttls-finger: certificate verification failed for
gmail-smtp-in.l.google.com[173.194.66.26]:25:
self-signed certificate
  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
  posttls-finger: Untrusted TLS connection established to
gmail-smtp-in.l.google.com[173.194.66.26]:25:
TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
so authentication fails where it would typically succeed):

  posttls-finger: certificate verification failed for
gmail-smtp-in.l.google.com[173.194.66.27]:25:
untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
subject_CN=gmail-smtp-in.l.google.com,
issuer_CN=Google Internet Authority G3,
  posttls-finger: Untrusted TLS connection established to
gmail-smtp-in.l.google.com[173.194.66.27]:25:
TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

This is a substantial behaviour change from TLS 1.2, and a rather
poor decision on Google's part IMHO, though I'm eager to learn why
this might have been a good idea.

In the mean-time, Richard's objection to automatic TLS 1.3 use
after shared-library upgrade is starting to look more compelling?

Comments?  [ Especially from David Benjamin, if he's in the loop
on the thinking that might have led to the new behaviour ]

-- 
Viktor.

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

Re: [openssl-project] TLS 1.3 and SNI

[Matt Caswell]

On 17/04/18 23:36, Viktor Dukhovni wrote:
> 
> Just wanted to check.  The TLS 1.3 draft lists SNI as mandatory to implement, 
> but is not mandatory to use.  Clients should, but do not have to send SNI, 
> and servers may require SNI, but can just use some default chain instead.
> 
> Does OpenSSL's TLS 1.3 support mandate SNI in either the client or server?
> 

No. We made changes to s_client to send SNI by default unless you
explicitly request not to. But for applications it's the same story as
always.

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

[openssl-project] TLS 1.3 and SNI

[Viktor Dukhovni]

Just wanted to check.  The TLS 1.3 draft lists SNI as mandatory to implement, 
but is not mandatory to use.  Clients should, but do not have to send SNI, and 
servers may require SNI, but can just use some default chain instead.

Does OpenSSL's TLS 1.3 support mandate SNI in either the client or server?

-- 
Viktor.

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

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

[Viktor Dukhovni]

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

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

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

-- 
Viktor.

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

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

[Richard Levitte]

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

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

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

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

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

[openssl-project] Release done, repository unfrozen

[Richard Levitte]

OpenSSL 1.1.1 pre release 5 done!
Repository is now unfrozen.

Thank you Matt for the review!

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

[openssl-project] OpenSSL verssion 1.1.1 pre release 5 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.1 pre release 5 (beta)
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 5 has now
   been made available. For details of changes and known issues see the
   release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1-pre5.tar.gz
  Size: 8288689
  SHA1 checksum: 8b479a8c555a9eba57b6003e4bd7200dff9535ee
  SHA256 checksum: 
0e5ff2f216cea5fa89af6dcd429c3c142acd7c786b0c4868a039689a2641cf3d

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1-pre5.tar.gz
openssl sha256 openssl-1.1.1-pre5.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlrV93QACgkQ1enkP335
7owHBBAArOo3ChdJyOVRNN9wXPgRJtDTTv22yqadmcgpEiwh5AMWZUCg9Tl8B0BZ
mMcQruV1J0m5qi4mUgBp87ZhqCcOje7uZubyj6VKEAxlklIzyrfPaJyIUWE7CwQi
6jPrMrF9PVkj24DZ/IUPFk6+fJen9POJddeaCuxUM12faZkRD0XxxTEvyKamgou7
Odb/Zn148SFQKMMSVOgaSr0t/go9gJ3vNRaRzBUhG9ZSaxDcwzCaO5OjjwI4xrEY
XnGT54yWJNIvnSsxddhs7q4AUDEa/jNq+iCduPYVbMfuym+7YYMTlKABfnP5i1D2
gd8Ag+2hJe7rtKB6vYKOnyTKJFoMLhoRfJ12N55fJ9L4yLoy5guZEelE2Ib35YWo
twlgQVPu5YnJpZnF0uZTZmcOJruEcQ7e15B8zyZfUIBtqXXg3tcH3QD3noKUYVmf
s8+EfwebwIoLCy8kriO5bogJRVLQHvu1gehTXQa3edrD7iinZzlhdR7UPl9avlnv
7A0XhEiPEqwEmJUdHx/NGH5bydx/cb+oRgB26YTQyqhNw0meQg4znTui/xz2ARE/
r7PWifGhPPAbq8txuj+d8ipDeoyXS46KgR+sF2ncYMS3iQpAddQtCFIU1whpeRip
wGm9uMu41Ba0H3CmUbmgTNU5kE3RCR00kirPiGQfRtf/pwI5zZY=
=vyz+
-END PGP SIGNATURE-
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Constant time by default

[Kurt Roeckx]

On Mon, Apr 16, 2018 at 06:06:33PM +0100, Matt Caswell wrote:
> 
> As I say in the PR (marked as WIP) I am seeking feedback as to whether
> this is something we should pursue now (i.e. for 1.1.1) or later (post
> 1.1.1) or not at all.

A related question I have is, do we consider this security issues,
and does that mean we should backport those changes?


Kurt

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

Re: [openssl-project] Fwd: New Defects reported by Coverity Scan for openssl/openssl

[Matt Caswell]

On 17/04/18 06:06, Dr. Matthias St. Pierre wrote:
> Matt,
> 
> I wasn't aware that I can register for coverity reports (which I just
> did). If no one else has done it yet, I can look into the three drbg
> issues mentioned in your mail.


Great! Thanks

Matt

> 
> Matthias
> 
> BTW: isn't beta release 3 (pre5) due today? There was no announcement of
> a code freeze yet.
> 
> Am 16.04.2018 um 19:47 schrieb Matt Caswell:
>> Can anyone enlighten me as to why I can't find half of these defects in
>> the coverity dashboard? None of the reported defects in the test cases
>> seem to exist any more (and I'm fairly sure we didn't fix them).
>> Actually I didn't think we scanned the tests at all, so I'm a little
>> confused.
>>
>> Matt
>>
> 
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Release of OpenSSL beta release 3 (pre5) happens

[Richard Levitte]

Hi,

just a reminder that we're scheduled to release openssl-1.1.1-pre5
today.

I'll do the release this time.

If someone could freeze the repo for me, I'd be grateful:

ssh openssl-...@git.openssl.org freeze openssl levitte

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