From matt at openssl.org  Mon Oct  1 17:19:50 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 1 Oct 2018 18:19:50 +0100
Subject: [openssl-project] Monthly Status Report (September)
Message-ID: <3f81928a-ec22-4a8d-e8ea-4d2adbdc5fcf@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Spent the week starting 3rd September attending the OpenSSL FIPS
summit in Brisbane. Working on the OpenSSL strategy for FIPS and the
design of the new module.
- Clarified the documentation for the return values of SSL_client_version()
- Fixed the handling of session tickets following a resumption with an
external PSK, i.e. we treat it like a resumption and send one ticket
back to the client
- Updated and merged the fix for handling applications with clients that
only write/servers that only read to avoid EPIPE while sending the new
session tickets
- Fix a problem where we were attempting to use an RSA-PSS cert for key
exchange
- A lot of work tracking and managing the release criteria status in the
lead up to the 1.1.1 release
- Performed the 1.1.1 release
- Merged fixes for the EVP_DigestSign* docs
- Updates to enable processing of NewSessionTickets and KeyUpdate
messages even after we've sent a close_notify
- Fixed a doc error wrt SSL_set_post_handshake_auth()
- Wrote an published a blog entry about the 1.1.1 release
- Fixed a bug in certificate callbacks when used with TLSv1.3
- Fixed a bug where SNI data can get reset mid-handshake
- Fixed a number of issues identified by Coverity
- Improve documentation around the -early_data option to s_server, and
make sure we error out if attempting to use it in conjunction with -www
- Significant and ongoing work on the OpenSSL Strategy and FIPS design
documents
- Fixed a bug with SNI in 1.1.1
- Fixed a bug with max psk len for TLSv1.3
- Fixed some no-* options


Matt

From kurt at roeckx.be  Sun Oct  7 12:48:55 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 7 Oct 2018 14:48:55 +0200
Subject: [openssl-project] Minimum C version
Message-ID: <20181007124854.GA3443@roeckx.be>

Hi,

We're currently still targetting C89/C90 + long long, yet use
various features of C99 and even some C11 when it's available.

C99 is now almost 20 years old, can we please move to at least
that?


Kurt


From levitte at openssl.org  Sun Oct  7 12:58:59 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 07 Oct 2018 14:58:59 +0200 (CEST)
Subject: [openssl-project] Minimum C version
In-Reply-To: <20181007124854.GA3443@roeckx.be>
References: <20181007124854.GA3443@roeckx.be>
Message-ID: <20181007.145859.1942706223512112002.levitte@openssl.org>

In message <20181007124854.GA3443 at roeckx.be> on Sun, 7 Oct 2018 14:48:55 +0200, Kurt Roeckx <kurt at roeckx.be> said:

> We're currently still targetting C89/C90 + long long, yet use
> various features of C99 and even some C11 when it's available.
> 
> C99 is now almost 20 years old, can we please move to at least
> that?

I'd like that.  I've just had a look at the compilers I worry about,
and I see no reason any more to stick with C89/C90.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sun Oct  7 13:33:23 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 7 Oct 2018 15:33:23 +0200
Subject: [openssl-project] Minimum C version
In-Reply-To: <d41ba750-02bf-4655-814c-655276e6df4b@email.android.com>
References: <20181007124854.GA3443@roeckx.be>
 <d41ba750-02bf-4655-814c-655276e6df4b@email.android.com>
Message-ID: <20181007133323.GR22242@roeckx.be>

On Sun, Oct 07, 2018 at 02:01:36PM +0100, David Woodhouse wrote:
> Unfortunately Microsoft still does not support C99, I believe. Or did that get fixed eventually, in a version that can reasonably be required?

That is a very good point, and they never intend to fix that.

So would that mean we say that VC will be unsupported? Or that we
should make it so that it can be build using C++?


Kurt


From tjh at cryptsoft.com  Sun Oct  7 13:46:45 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Sun, 7 Oct 2018 23:46:45 +1000
Subject: [openssl-project] Minimum C version
In-Reply-To: <20181007133323.GR22242@roeckx.be>
References: <20181007124854.GA3443@roeckx.be>
 <d41ba750-02bf-4655-814c-655276e6df4b@email.android.com>
 <20181007133323.GR22242@roeckx.be>
Message-ID: <CAHEJ-S5zARPOQfGDeR-fFTStLGQ4Exr7t4JK9b8_tUJYyoVK=A@mail.gmail.com>

I don't see a *substantial benefit* from going to C99 and I've worked on
numerous embedded platforms where it is highly unlikely that C99 support
will ever be available.

Kurt - do you have a specific list of features you think would be
beneficial - or is it just a general sense to move forward?

We should ensure that C++ builds work - but that is mostly simply keyword
avoidance - but sticking with the base C89/C90 in my experience is still a
reasonable position.

