More GitHub labels

[Dr Paul Dale]

Just wondering if we should have two new labels: “hold: tests needed” and 
“hold: documentation needed” labels?
There are a number of PRs that come through where one or both of these are 
missing (this post posed by @slontis’s comment in 12826 
).

These would give a clear indication of what additional material is being 
expected as per CLA required and need rebase.

A “hold: code needed" seems less useful :)


Thoughts or should we just add them?


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia

Re: Reordering new API's that have a libctx, propq

[Dr Paul Dale]

Still no need for the added complexity:

Push:
OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);

Pop is:
OPENSSL_CTX_set0_default(prevctx);

Push before callback:
OPENSSL_CTX_set0_default(prevctx);

Pop after callback:
prevctx = OPENSSL_CTX_set0_default(libctx);
or
OPENSSL_CTX_set0_default(libctx);
Depending if we want to support call backs changing the Libctx directly — we 
should choose one and always recommend that.


Also the auto allocation of storage for the second on stack cannot fail, so no 
error checking spaghetti.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 10 Sep 2020, at 12:08 am, Tomas Mraz  wrote:
> 
> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
>>> On 9 Sep 2020, at 9:38 pm, Tomas Mraz  wrote:
>>> 
>>> We could even provide a convenience thread local stack of lib
>>> contexts
>>> so the caller would not have to keep the old value but would just
>>> push
>>> the new libctx when entering and pop the old one when leaving. With
>>> that, I think the changes needed in the application code would be
>>> fairly simple and minimal.
>> 
>> Let’s not overcomplicate things.
>> We went through this discussion back when this was introduced.
>> 
>> 
>> Push is:
>>OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
>> 
>> Pop is:
>>OPENSSL_CTX_set0_default(prevctx)
>> 
>> 
>> I don’t see having an explicit stack of these is of any benefit to
>> anything but unwarranted complexity.
> 
> There is one thing where it would be IMO helpful - let's say libcurl
> has a callback into a calling application. With the current API in
> libcurl API calls you would put the
> calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
> ) at the beginning and end. But you would have to save the prevctx
> somewhere in the libcurl context structure because on callbacks you
> would have to temoprarily reset the context to the prevctx value. If we
> implemented real stack it would not be needed. But yeah, I am not sure
> this convenience is that much worth it.
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>  Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]

Re: Reordering new API's that have a libctx, propq

[Richard Levitte]

On Wed, 09 Sep 2020 16:08:10 +0200,
Tomas Mraz wrote:
> 
> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
> > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz  wrote:
> > > 
> > > We could even provide a convenience thread local stack of lib
> > > contexts
> > > so the caller would not have to keep the old value but would just
> > > push
> > > the new libctx when entering and pop the old one when leaving. With
> > > that, I think the changes needed in the application code would be
> > > fairly simple and minimal.
> > 
> > Let’s not overcomplicate things.
> > We went through this discussion back when this was introduced.
> > 
> > 
> > Push is:
> > OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> > 
> > Pop is:
> > OPENSSL_CTX_set0_default(prevctx)
> > 
> > 
> > I don’t see having an explicit stack of these is of any benefit to
> > anything but unwarranted complexity.
> 
> There is one thing where it would be IMO helpful - let's say libcurl
> has a callback into a calling application. With the current API in
> libcurl API calls you would put the
> calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
> ) at the beginning and end. But you would have to save the prevctx
> somewhere in the libcurl context structure because on callbacks you
> would have to temoprarily reset the context to the prevctx value. If we
> implemented real stack it would not be needed. But yeah, I am not sure
> this convenience is that much worth it.

A stack becomes potentially extra churn in memory allocation for every
push, and wondering what to do with the stack if the stack
functionality fails.  So yeah, I'm thinking that it's not really worth
it.

Cheers,
Richard

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

Re: Reordering new API's that have a libctx, propq

[Tomas Mraz]

