<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src, branch libressl-v3.1.3</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=libressl-v3.1.3</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=libressl-v3.1.3'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2020-06-10T03:56:22+00:00</updated>
<entry>
<title>OpenBSD 6.7 errata 010, June 11, 2020 (6.7/010_x509.patch.sig)</title>
<updated>2020-06-10T03:56:22+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-06-10T03:56:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=6509152b9d4dd2af6685a777e5384b818cd88911'/>
<id>urn:sha1:6509152b9d4dd2af6685a777e5384b818cd88911</id>
<content type='text'>
original commit:

CVSROOT:	/cvs
Module name:	src
Changes by:	jsing@cvs.openbsd.org	2020/05/31 11:23:39

Modified files:
	lib/libcrypto/x509: x509_vfy.c

Log message:
When building a chain look for non-expired certificates first.

Currently, when building a certificate chain we look up an issuer and if
it is the only issuer certificate available we still use it even if it has
expired. When X509_V_FLAG_TRUSTED_FIRST is not in use, untrusted
certificates are processed first and if one of these happens to be expired
it will be used to build the chain, even if there is another non-expired
option in the trusted store.

Rework this code so that we first look for a non-expired untrusted
certificate. If one does not exist then we take a look in the trusted
store to see if we would be able to build the chain and only if there is
not, do we then look for an expired untrusted certificate.

This makes certificate validation possible for various sites that are
serving expired AddTrust certificates.

Issue reported by Christian Heimes via GitHub.

ok beck@ tb@
</content>
</entry>
<entry>
<title>LibreSSL 3.1.2</title>
<updated>2020-05-21T02:27:34+00:00</updated>
<author>
<name>bcook</name>
<email></email>
</author>
<published>2020-05-21T02:27:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=98fa86d49f73602179145a8a82817acd8dd42203'/>
<id>urn:sha1:98fa86d49f73602179145a8a82817acd8dd42203</id>
<content type='text'>
</content>
</entry>
<entry>
<title>OpenBSD 6.7 errata 004 6.7/004_libssl.patch.sig</title>
<updated>2020-05-19T20:22:33+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-05-19T20:22:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=7b3159529b31e90658d16fd8468765e7ae37f1e5'/>
<id>urn:sha1:7b3159529b31e90658d16fd8468765e7ae37f1e5</id>
<content type='text'>
original commits:

CVSROOT:        /cvs
Module name:    src
Changes by:     jsing@cvs.openbsd.org   2020/05/16 08:44:55

Modified files:
        lib/libssl     : tls13_client.c

Log message:
Ensure that a TLSv1.3 server has provided a certificate.

The RFC requires that a server always provide a certificate for
authentication. Ensure that this is the case, rather than proceeding and
attempting validation. In the case where validation was disabled and the
server returned an empty certificate list, this would have previously
resulted in a NULL pointer deference.

Issue reported by otto@

ok inoguchi@ tb@

CVSROOT:        /cvs
Module name:    src
Changes by:     jsing@cvs.openbsd.org   2020/05/17 08:26:15

Modified files:
        lib/libssl     : tls13_client.c

Log message:
Send a decode error alert if a server provides an empty certificate list.

According to RFC 8446 section 4.4.2.4, a client receiving an empty
certificate list must abort the handshake with a decode error alert.

ok beck@ inoguchi@ tb@ ('it rarely is the alert you'd expect it to be...')
</content>
</entry>
<entry>
<title>Bump LibreSSL version to 3.1.1</title>
<updated>2020-05-06T15:45:22+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-05-06T15:45:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=ee48f389834876fcbc39c15605a1a3037becc5c2'/>
<id>urn:sha1:ee48f389834876fcbc39c15605a1a3037becc5c2</id>
<content type='text'>
ok bcook inoguchi deraadt
</content>
</entry>
<entry>
<title>Use a larger (2048 bit) RSA test key.</title>
<updated>2020-05-04T16:18:54+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2020-05-04T16:18:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=b2af28cd297d80fb2c19ed05765fb6c5aa610a7a'/>
<id>urn:sha1:b2af28cd297d80fb2c19ed05765fb6c5aa610a7a</id>
<content type='text'>
Otherwise we fail to do PSS signatures since the key size is too small.
</content>
</entry>
<entry>
<title>Fix out-of-bounds access in tables[][] that was exposed in bluhm's</title>
<updated>2020-05-04T14:20:36+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-05-04T14:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=2f51014ac0adf8681f1764313a33eab2c8e9bd11'/>
<id>urn:sha1:2f51014ac0adf8681f1764313a33eab2c8e9bd11</id>
<content type='text'>
regress on i386 after inoguchi moved some symbols to const.

ok inoguchi jsing deraadt
</content>
</entry>
<entry>
<title>Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.</title>
<updated>2020-05-03T15:57:25+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2020-05-03T15:57:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c011805d37d80a9f55b2f013aa73f0183dff7d25'/>
<id>urn:sha1:c011805d37d80a9f55b2f013aa73f0183dff7d25</id>
<content type='text'>
In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message
immediately after its first handshake message. This is normally after the
ServerHello message, but it can be after the HelloRetryRequest message.
As such we accept one CCS message from the server during the handshake.

However, it turns out that in the HelloRetryRequest case, Facebook's fizz
TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message
and the ServerHello message. This is unexpected and as far as I'm aware,
no other TLSv1.3 implementation does this. Unfortunately the RFC is rather
ambiguous here, which probably means it is not strictly an RFC violation.

Relax the CCS message handling to allow two dummy CCS messages during a
TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR
is triggered.

Issue discovered by inoguchi@ and investigated by tb@.

ok deraadt@ tb@
</content>
</entry>
<entry>
<title>Add const to TLS1.3 internal vectors</title>
<updated>2020-05-02T00:31:54+00:00</updated>
<author>
<name>inoguchi</name>
<email></email>
</author>
<published>2020-05-02T00:31:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=2e6d47dd230cf0a1dc61aea57faf78019cf22858'/>
<id>urn:sha1:2e6d47dd230cf0a1dc61aea57faf78019cf22858</id>
<content type='text'>
ok tb@
</content>
</entry>
<entry>
<title>Disallow setting the AES-GCM IV length to 0</title>
<updated>2020-04-30T18:43:11+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-04-30T18:43:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=1813a9138ee882b675662d47ed9fe6974bd433f3'/>
<id>urn:sha1:1813a9138ee882b675662d47ed9fe6974bd433f3</id>
<content type='text'>
It is possible to do this by abusing the EVP_CTRL_INIT API.
Pointed out by jsing.

ok inoguchi jsing (as part of a larger diff)
</content>
</entry>
<entry>
<title>tls13_record_layer internal functions to static in libssl</title>
<updated>2020-04-29T01:22:28+00:00</updated>
<author>
<name>inoguchi</name>
<email></email>
</author>
<published>2020-04-29T01:22:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=cbd0a539eed34c8b6b65717c68d01a47aa9aa314'/>
<id>urn:sha1:cbd0a539eed34c8b6b65717c68d01a47aa9aa314</id>
<content type='text'>
We might remove static again for further regress around record layer
in the future.

ok jsing@ tb@
</content>
</entry>
</feed>