For Microsoft reading
https://social.msdn.microsoft.com/Forums/en-US/fa17bcdd-7165-4645-a676-ef3797b95918/details-on-c99-support-in-msvc?forum=vcgeneral
and
https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/
may
assist.

I know there are Microsoft platforms that require use of earlier compilers
than VS2013 to support (unfortunately).

Tim.


On Sun, Oct 7, 2018 at 11:33 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Sun, Oct 07, 2018 at 02:01:36PM +0100, David Woodhouse wrote:
> > Unfortunately Microsoft still does not support C99, I believe. Or did
> that get fixed eventually, in a version that can reasonably be required?
>
> That is a very good point, and they never intend to fix that.
>
> So would that mean we say that VC will be unsupported? Or that we
> should make it so that it can be build using C++?
>
>
> Kurt
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20181007/4a2db38d/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Oct 11 17:18:03 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 11 Oct 2018 13:18:03 -0400
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
Message-ID: <20181011171802.GL3589@straasha.imrryr.org>


Apparently, some SMTP clients set fallback_scsv when doing TLS 1.2
with Postfix servers using OpenSSL 1.1.1.  Not yet clear whether
they tried TLS 1.3 first and failed, or just sent the SCSV out of
the blue...

See attached.  If this is a common problem, it might be useful to
have a control that tolerates "downgrade" to TLS 1.2, without
disabling TLS 1.3 support.  In many cases, and especially opportunitistic
security, where STARTTLS can be stripped by an MiTM entirely, so
we often can't even prevent downgrades to cleartext, TLS 1.2 is
quite good enough.

-- 
	Viktor.
-------------- next part --------------
An embedded message was scrubbed...
From: Viktor Dukhovni <postfix-users at dukhovni.org>
Subject: Re: postfix & TLS1.3 problems
Date: Thu, 11 Oct 2018 12:53:38 -0400
Size: 4531
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20181011/15b5ffc7/attachment.mht>

From kaduk at mit.edu  Fri Oct 12 00:03:21 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Thu, 11 Oct 2018 19:03:21 -0500
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <20181011171802.GL3589@straasha.imrryr.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
Message-ID: <20181012000321.GA3293@kduck.kaduk.org>

I would guess that the misbehaving clients are early openssl betas
that receive the real TLS 1.3 version and then try to interpret
as whatever draft versino they actually implemnet.

-Ben

On Thu, Oct 11, 2018 at 01:18:03PM -0400, Viktor Dukhovni wrote:
> 
> Apparently, some SMTP clients set fallback_scsv when doing TLS 1.2
> with Postfix servers using OpenSSL 1.1.1.  Not yet clear whether
> they tried TLS 1.3 first and failed, or just sent the SCSV out of
> the blue...
> 
> See attached.  If this is a common problem, it might be useful to
> have a control that tolerates "downgrade" to TLS 1.2, without
> disabling TLS 1.3 support.  In many cases, and especially opportunitistic
> security, where STARTTLS can be stripped by an MiTM entirely, so
> we often can't even prevent downgrades to cleartext, TLS 1.2 is
> quite good enough.
> 
> -- 
> 	Viktor.

> Date: Thu, 11 Oct 2018 12:53:38 -0400
> From: Viktor Dukhovni <postfix-users at dukhovni.org>
> To: postfix-users at postfix.org
> Subject: Re: postfix & TLS1.3 problems
> User-Agent: Mutt/1.10.1 (2018-07-13)
> 
> On Thu, Oct 11, 2018 at 05:54:59PM +0200, A. Schulze wrote:
> 
> > today I noticed a significant amount of TLS failures in my postfix log.
> > 
> > Oct 11 17:43:35 mta postfix/smtpd[23847]: SSL_accept error from  
> > client.example[192.0.2.25]:34152: -1
> > 
> > I traced some sessions and found the problematic client is announcing  
> > the special cipher "TLS_FALLBACK_SCSV"
> > in a TLSv1.2 ClientHello message. Now, as my server support TLSv1.3,  
> > my SSL library (openssl-1.1.1) assume a downgrade attack an close the  
> > connection with an SSL error message "inappropriate fallback"
> > 
> > The core issue is a client with a nonconforming TLS implementation.
> 
> Any idea what software these clients are running?  Are they at all
> likely to fix this any time soon?
> 
> > To circumvent the problem I tried to disable TLS1.3 on my server by setting
> > smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1.3
> > 
> > But that does not help.
> > The Client still fail an deliver the message by falling back to plain text :-/
> > 
> > The only option to force encrypted traffic again would be a library  
> > downgrade on my side.
> > Any other suggestions?
> 
> Support for OpenSSL 1.1.1 and TLS 1.3 is on the list of fixes slated
> for Postfix 3.4, and some may then be backported to patch levels
> of earlier releases.
> 
> In the meantime, try:
> 
>     tls_ssl_options = 0x20000000
> 
> which corresponds to SSL_OP_NO_TLSv1_3.  I am not aware of any
> method to accept the "downgrade" to TLS 1.2 without disabling TLS
> 1.3 for clients that do have correct implementations.
> 
> -- 
> 	Viktor.

> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


From appro at openssl.org  Fri Oct 12 12:01:42 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 12 Oct 2018 14:01:42 +0200
Subject: [openssl-project] dropping out
Message-ID: <05dc51a0-e2b7-ae9c-6967-bcc82d64d058@openssl.org>

I'm dropping out in a week time. It's not some single recent thing, but
combination. I don't see that my perception of project spirit aligns
with current state of affairs. This goes for both technical aspects and
policies (lack of, and/or their applications). One can probably say that
these are misguided expectations, but that's where I draw line for
myself. Another contributing factor is lack of opportunities to pursue
so to say "fundamental" goals, formal validation of assembly code being
one example. Just in case, I don't know what future holds exactly, but
it's not end of "crypto programming" for me, it's just that I won't be
lending my expertise directly/solely to this project on general basis.

As for my e-mail address. I'd like to argue that it would be appropriate
if it remains working for a while after, at the very least to see
through some of ongoing threads. I promise not to use it in context
other than purely technical.

From appro at openssl.org  Fri Oct 12 15:45:34 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 12 Oct 2018 17:45:34 +0200
Subject: [openssl-project] speaking of versioning schemes
Message-ID: <5704cd65-a270-8589-3729-4beb1c566c2b@openssl.org>

As once said, what matters at the end of the day is whether or not
versioning scheme is *accepted* by "downstream". And by "accepted" I
mean to degree that ROBOT wouldn't have happened to Facebook. In other
words first question should not be how to arrange digits and letters,
but rather how to mitigate the apparent tendency to deviate from "upstream".

From openssl-users at dukhovni.org  Fri Oct 12 15:50:22 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 12 Oct 2018 11:50:22 -0400
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <20181012000321.GA3293@kduck.kaduk.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
Message-ID: <20181012155022.GA3589@straasha.imrryr.org>

On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote:

> I would guess that the misbehaving clients are early openssl betas
> that receive the real TLS 1.3 version and then try to interpret
> as whatever draft versino they actually implemnet.

Early, partial reports of the cause seem to indicate that the sending
side was using OpenSSL with:

	SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV);

seemingly despite no prior handshake failure, this is of course
fatally wrong.  But my question remains, should/could we provide a
control that ignores fallback signals from clients, and keeps going?
Either regardless of the resulting protocol version, or perhaps if
it is at least some acceptable floor?

That way, applications like MTAs that do opportunistic TLS, could
keep going with TLS 1.2, since failing to negotiate TLS will typically
result in downgrade to cleartext, rather than protection from TLS
version downgrades.  Such a mechanism might also make it possible
to support connections from a small fraction of broken clients,
without disabling TLS 1.3 globally.

-- 
	Viktor.

From kurt at roeckx.be  Fri Oct 12 16:32:31 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 12 Oct 2018 18:32:31 +0200
Subject: [openssl-project] dropping out
In-Reply-To: <05dc51a0-e2b7-ae9c-6967-bcc82d64d058@openssl.org>
References: <05dc51a0-e2b7-ae9c-6967-bcc82d64d058@openssl.org>
Message-ID: <20181012163230.GA29530@roeckx.be>

On Fri, Oct 12, 2018 at 02:01:42PM +0200, Andy Polyakov wrote:
> Another contributing factor is lack of opportunities to pursue
> so to say "fundamental" goals, formal validation of assembly code being
> one example.

Formal validation of the assembly code is something I would
actually like to see, and even talked with some people about it.
But I don't have the time to actually get this done.


Kurt


From appro at openssl.org  Fri Oct 12 20:59:56 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 12 Oct 2018 22:59:56 +0200
Subject: [openssl-project] dropping out
In-Reply-To: <20181012163230.GA29530@roeckx.be>
References: <05dc51a0-e2b7-ae9c-6967-bcc82d64d058@openssl.org>
 <20181012163230.GA29530@roeckx.be>
Message-ID: <fe9a7621-6dad-7d38-1ca7-722e34f618cf@openssl.org>

>> Another contributing factor is lack of opportunities to pursue
>> so to say "fundamental" goals, formal validation of assembly code being
>> one example.
> 
> Formal validation of the assembly code is something I would
> actually like to see, and even talked with some people about it.
> But I don't have the time to actually get this done.