On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
> > On 9 Sep 2020, at 9:38 pm, Tomas Mraz  wrote:
> > 
> > We could even provide a convenience thread local stack of lib
> > contexts
> > so the caller would not have to keep the old value but would just
> > push
> > the new libctx when entering and pop the old one when leaving. With
> > that, I think the changes needed in the application code would be
> > fairly simple and minimal.
> 
> Let’s not overcomplicate things.
> We went through this discussion back when this was introduced.
> 
> 
> Push is:
> OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> 
> Pop is:
> OPENSSL_CTX_set0_default(prevctx)
> 
> 
> I don’t see having an explicit stack of these is of any benefit to
> anything but unwarranted complexity.

There is one thing where it would be IMO helpful - let's say libcurl
has a callback into a calling application. With the current API in
libcurl API calls you would put the
calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
) at the beginning and end. But you would have to save the prevctx
somewhere in the libcurl context structure because on callbacks you
would have to temoprarily reset the context to the prevctx value. If we
implemented real stack it would not be needed. But yeah, I am not sure
this convenience is that much worth it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: Reordering new API's that have a libctx, propq

[Richard Levitte]

On Wed, 09 Sep 2020 13:38:42 +0200,
Tomas Mraz wrote:
> > Regarding model 3, it must be said that there is potential for
> > confusion
> > on what it's supposed to do, replace the default property query
> > string
> > (settable with EVP_set_default_properties()), or merge with it.
> > Remember that a property query string given through any XXX_fetch()
> > function is temporarly merged with the default properties when
> > looking
> > for fitting algorithms.
> 
> Here I would actually argue, that there should be another property
> query in the libctx in addition to the default, that would have the
> exactly same semantics as the propq parameter has now and for the
> functions with the propq parameter it even would not be applied. How to
> name it so it won't be confused with the default property query, that's
> hard to say though.

"current" was mentioned several times during yesterday's videocall,
that could actually be used for a name.

I'm ok with putting such a property query string into the library
context, As Long As there is the understanding that it's not *tied*
to that library context, i.e. it can be used to pass a property query
string on to a provider implementation, to be used with whatever
library context the provider uses (the FIPS module has its own, for
example).

Side note: the function OPENSSL_CTX_set0_default() is a confusing
name, as there's an internal default ("default default", "ultimate
default"?) library context already, it's possible that we should
rename that to OPENSSL_CTX_set0_current().

Cheers,
Richard

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

Re: OpenSSL Security Advisory

[Dmitry Belyavsky]

Many thanks!

On Wed, Sep 9, 2020 at 4:16 PM Mark J Cox  wrote:

