| Commit message (Collapse) | Author | Files | Lines |
|
|
|
The exporter depends on having a master secret. If the handshake is
not completed, it is neither guaranteed that a shared ciphersuite was
selected (in which case tls1_PRF() will currently NULL deref) or that
a master secret was set up (in which case the exporter will succeed
with a predictable value). Neither outcome is desirable, so error out
early instead of entering the sausage factory unprepared. This aligns
the legacy exporter with the TLSv1.3 exporter in that regard.
with/ok jsing
|
|
https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds describes
a mechanism to authenticate RFC 8805 Geofeed data files through the RPKI.
OpenSSL counterpart https://github.com/openssl/openssl/pull/14050
OK tb@ jsing@
|
|
RFC6482 - A Profile for Route Origin Authorizations (ROAs)
RFC6484 - Certificate Policy (CP) for the RPKI
RFC6493 - The RPKI Ghostbusters Record
RFC8182 - The RPKI Repository Delta Protocol (RRDP)
RFC8360 - RPKI Validation Reconsidered
draft-ietf-sidrops-rpki-rta - A profile for RTAs
Also in OpenSSL: https://github.com/openssl/openssl/commit/d3372c2f35495d0c61ab09daf7fba3ecbbb595aa
OK sthen@ tb@ jsing@
|
|
ok eric jsing
|
|
|
|
Now that AEAD is handled internally, we should no longer be assigning
aead_ctx directly, as this will result in a leak. Missed during the
previous change.
|
|
ok tb@
|
|
|
|
|