To clarify. As far as *this* specific remark goes, it's not like I feel
constrained, by policies or anything of the sort. It's rather about
"chronic" failure to find opportunity to put things aside and devote a
concentrated effort. The remark belongs in "what future holds" part. (As
most should know by now, I'm not on good terms with words.)

From matt at openssl.org  Mon Oct 15 13:19:34 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Oct 2018 14:19:34 +0100
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <20181012155022.GA3589@straasha.imrryr.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
 <20181012155022.GA3589@straasha.imrryr.org>
Message-ID: <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>



On 12/10/18 16:50, Viktor Dukhovni wrote:
> On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote:
> 
>> I would guess that the misbehaving clients are early openssl betas
>> that receive the real TLS 1.3 version and then try to interpret
>> as whatever draft versino they actually implemnet.
> 
> Early, partial reports of the cause seem to indicate that the sending
> side was using OpenSSL with:
> 
> 	SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV);
> 
> seemingly despite no prior handshake failure,

Are you sure about the "no prior handshake failure" bit? If they were
using pre6 or below then if they attempt TLSv1.3 first it will fail
(incorrectly - it should negotiation TLSv1.2 see issue 7315). The
fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be
reasonable.

Matt



> this is of course
> fatally wrong.  But my question remains, should/could we provide a
> control that ignores fallback signals from clients, and keeps going?
> Either regardless of the resulting protocol version, or perhaps if
> it is at least some acceptable floor?
> 
> That way, applications like MTAs that do opportunistic TLS, could
> keep going with TLS 1.2, since failing to negotiate TLS will typically
> result in downgrade to cleartext, rather than protection from TLS
> version downgrades.  Such a mechanism might also make it possible
> to support connections from a small fraction of broken clients,
> without disabling TLS 1.3 globally.
> 

From openssl-users at dukhovni.org  Mon Oct 15 17:54:29 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 15 Oct 2018 13:54:29 -0400
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
 <20181012155022.GA3589@straasha.imrryr.org>
 <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>
Message-ID: <84408AA6-ECD1-40A0-93C9-E32B3685A798@dukhovni.org>



> On Oct 15, 2018, at 9:19 AM, Matt Caswell <matt at openssl.org> wrote:
> 
>> Early, partial reports of the cause seem to indicate that the sending
>> side was using OpenSSL with:
>> 
>> 	SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV);
>> 
>> seemingly despite no prior handshake failure,
> 
> Are you sure about the "no prior handshake failure" bit? If they were
> using pre6 or below then if they attempt TLSv1.3 first it will fail
> (incorrectly - it should negotiation TLSv1.2 see issue 7315). The
> fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be
> reasonable.

No, not sure at all, but that's what the receiving system administrator
tells me the sending system administrator told him.  Perhaps they failed
to understand the docs, and always set the fallback bit.  MTAs tend to
not do complex fallback, just send in the clear if opportunistic TLS
fails, or try later and hope things work out better then.

I've not yet received further corroboration.  What do you make of the
idea of making it possible for servers to accept downgrades (to some
floor protocol version or all supported versions)?

-- 
	Viktor.


From matt at openssl.org  Mon Oct 15 17:56:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Oct 2018 18:56:06 +0100
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <84408AA6-ECD1-40A0-93C9-E32B3685A798@dukhovni.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
 <20181012155022.GA3589@straasha.imrryr.org>
 <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>
 <84408AA6-ECD1-40A0-93C9-E32B3685A798@dukhovni.org>
Message-ID: <db2b96db-7912-ac2a-fd6d-3f2dbb3cb30b@openssl.org>



On 15/10/18 18:54, Viktor Dukhovni wrote:
> 
> 
>> On Oct 15, 2018, at 9:19 AM, Matt Caswell <matt at openssl.org> wrote:
>>
>>> Early, partial reports of the cause seem to indicate that the sending
>>> side was using OpenSSL with:
>>>
>>> 	SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV);
>>>
>>> seemingly despite no prior handshake failure,
>>
>> Are you sure about the "no prior handshake failure" bit? If they were
>> using pre6 or below then if they attempt TLSv1.3 first it will fail
>> (incorrectly - it should negotiation TLSv1.2 see issue 7315). The
>> fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be
>> reasonable.
> 
> No, not sure at all, but that's what the receiving system administrator
> tells me the sending system administrator told him.  Perhaps they failed
> to understand the docs, and always set the fallback bit.  MTAs tend to
> not do complex fallback, just send in the clear if opportunistic TLS
> fails, or try later and hope things work out better then.
> 
> I've not yet received further corroboration.  What do you make of the
> idea of making it possible for servers to accept downgrades (to some
> floor protocol version or all supported versions)?
> 

I'm really not keen on that idea at all.

Matt


From openssl-users at dukhovni.org  Mon Oct 15 19:41:06 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 15 Oct 2018 15:41:06 -0400
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <db2b96db-7912-ac2a-fd6d-3f2dbb3cb30b@openssl.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
 <20181012155022.GA3589@straasha.imrryr.org>
 <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>
 <84408AA6-ECD1-40A0-93C9-E32B3685A798@dukhovni.org>
 <db2b96db-7912-ac2a-fd6d-3f2dbb3cb30b@openssl.org>