> I just spotted it via twitter, https://raccoon-attack.com/
>
> Mark
>
> On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky  wrote:
> >
> > Could you please let me know when it is available?
> >
> > On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox  wrote:
> >>
> >> They should be releasing their paper very soon (today).
> >>
> >> Regards, Mark
> >>
> >> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky 
> wrote:
> >> >
> >> > Is the description of the attack publicly available?
> >> >
> >> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
> >> >>
> >> >> -BEGIN PGP SIGNED MESSAGE-
> >> >> Hash: SHA512
> >> >>
> >> >> OpenSSL Security Advisory [09 September 2020]
> >> >> =
> >> >>
> >> >> Raccoon Attack (CVE-2020-1968)
> >> >> ==
> >> >>
> >> >> Severity: Low
> >> >>
> >> >> The Raccoon attack exploits a flaw in the TLS specification which
> can lead to
> >> >> an attacker being able to compute the pre-master secret in
> connections which
> >> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case
> this would
> >> >> result in the attacker being able to eavesdrop on all encrypted
> communications
> >> >> sent over that TLS connection. The attack can only be exploited if an
> >> >> implementation re-uses a DH secret across multiple TLS connections.
> Note that
> >> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
> >> >>
> >> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH
> secret and
> >> >> does not implement any "static" DH ciphersuites.
> >> >>
> >> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> >> >> ciphersuite is used. These static "DH" ciphersuites are ones that
> start with the
> >> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA
> names for these
> >> >> ciphersuites all start with "TLS_DH_" but excludes those that start
> with
> >> >> "TLS_DH_anon_".
> >> >>
> >> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple
> TLS
> >> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE
> option was
> >> >> explicitly configured. Therefore all ciphersuites that use DH in
> servers
> >> >> (including ephemeral DH) are vulnerable in these versions. In
> OpenSSL 1.0.2f
> >> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned
> off as a
> >> >> response to CVE-2016-0701.
> >> >>
> >> >> Since the vulnerability lies in the TLS specification, fixing the
> affected
> >> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> >> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> >> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely
> to cause
> >> >> interoperability problems in most cases since use of these
> ciphersuites is rare.
> >> >> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> >> >> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
> >> >>
> >> >> OpenSSL 1.0.2 is out of support and no longer receiving public
> updates.
> >> >>
> >> >> Premium support customers of OpenSSL 1.0.2 should upgrade to
> 1.0.2w.  If
> >> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should
> ensure
> >> >> that affected ciphersuites are disabled through runtime
> configuration. Also
> >> >> note that the affected ciphersuites are only available on the server
> side if a
> >> >> DH certificate has been configured. These certificates are very
> rarely used and
> >> >> for this reason this issue has been classified as LOW severity.
> >> >>
> >> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod
> Aviram and Juraj
> >> >> Somorovsky and report

Re: OpenSSL Security Advisory

[Mark J Cox]

I just spotted it via twitter, https://raccoon-attack.com/

Mark

On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky  wrote:
>
> Could you please let me know when it is available?
>
> On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox  wrote:
>>
>> They should be releasing their paper very soon (today).
>>
>> Regards, Mark
>>
>> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky  wrote:
>> >
>> > Is the description of the attack publicly available?
>> >
>> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
>> >>
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA512
>> >>
>> >> OpenSSL Security Advisory [09 September 2020]
>> >> =
>> >>
>> >> Raccoon Attack (CVE-2020-1968)
>> >> ==
>> >>
>> >> Severity: Low
>> >>
>> >> The Raccoon attack exploits a flaw in the TLS specification which can 
>> >> lead to
>> >> an attacker being able to compute the pre-master secret in connections 
>> >> which
>> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this 
>> >> would
>> >> result in the attacker being able to eavesdrop on all encrypted 
>> >> communications
>> >> sent over that TLS connection. The attack can only be exploited if an
>> >> implementation re-uses a DH secret across multiple TLS connections. Note 
>> >> that
>> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>> >>
>> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH 
>> >> secret and
>> >> does not implement any "static" DH ciphersuites.
>> >>
>> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
>> >> ciphersuite is used. These static "DH" ciphersuites are ones that start 
>> >> with the
>> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for 
>> >> these
>> >> ciphersuites all start with "TLS_DH_" but excludes those that start with
>> >> "TLS_DH_anon_".
>> >>
>> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
>> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
>> >> explicitly configured. Therefore all ciphersuites that use DH in servers
>> >> (including ephemeral DH) are vulnerable in these versions. In OpenSSL 
>> >> 1.0.2f
>> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off 
>> >> as a
>> >> response to CVE-2016-0701.
>> >>
>> >> Since the vulnerability lies in the TLS specification, fixing the affected
>> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
>> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
>> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to 
>> >> cause
>> >> interoperability problems in most cases since use of these ciphersuites 
>> >> is rare.
>> >> Support for the "weak-ssl-ciphers" can be added back by configuring 
>> >> OpenSSL at
>> >> compile time with the "enable-weak-ssl-ciphers" option. This is not 
>> >> recommended.
>> >>
>> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>> >>
>> >> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
>> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should 
>> >> ensure
>> >> that affected ciphersuites are disabled through runtime configuration. 
>> >> Also
>> >> note that the affected ciphersuites are only available on the server side 
>> >> if a
>> >> DH certificate has been configured. These certificates are very rarely 
>> >> used and
>> >> for this reason this issue has been classified as LOW severity.
>> >>
>> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram 
>> >> and Juraj
>> >> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in 
>> >> order to
>> >> allow co-ordinated disclosure with other implementations.
>> >>
>> >> Note
>> >> 

