Conversation
00cb110 to
9988a27
Compare
9988a27 to
40a663d
Compare
Codecov ReportBase: 88.00% // Head: 87.95% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #3112 +/- ##
==========================================
- Coverage 88.00% 87.95% -0.05%
==========================================
Files 600 600
Lines 67055 66871 -184
Branches 6696 6687 -9
==========================================
- Hits 59011 58819 -192
- Misses 5219 5227 +8
Partials 2825 2825
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
40a663d to
26c074c
Compare
randombit
left a comment
There was a problem hiding this comment.
I just reviewed the final commits
| buf.push_back(0); | ||
| buf.push_back(0); | ||
| buf.push_back(0); | ||
| TODO: look into this more deeply |
There was a problem hiding this comment.
Outstanding issue here? I don't understand what this TODO refers to
There was a problem hiding this comment.
I was wondering about the hard-coded serialization and wanted to find out what is going on here. For reference, this is now:
// Serialization is hard-coded as we don't support advanced features
// of this extension anyway.
return
{
1, // status_type = ocsp
0, 0, // empty responder_id_list
0, 0, // no extensions
};a3012ae to
3ad1a6b
Compare
This extension got redefined in TLS 1.3 and is now attached to individual CertificateEntries in the Certificate handshake message. This prepares the Certificate_Status_Request class using a pimpl construction.
3ad1a6b to
706670f
Compare
Pull Request Dependencies
Description
This introduces active support for OCSP stapling for certificate-based authentication of both TLS 1.3 servers and clients.
I refactored the existing
Certificate_Status_Requestextension that was already used in TLS 1.2 but changed its semantics in TLS 1.3. Relevant RFC sections are referenced in the code. TL;DR: In TLS 1.3Certificate_Status_Requestis used as an extension to individualCertificateEntrystructures in theCertificatehandshake message. Though, the extension's body is equal to theCertificate_Statushandshake message used in TLS 1.2 🤯New Callback:
TLS::Callbacks::tls_provide_cert_chain_status()... that allows applications to provide stapled OCSP responses for all (or some) certificates added to the Certificate handshake message. To the best of my understanding, previous versions of TLS allowed stapled OCSP responses for the leaf certificate, only.
By default, this callback invokes the old
tls_provide_cert_status()callback: mimicking the behavior of TLS 1.2 and stapling an OCSP response for the leaf certificate, only.BoGo
Note that this enables several BoGo tests that are not necessarily related to OCSP stapling. In fact, the relevant tests for OCSP stapling cannot be enabled yet: They all depend on session resumption that is future work. However, the initial handshakes (with OCSP stapling) were successful, the tests fail due to the inability to resume the session later on.