Message-ID: <20181015194106.GD983@straasha.imrryr.org>

On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote:

> > What do you make of the
> > idea of making it possible for servers to accept downgrades (to some
> > floor protocol version or all supported versions)?
> 
> I'm really not keen on that idea at all.

I understand the healthy skepticism, but it may worthwhile to keep
in mind that for SMTP the consequence of not accepting fallback to
TLS 1.2, is accepting fallback to cleartext!  So protocol downgrade
protection looks somewhat silly.

The only counter-argument I can think of is that some clients in
fact do mandatory authenticated TLS (e.g. with DANE, MTA-STS or
local policy), and they will not fall back to cleartext.  On the
other hand, no MTA I know of does attempts (valid) browser-style
protocol fallback after a connection failure.  So the clients that
insist on security (Postfix, Exim, ...) just defer the mail when
the TLS handshake fails.

In the SMTP ecosystem enforcing FALLBACK_SCSV is pretty much
counter-productive (only reduces security to cleartext for opportunistic
clients, and does not at all help non-opportunistic clients get
through to servers that don't support TLS 1.3, and fail the handshake
if you try).

-- 
	Viktor.

From matt at openssl.org  Tue Oct 16 07:33:32 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 16 Oct 2018 08:33:32 +0100
Subject: [openssl-project] FYI: [postfix & TLS1.3 problems]
In-Reply-To: <20181015194106.GD983@straasha.imrryr.org>
References: <20181011171802.GL3589@straasha.imrryr.org>
 <20181012000321.GA3293@kduck.kaduk.org>
 <20181012155022.GA3589@straasha.imrryr.org>
 <75e78d91-7f45-0578-c706-42e6d1990a8e@openssl.org>
 <84408AA6-ECD1-40A0-93C9-E32B3685A798@dukhovni.org>
 <db2b96db-7912-ac2a-fd6d-3f2dbb3cb30b@openssl.org>
 <20181015194106.GD983@straasha.imrryr.org>
Message-ID: <a4a5eccd-152a-272c-a562-af09a4873564@openssl.org>



On 15/10/18 20:41, Viktor Dukhovni wrote:
> On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote:
> 
>>> What do you make of the
>>> idea of making it possible for servers to accept downgrades (to some
>>> floor protocol version or all supported versions)?
>>
>> I'm really not keen on that idea at all.
> 
> I understand the healthy skepticism, but it may worthwhile to keep
> in mind that for SMTP the consequence of not accepting fallback to
> TLS 1.2, is accepting fallback to cleartext!  So protocol downgrade
> protection looks somewhat silly.
> 
> The only counter-argument I can think of is that some clients in
> fact do mandatory authenticated TLS (e.g. with DANE, MTA-STS or
> local policy), and they will not fall back to cleartext.  On the
> other hand, no MTA I know of does attempts (valid) browser-style
> protocol fallback after a connection failure.  So the clients that
> insist on security (Postfix, Exim, ...) just defer the mail when
> the TLS handshake fails.
> 
> In the SMTP ecosystem enforcing FALLBACK_SCSV is pretty much
> counter-productive (only reduces security to cleartext for opportunistic
> clients, and does not at all help non-opportunistic clients get
> through to servers that don't support TLS 1.3, and fail the handshake
> if you try).
> 

I think we should do more to understand the current problem before going
any further down this route. If this is caused by pre6 or below OpenSSL
clients then I don't think we should be making any changes to
accommodate them.

Matt

From kurt at roeckx.be  Tue Oct 16 20:15:31 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 16 Oct 2018 22:15:31 +0200
Subject: [openssl-project] Current priorities
In-Reply-To: <20180918180611.GA2053@roeckx.be>
References: <20180918180611.GA2053@roeckx.be>
Message-ID: <20181016201531.GA7509@roeckx.be>

On Tue, Sep 18, 2018 at 08:06:12PM +0200, Kurt Roeckx wrote:
> The open PRs were around 100 when 1.1.0 was released, and have
> been around 120 for a very long time, but the last few months it has
> grown to around 150. I guess we have some that are waiting because
> they are new features that didn't go in 1.1.1. But I would like to
> get the number of open PRs to around 100, but even lower is of
> course even better.

We currently at 176 open PR, that's 25 more open PRs 1 month
later.


Kurt


From paul.dale at oracle.com  Mon Oct 29 01:09:45 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Sun, 28 Oct 2018 18:09:45 -0700 (PDT)
Subject: [openssl-project] Low severity timing attack in ECDSA
	(CVE-2018-0735)
Message-ID: <65ac4276-79b0-48fa-88d2-98ff52ad8cf8@default>