Re: OpenSSL Security Advisory

[Dmitry Belyavsky]

Could you please let me know when it is available?

On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox  wrote:

> They should be releasing their paper very soon (today).
>
> Regards, Mark
>
> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky  wrote:
> >
> > Is the description of the attack publicly available?
> >
> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> OpenSSL Security Advisory [09 September 2020]
> >> =
> >>
> >> Raccoon Attack (CVE-2020-1968)
> >> ==
> >>
> >> Severity: Low
> >>
> >> The Raccoon attack exploits a flaw in the TLS specification which can
> lead to
> >> an attacker being able to compute the pre-master secret in connections
> which
> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this
> would
> >> result in the attacker being able to eavesdrop on all encrypted
> communications
> >> sent over that TLS connection. The attack can only be exploited if an
> >> implementation re-uses a DH secret across multiple TLS connections.
> Note that
> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
> >>
> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH
> secret and
> >> does not implement any "static" DH ciphersuites.
> >>
> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> >> ciphersuite is used. These static "DH" ciphersuites are ones that start
> with the
> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names
> for these
> >> ciphersuites all start with "TLS_DH_" but excludes those that start with
> >> "TLS_DH_anon_".
> >>
> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE option
> was
> >> explicitly configured. Therefore all ciphersuites that use DH in servers
> >> (including ephemeral DH) are vulnerable in these versions. In OpenSSL
> 1.0.2f
> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned
> off as a
> >> response to CVE-2016-0701.
> >>
> >> Since the vulnerability lies in the TLS specification, fixing the
> affected
> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to
> cause
> >> interoperability problems in most cases since use of these ciphersuites
> is rare.
> >> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> >> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
> >>
> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> >>
> >> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should
> ensure
> >> that affected ciphersuites are disabled through runtime configuration.
> Also
> >> note that the affected ciphersuites are only available on the server
> side if a
> >> DH certificate has been configured. These certificates are very rarely
> used and
> >> for this reason this issue has been classified as LOW severity.
> >>
> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram
> and Juraj
> >> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in
> order to
> >> allow co-ordinated disclosure with other implementations.
> >>
> >> Note
> >> 
> >>
> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> Extended
> >> support is available for premium support customers:
> >> https://www.openssl.org/support/contracts.html
> >>
> >> OpenSSL 1.1.0 is out of support and no longer receiving updates of any
> kind.
> >> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
> >>
> >> Users of these versions should upgrade to OpenSSL 1.1.1.
> >>
> >> References
> >> ==
> >>
> >> URL for this Security Advisory:
> &

Re: OpenSSL Security Advisory

[Mark J Cox]

They should be releasing their paper very soon (today).

Regards, Mark