Timing vulnerability in ECDSA signature generation (CVE-2018-0735)
==================================================================

Severity: Low

The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.

Due to the low severity of this issue we are not issuing a new release
of OpenSSL 1.1.1 or 1.1.0 at this time. The fix will be included in
OpenSSL 1.1.1a and OpenSSL 1.1.0j when they become available. The fix
is also available in commit b1d6d55ece (for 1.1.1) and commit 56fb454d28
(for 1.1.0) in the OpenSSL git repository.

This issue was reported to OpenSSL on 25th October 2018 by Samuel Weiser.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20181029.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html



Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From paul.dale at oracle.com  Mon Oct 29 09:45:36 2018
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Mon, 29 Oct 2018 19:45:36 +1000
Subject: [openssl-project] Review
Message-ID: <785270DB-E18C-4C5A-A961-765859CD6B23@oracle.com>

I?d like a prompt review of #7513 so I can push the second CVE out.
#7512 is kind of related but not CVE level.


Pauli


From levitte at openssl.org  Mon Oct 29 10:21:39 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 29 Oct 2018 11:21:39 +0100 (CET)
Subject: [openssl-project] Review
In-Reply-To: <785270DB-E18C-4C5A-A961-765859CD6B23@oracle.com>
References: <785270DB-E18C-4C5A-A961-765859CD6B23@oracle.com>
Message-ID: <20181029.112139.181248863860316684.levitte@openssl.org>

In message <785270DB-E18C-4C5A-A961-765859CD6B23 at oracle.com> on Mon, 29 Oct 2018 19:45:36 +1000, Dr Paul Dale <paul.dale at oracle.com> said:

> I?d like a prompt review of #7513 so I can push the second CVE out.
> #7512 is kind of related but not CVE level.

Done

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From paul.dale at oracle.com  Mon Oct 29 11:09:43 2018
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Mon, 29 Oct 2018 21:09:43 +1000
Subject: [openssl-project] Review
In-Reply-To: <20181029.112139.181248863860316684.levitte@openssl.org>
References: <785270DB-E18C-4C5A-A961-765859CD6B23@oracle.com>
 <20181029.112139.181248863860316684.levitte@openssl.org>
Message-ID: <CA939A23-56B1-4614-9259-42FBE25A0AC8@oracle.com>

Thanks, Richard.  I?ll merge tomorrow and publish CVE 20181030.

Pauli


> On 29 Oct 2018, at 8:21 pm, Richard Levitte <levitte at openssl.org> wrote:
> 
> In message <785270DB-E18C-4C5A-A961-765859CD6B23 at oracle.com> on Mon, 29 Oct 2018 19:45:36 +1000, Dr Paul Dale <paul.dale at oracle.com> said:
> 
>> I?d like a prompt review of #7513 so I can push the second CVE out.
>> #7512 is kind of related but not CVE level.
> 
> Done
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


From paul.dale at oracle.com  Mon Oct 29 21:03:59 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 29 Oct 2018 14:03:59 -0700 (PDT)
Subject: [openssl-project] Low severity timing attack in DSA (CVE-2018-0734)
Message-ID: <227e9c98-90e5-47ed-b548-1b3bff5de66b@default>

Timing vulnerability in DSA signature generation (CVE-2018-0734) 
================================================================ 
  
Severity: Low 
  
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a 
timing side channel attack. An attacker could use variations in the signing 
algorithm to recover the private key. 
  
Due to the low severity of this issue we are not issuing a new release 
of OpenSSL 1.1.1, 1.1.0 or 1.0.2 at this time. The fix will be included 
in OpenSSL 1.1.1a, OpenSSL 1.1.0j and OpenSSL 1.0.2q when they become 
available. The fix is also available in commit 8abfe72e8c (for 1.1.1), 
ef11e19d13 (for 1.1.0) and commit 43e6a58d49 (for 1.0.2) in the OpenSSL 
git repository. 
  
This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser. 
  
References 
========== 
  
URL for this Security Advisory: 
https://www.openssl.org/news/secadv/20181030.txt 
  
Note: the online version of the advisory may be updated with additional details 
over time. 
  
For details of OpenSSL severity classifications please see: 
https://www.openssl.org/policies/secpolicy.html <https://www.openssl.org/policies/secpolicy.html> 
  
  
Pauli 
-- 
Oracle 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217 
Oracle Australia 
  

-----BEGIN PGP MESSAGE----- 
Version: GnuPG v2 

owGlVGtsFFUU3j4kMHRThCYEELyQCm3ZZ7cvCkUXlodSaNltEaSF3s7c3Rk6O3eZ 
me2wWOWRtipSqaFQEBAt8ggEtVSKUiQQEaxEQXkUKAjlIZZHKVVIsJh4Z7pLiz9M 
jDubzJ17znzn+8755lbqI3S9w9qbpw8/fMppDTt+q1A3t8n/eQ7n5QQPKPbzAhJh 
IcdzcgBwAnC47EDiPAKU/SICHqRGZQ4LIG7irEnGRIs1zWhJtSXF66mM//nTU0BP 
uVAxEknpdJCJFW0nh0Ugy4cElyvzH2Qg78Ekl/UCFkqgECEBSCxWBCBj8vRECo/U 
Dain5C6JEscgQLNQEBAPoCxDusgE7EJwiURAYz/PAL9EIKDIaWoltRUyYaJWJyB6 
qrs4ARcRjQlvLcMncsVQRqAIBUyaAIdfI6DGeKwAKagQYDfZ4wiyJJEMheghmgQs 
axsqUQgEpBBsHkEJ6SmSH+qD1UQug3azACyShcWUSAR0ARKdyATUvrm5RUDheF5t 
ByfQvJ9BjJ4iUp4Cgoanni0LABSYHlsEeyFQWKR1IECwaOwlfGAx5Hi1vd21SHHI 
S6TZoZDaNpLt5WSQBgvdKDURpdEgzq1xJle8QU8ht9WKrGMYq607YInXOARfTbKh 
FJicxiSNCWUQSvGhkQSJ6ikPSRWRD0ucjMVg83N6dJiYRA2LMmLUgYQEEi9bU2QW 
ZNEyLiRDVD0NCgPABb1+4pBXESchsQvNidxIRAKNpJ5210K5zkygctMm4EK0X5ux 
nSnmJEImXU+xsuyT0s1mRVFMmJSWJN6ERY+ZzFgyS4iGTLFZLW212CwmeZGsoc7A 
MkrXVGKB5wTiSCRK6tenmYdYJogPvFAdDPD7GKjKU4gzSZDhVPNCHjBIJhMhrLts 
qhpEw59MGB8qCEZBD4c9cSnNQ0ni3Bwd/A58mhtJHP2LJh/mOZpDmi5tHTCxspcH 
4/7jC+OBxpL8s6Gf5/SU0UjWWSKkeWJAhwjUbeCAxGglYKIY8MnYI0IfSzSWgBlI 
VrBY1D2MkWCSQKtJagMJJItJQ0enWEEqsFls5JZoTQ2hA7tfkkXIc+TcAO+EPxep 
C+ut6/VMuHpU6qg+/ULn5+N70Y+j+lWuPFFfv3VnR+ydNvn7BuNiZppp5qOpytsv 
dxTZyyOX13x897uduWt2Xq5/ccINV0ZceEHDVbFyx7bzx6rfYHJbBsyPBZ0j4w7U 
Xg6PnLNw3wZzY1TM7YJ555K/eeDsXdJ/q27jlb5jseXi/Y6Mt/JMB2uMRdKttXtG 
n//MsKrk9B8FWa1U1keXTj2y39V9vX/28gGrGsfsurNp4xex7KOqptboHMdiHlyq 
s+3ZPHzfjCUroLO67MvM9rKfA5uyJ9qGrIsurWialbnDvf/H/Pdf6uyztPWIcXPY 
uxsmiGej7g9aPWp0xoq9+bveq+i8Oflk9Q9VK2L61rKzY/JeH5LvPlbnzvsp1jgq 
e430uHbKhG/bq9ZPP3ArwdZ25mFt0tznqZw+eCAcVtpyIdxnoE7v2sJUJiRfwW8O 
Przl3gtO8UjOgbas+jNjP4mxrj2uNNyYEzHCXXezPL/loX3l7311Z8Vq5y/nfru6 
yV1f4ZvuHTSt2Tgs8VO2ctzA/rVFEWUXI6p/NQyu2F4W3XRt37ENSzvm8MuTbzfY 
Fh3EzzZc+qv1+itLpuz5oH3mqqXNkVtLdLsf1kZtnLqs+c91pvmZ/hrdA8OCxpM1 
WRWrz+5tdpe3DC2lxl24OHTEMsfhlFkJjeOvxc9bb9zeWNpYZ9/RfvS1rxznK2q2 
3anPjumEebkR5vEfnqi6ktCr39Hd1+MPTdO1/Q0= 
=VVHo 
-----END PGP MESSAGE----- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20181029/c1fd850c/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Tue Oct 30 19:23:52 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 30 Oct 2018 19:23:52 +0000
Subject: [openssl-project] Random devices in chroot environments revisited
Message-ID: <9f1d1c38b9a04c5eac7c1e4bad853676@Ex13.ncp.local>

Hi,

I'd like to recall that the following issue

    #7419 - RAND_keep_random_devices_open not working

still needs to be fixed until 1.1.1a and that currently there are two
alternative approaches for doing it:

    #7429 - Conditionally open random devices on initialization
    #7437 - rand_unix.c: open random devices on first use only 