On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky  wrote:
>
> Is the description of the attack publicly available?
>
> On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> OpenSSL Security Advisory [09 September 2020]
>> =
>>
>> Raccoon Attack (CVE-2020-1968)
>> ==
>>
>> Severity: Low
>>
>> The Raccoon attack exploits a flaw in the TLS specification which can lead to
>> an attacker being able to compute the pre-master secret in connections which
>> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would
>> result in the attacker being able to eavesdrop on all encrypted 
>> communications
>> sent over that TLS connection. The attack can only be exploited if an
>> implementation re-uses a DH secret across multiple TLS connections. Note that
>> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>>
>> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret 
>> and
>> does not implement any "static" DH ciphersuites.
>>
>> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
>> ciphersuite is used. These static "DH" ciphersuites are ones that start with 
>> the
>> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for 
>> these
>> ciphersuites all start with "TLS_DH_" but excludes those that start with
>> "TLS_DH_anon_".
>>
>> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
>> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
>> explicitly configured. Therefore all ciphersuites that use DH in servers
>> (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f
>> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a
>> response to CVE-2016-0701.
>>
>> Since the vulnerability lies in the TLS specification, fixing the affected
>> ciphersuites is not viable. For this reason 1.0.2w moves the affected
>> ciphersuites into the "weak-ssl-ciphers" list. Support for the
>> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause
>> interoperability problems in most cases since use of these ciphersuites is 
>> rare.
>> Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL 
>> at
>> compile time with the "enable-weak-ssl-ciphers" option. This is not 
>> recommended.
>>
>> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>>
>> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
>> upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure
>> that affected ciphersuites are disabled through runtime configuration. Also
>> note that the affected ciphersuites are only available on the server side if 
>> a
>> DH certificate has been configured. These certificates are very rarely used 
>> and
>> for this reason this issue has been classified as LOW severity.
>>
>> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and 
>> Juraj
>> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to
>> allow co-ordinated disclosure with other implementations.
>>
>> Note
>> 
>>
>> OpenSSL 1.0.2 is out of support and no longer receiving public updates. 
>> Extended
>> support is available for premium support customers:
>> https://www.openssl.org/support/contracts.html
>>
>> OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
>> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
>>
>> Users of these versions should upgrade to OpenSSL 1.1.1.
>>
>> References
>> ==
>>
>> URL for this Security Advisory:
>> https://www.openssl.org/news/secadv/20200909.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
>> -BEGIN PGP SIGNATURE-
>>
>> iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335
>> 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F
>> KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb
>> 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E
>> G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu
>> QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk
>> Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb
>> ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280
>> dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3
>> fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry
>> pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj
>> RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU=
>> =U7OO
>> -END PGP SIGNATURE-
>
>
>
> --
> SY, Dmitry Belyavsky

Re: OpenSSL Security Advisory

[Dmitry Belyavsky]

Is the description of the attack publicly available?

On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> OpenSSL Security Advisory [09 September 2020]
> =
>
> Raccoon Attack (CVE-2020-1968)
> ==
>
> Severity: Low
>
> The Raccoon attack exploits a flaw in the TLS specification which can lead
> to
> an attacker being able to compute the pre-master secret in connections
> which
> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this
> would
> result in the attacker being able to eavesdrop on all encrypted
> communications
> sent over that TLS connection. The attack can only be exploited if an
> implementation re-uses a DH secret across multiple TLS connections. Note
> that
> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>
> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret
> and
> does not implement any "static" DH ciphersuites.
>
> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> ciphersuite is used. These static "DH" ciphersuites are ones that start
> with the
> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for
> these
> ciphersuites all start with "TLS_DH_" but excludes those that start with
> "TLS_DH_anon_".
>
> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
> explicitly configured. Therefore all ciphersuites that use DH in servers
> (including ephemeral DH) are vulnerable in these versions. In OpenSSL
> 1.0.2f
> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off
> as a
> response to CVE-2016-0701.
>
> Since the vulnerability lies in the TLS specification, fixing the affected
> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause
> interoperability problems in most cases since use of these ciphersuites is
> rare.
> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
>
> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>
> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
> upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure
> that affected ciphersuites are disabled through runtime configuration. Also
> note that the affected ciphersuites are only available on the server side
> if a
> DH certificate has been configured. These certificates are very rarely
> used and
> for this reason this issue has been classified as LOW severity.
>
> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and
> Juraj
> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order
> to
> allow co-ordinated disclosure with other implementations.
>
> Note
> 
>
> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> Extended
> support is available for premium support customers:
> https://www.openssl.org/support/contracts.html
>
> OpenSSL 1.1.0 is out of support and no longer receiving updates of any
> kind.
> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
>
> Users of these versions should upgrade to OpenSSL 1.1.1.
>
> References
> ==
>
> URL for this Security Advisory:
> https://www.openssl.org/news/secadv/20200909.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
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335
> 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F
> KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb
> 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E
> G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu
> QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk
> Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb
> ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280
> dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3
> fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry
> pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj
> RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU=
> =U7OO
> -END PGP SIGNATURE-
>


-- 
SY, Dmitry Belyavsky

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OpenSSL Security Advisory [09 September 2020]
=

Raccoon Attack (CVE-2020-1968)
==

Severity: Low

The Raccoon attack exploits a flaw in the TLS specification which can lead to
an attacker being able to compute the pre-master secret in connections which
have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would
result in the attacker being able to eavesdrop on all encrypted communications
sent over that TLS connection. The attack can only be exploited if an
implementation re-uses a DH secret across multiple TLS connections. Note that
this issue only impacts DH ciphersuites and not ECDH ciphersuites.

OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and
does not implement any "static" DH ciphersuites.

OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
ciphersuite is used. These static "DH" ciphersuites are ones that start with the
text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these
ciphersuites all start with "TLS_DH_" but excludes those that start with
"TLS_DH_anon_".

OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
explicitly configured. Therefore all ciphersuites that use DH in servers
(including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f
SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a
response to CVE-2016-0701.

Since the vulnerability lies in the TLS specification, fixing the affected
ciphersuites is not viable. For this reason 1.0.2w moves the affected
ciphersuites into the "weak-ssl-ciphers" list. Support for the
"weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause
interoperability problems in most cases since use of these ciphersuites is rare.
Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at
compile time with the "enable-weak-ssl-ciphers" option. This is not recommended.

OpenSSL 1.0.2 is out of support and no longer receiving public updates.

Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure
that affected ciphersuites are disabled through runtime configuration. Also
note that the affected ciphersuites are only available on the server side if a
DH certificate has been configured. These certificates are very rarely used and
for this reason this issue has been classified as LOW severity.

This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj
Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to
allow co-ordinated disclosure with other implementations.

Note


OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended
support is available for premium support customers:
https://www.openssl.org/support/contracts.html

OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
The impact of this issue on OpenSSL 1.1.0 has not been analysed.

Users of these versions should upgrade to OpenSSL 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20200909.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
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335
7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F
KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb
5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E
G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu
QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk
Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb
ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280
dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3
fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry
pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj
RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU=
=U7OO
-END PGP SIGNATURE-

Re: Reordering new API's that have a libctx, propq

[Dr Paul Dale]

> On 9 Sep 2020, at 9:38 pm, Tomas Mraz  wrote:
> 
> We could even provide a convenience thread local stack of lib contexts
> so the caller would not have to keep the old value but would just push
> the new libctx when entering and pop the old one when leaving. With
> that, I think the changes needed in the application code would be
> fairly simple and minimal.

Let’s not overcomplicate things.
We went through this discussion back when this was introduced.


Push is:
OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);

Pop is:
OPENSSL_CTX_set0_default(prevctx)


I don’t see having an explicit stack of these is of any benefit to anything but 
unwarranted complexity.



Pauli

Re: Beta1 PR deadline

[Kurt Roeckx]

On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> Please can anyone with PRs that they wish to have included in OpenSSL
> 3.0 beta1 ensure that they are merged to master by 8th September.

So that date has passed now. Can someone give an overview of what
we think is still needed to be done before the beta 1 release? Are
there open PRs for everything? Do we a milestone on github to
indicate which PRs need to go in before beta1?


Kurt

Re: Reordering new API's that have a libctx, propq

[Tomas Mraz]

On Wed, 2020-09-09 at 11:41 +0200, Richard Levitte wrote:
> 
> Regarding the library context, when viewed as a global state, it
> makes
> sense to have it as a first argument where it's being passed, if at
> all.  The question is, where should we actually pass it?  We have a
> few different suggestions, in wording or in code, on the table:
> 
> 1.  Pass it as first argument everywhere.  This is problematic, as
> "everywhere" is a *lot*, and if we do this, we might as well
> re-design the whole libcrypto API [*], and that's definitely not
> what OpenSSL 3.0 is about, quite the contrary.
> 
> This has been partially done, with all the _with_libctx
> functions.  As far as I've understood, these have been added on
> need basis, i.e. somewhere down the code path, a library context
> or a property query string is needed.  I can't say if this gives
> any sense of completeness or consistency, viewed as an cohesive
> API, or if we stand any chance of getting there without a
> complete
> API re-design.
> 
> Something to be noted is that it doesn't make sense to pass the
> library context everywhere, because it's already part of other
> structures that are passed.  For example, any method structure,
> such as EVP_CIPHER, EVP_MD, etc are tied to a provider, which is
> in turn tied to a library context.  Passing another library
> context to anything that includes one of those method structures
> would only be confusing.
> 
> 2.  Pass it when constructing different structures, mostly other
> context structures.  As an example, EVP_PKEY_CTX_new_from_pkey()
> that I displayed above.  There may be cases where we need to pass
> it directly to functions that aren't constructors, but I expect
> those cases to be relatively few.
> 
> This has been done for some other structures as well, on an as
> needed basis:
> 
> X509 *X509_new_with_libctx(OPENSSL_CTX *libctx, const char
> *propq);
> 
> X509_STORE_CTX *X509_STORE_CTX_new_with_libctx(OPENSSL_CTX
> *libctx,
>const char
> *propq);
> 
> (the following are internal only)
> 
> int x509_set0_libctx(X509 *x, OPENSSL_CTX *libctx, const char
> *propq);
> int x509_crl_set0_libctx(X509_CRL *x, OPENSSL_CTX *libctx,
> const char *propq);
> 
> 3.  Set a current library context, a pointer in a thread local
> variable.  We already have support for that, which this function:
> 
> OPENSSL_CTX *OPENSSL_CTX_set0_default(OPENSSL_CTX *libctx);
> 
> The usage model is this:
> 
> OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> 
> /* do stuff with |libctx| as implicit current global state */
> 
> OPENSSL_CTX_set0_default(prevctx)
> 
> Looking at that list now, I realise that it goes from most intrusive
> to least intrusive, viewed as a public API.
> 
> The third choice in particular would let any application or library
> just set their library context for the duration of the code that
> should be execute with that as a "global state", and restore it when
> done, leaving the rest of the OpenSSL calls untouched.

We could even provide a convenience thread local stack of lib contexts
so the caller would not have to keep the old value but would just push
the new libctx when entering and pop the old one when leaving. With
that, I think the changes needed in the application code would be
fairly simple and minimal.

> Something to be noted is that model 2 and 3 is possible to combine,
> which could give us a smoother transition between the current API and
> whatever we design going forward.

Although I have big sympathy with people that worked hard to add the
various _with_libctx() calls I would say that keeping the new
with_libctx variants would be too confusing. Especially for the reason
we would not have a complete set of them anyway. The exception might be
the low level EVP calls where we deal with the libctx directly and
where the algorithm fetched is actually associated with the context.

> 
> 
> Regarding the property query string, looking at it separate from the
> library context, the question remains where to put it, and a few
> proposals are on the table:
> 
> 1.  Put it last.
> 
> 2.  Put it next to the algorithm name or the object that an algorithm
> name is inferred from.
> 
> 3.  Set it "globally" with a thread local variable, a bit like what
> OPENSSL_CTX_set0_default() does for library contexts.
> 
> For this model, it's been argued if it should simply be stored in
> the current library context, thereby avoiding to add another
> thread local variable (which, for all intents and purposes, is
> another actually global thing to deal with, even though on
> per-thread level).
> 
> In my mind, model 2 would be more sensible than model 1, because of
> the implied tie between algorithm name and property 

Re: Reordering new API's that have a libctx, propq

[Richard Levitte]

A few of the more active developers currently have a videocall meeting
every tuesday, in the morning for us in Europe.

We talked about this issue yesterday, and realised quite a few things.
One pretty important thing to realise is that while many new functions
take a library context and a property query string that are located
together, that doesn't mean that they are the coupled pair that we
made them out to be, quite the contrary.

The library context has been called many things...  during the vidcall
yesterday, it was compared to "a global state", which could be a term
that we can agree with, since its primary function is to be a
collection of stuff that were previously global.

The property query string, on the other hand, is only interesting for
fetching implementations, so if it's to be conceptually coupled with
anything, it's with the name of the algorithm that's being fetched.
This is most visible when we pass a cipher or digest name to some
provider-side implementations; they also always take a property query
string (if we've missed a spot, please raise an issue).

Do note that there are places where we pass a property query string
without passing an algorithm name.  That happen when the algorithm
name is inferred from another object that's passed in.  For example:

EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OPENSSL_CTX *libctx,
 EVP_PKEY *pkey,
 const char *propquery);

This function would classically be used when you have a |pkey| with
just domain parameters, and you want to generate a key from it.  In
this case, the algorithm name is inferred from the |pkey|.

With this, it makes sense to conceptually decouple the library context
and the property query string, and to view the passing of them to
diverse functions in form of a pair as accidental.  We can thereby
talk about them separately.



Regarding the library context, when viewed as a global state, it makes
sense to have it as a first argument where it's being passed, if at
all.  The question is, where should we actually pass it?  We have a
few different suggestions, in wording or in code, on the table:

1.  Pass it as first argument everywhere.  This is problematic, as
"everywhere" is a *lot*, and if we do this, we might as well
re-design the whole libcrypto API [*], and that's definitely not
what OpenSSL 3.0 is about, quite the contrary.

This has been partially done, with all the _with_libctx
functions.  As far as I've understood, these have been added on
need basis, i.e. somewhere down the code path, a library context
or a property query string is needed.  I can't say if this gives
any sense of completeness or consistency, viewed as an cohesive
API, or if we stand any chance of getting there without a complete
API re-design.

Something to be noted is that it doesn't make sense to pass the
library context everywhere, because it's already part of other
structures that are passed.  For example, any method structure,
such as EVP_CIPHER, EVP_MD, etc are tied to a provider, which is
in turn tied to a library context.  Passing another library
context to anything that includes one of those method structures
would only be confusing.

2.  Pass it when constructing different structures, mostly other
context structures.  As an example, EVP_PKEY_CTX_new_from_pkey()
that I displayed above.  There may be cases where we need to pass
it directly to functions that aren't constructors, but I expect
those cases to be relatively few.

This has been done for some other structures as well, on an as
needed basis:

X509 *X509_new_with_libctx(OPENSSL_CTX *libctx, const char *propq);

X509_STORE_CTX *X509_STORE_CTX_new_with_libctx(OPENSSL_CTX *libctx,
   const char *propq);

(the following are internal only)

int x509_set0_libctx(X509 *x, OPENSSL_CTX *libctx, const char *propq);
int x509_crl_set0_libctx(X509_CRL *x, OPENSSL_CTX *libctx, const char 
*propq);

3.  Set a current library context, a pointer in a thread local
variable.  We already have support for that, which this function:

OPENSSL_CTX *OPENSSL_CTX_set0_default(OPENSSL_CTX *libctx);

The usage model is this:

OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);

/* do stuff with |libctx| as implicit current global state */

OPENSSL_CTX_set0_default(prevctx)

Looking at that list now, I realise that it goes from most intrusive
to least intrusive, viewed as a public API.

The third choice in particular would let any application or library
just set their library context for the duration of the code that
should be execute with that as a "global state", and restore it when
done, leaving the rest of the OpenSSL calls untouched.

Something to be noted is that model 2