A short recall of the background story: In pull request

    #6432 - Keep /dev/random open for seeding

a regression was fixed that affected applications in chroot environments.
It compensated the fact that the new OpenSSL CSPRNG now reseeds
periodically, which the previous one didn't.

The solution was to open all random devices early and keep them
open.  An API call (RAND_keep_random_devices_open()) was added
for the application to opt-out from this behaviour.

In issue #7419 it was reported that this opt-out did not work as expected.

*  Pull request #7429 fixes the opt-out issue but remains along the lines of
    the initial solution #7432. This approach has the side effect that the
    random devices are always opened, even if they are never used
    (for example, because getrandom() is available). Even more, if the
    application forks and execs, these handles will be left open and unused
    in the child process.

    An application which does not want this behavior, could explicitly opt-out,
    but this would require a recompilation, which is somewhat contrary to
    the assumptions of the initial chroot problem.

*  Pull request #7429 works without explicit opt-out, because it opens the
    random devices on first use only (and then keeps them open, unless
    the opt-out was called). The advantage of this approach: If getrandom()
    is available and working, the opening will never happen.

    The lazy opening does not add a regression for applications compiled
    against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
    on first use, too. So also with 1.1.0 it was necessary to initialize the
    CSPRNG properly before chrooting (unless the random device was
    mounted into the chroot jail).

Your thoughts?

Matthias


From kurt at roeckx.be  Tue Oct 30 21:03:22 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 30 Oct 2018 22:03:22 +0100
Subject: [openssl-project] Random devices in chroot environments
	revisited
In-Reply-To: <9f1d1c38b9a04c5eac7c1e4bad853676@Ex13.ncp.local>
References: <9f1d1c38b9a04c5eac7c1e4bad853676@Ex13.ncp.local>
Message-ID: <20181030210321.GA1449@roeckx.be>

On Tue, Oct 30, 2018 at 07:23:52PM +0000, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> I'd like to recall that the following issue
> 
>     #7419 - RAND_keep_random_devices_open not working
> 
> still needs to be fixed until 1.1.1a and that currently there are two
> alternative approaches for doing it:
> 
>     #7429 - Conditionally open random devices on initialization
>     #7437 - rand_unix.c: open random devices on first use only 
> 
> A short recall of the background story: In pull request
> 
>     #6432 - Keep /dev/random open for seeding
> 
> a regression was fixed that affected applications in chroot environments.
> It compensated the fact that the new OpenSSL CSPRNG now reseeds
> periodically, which the previous one didn't.
> 
> The solution was to open all random devices early and keep them
> open.  An API call (RAND_keep_random_devices_open()) was added
> for the application to opt-out from this behaviour.
> 
> In issue #7419 it was reported that this opt-out did not work as expected.
> 
> *  Pull request #7429 fixes the opt-out issue but remains along the lines of
>     the initial solution #7432. This approach has the side effect that the
>     random devices are always opened, even if they are never used
>     (for example, because getrandom() is available). Even more, if the
>     application forks and execs, these handles will be left open and unused
>     in the child process.
> 
>     An application which does not want this behavior, could explicitly opt-out,
>     but this would require a recompilation, which is somewhat contrary to
>     the assumptions of the initial chroot problem.
> 
> *  Pull request #7429 works without explicit opt-out, because it opens the

#7437 I guess

>     random devices on first use only (and then keeps them open, unless
>     the opt-out was called). The advantage of this approach: If getrandom()
>     is available and working, the opening will never happen.
> 
>     The lazy opening does not add a regression for applications compiled
>     against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
>     on first use, too. So also with 1.1.0 it was necessary to initialize the
>     CSPRNG properly before chrooting (unless the random device was
>     mounted into the chroot jail).
> 
> Your thoughts?

I prefer the option where it doesn't get opened if getrandom() is
avialable.


Kurt


From Matthias.St.Pierre at ncp-e.com  Tue Oct 30 23:04:23 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 30 Oct 2018 23:04:23 +0000
Subject: [openssl-project] Random devices in chroot
	environments	revisited
In-Reply-To: <20181030210321.GA1449@roeckx.be>
References: <9f1d1c38b9a04c5eac7c1e4bad853676@Ex13.ncp.local>
 <20181030210321.GA1449@roeckx.be>
Message-ID: <b1f31a42d434432fb9f44eb77f74f73b@Ex13.ncp.local>


> > ... currently there are two alternative approaches for doing it:
> >
> >     #7429 - Conditionally open random devices on initialization
> >     #7437 - rand_unix.c: open random devices on first use only
> > ...
> > *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> >     the initial solution #7432. ...
> >
> > *  Pull request #7429 works without explicit opt-out, because it opens the
> >     random devices on first use only ...
> 
> #7437 I guess

Yes, thanks for the correction. A typical copy&paste error. 

Matthias