A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.8.2 2023-07-06T07:56:32+00:00 2023-07-06T07:56:32+00:00 beck 2023-07-06T07:56:32+00:00 urn:sha1:deb33f171f3135e4367961ec4388c20da87f41c8 And remove the tendrils. This was useful for transition but we are now well past this. 2023-05-05T21:23:02+00:00 tb 2023-05-05T21:23:02+00:00 urn:sha1:549cbe92324cb49a0d9fce29e4ece1813496c88b ok jsing (a very long time ago) 2022-11-11T11:25:18+00:00 beck 2022-11-11T11:25:18+00:00 urn:sha1:0ba6b15619d4e4feafccdbd0226ee99b70553a11 Fully explained in libcrypto/README. TL;DR make sure libcrypto and libssl's function calls internally and to each other are via symbol names that won't get overridden by linking other libraries. Mostly work by guenther@, which will currently be gated behind a build setting NAMESPACE=yes. once we convert all the symbols to this method we will do a major bump and pick up the changes. ok tb@ jsing@ 2022-08-17T07:39:19+00:00 jsing 2022-08-17T07:39:19+00:00 urn:sha1:5f133a78eec6f3a2549c066b9a561d6350d6e07a Rather than reimplement this in each TLS client and server, deduplicate it into a single function. Furthermore, rather than dealing with the API hazard that is SSL_get_peer_cert_chain() in this code, simply produce two chains - one that has the leaf and one that does not. SSL_get_peer_cert_chain() can then return the appropriate one. This also moves the peer cert chain from the SSL_SESSION to the SSL_HANDSHAKE, which makes more sense since it is not available on resumption. ok tb@ 2022-07-24T14:28:16+00:00 jsing 2022-07-24T14:28:16+00:00 urn:sha1:2c5937ccb88658c18243c49fc57c58b62e344235 QUIC uses TLS to complete the handshake, however unlike normal TLS it does not use the TLS record layer, rather it provides its own transport. This means that we need to intercept all communication between the TLS handshake and the record layer. This allows TLS handshake message writes to be directed to QUIC, likewise for TLS handshake message reads. Alerts also need to be sent via QUIC, plus it needs to be provided with the traffic keys that are derived by TLS. ok tb@ 2022-06-28T20:40:24+00:00 tb 2022-06-28T20:40:24+00:00 urn:sha1:155ade5b4877933ef80a8ed009a2750254d9dec8 And here is where the fun starts. The tentacles will grow everywhere. ok beck jsing sthen 2022-01-14T09:09:30+00:00 tb 2022-01-14T09:09:30+00:00 urn:sha1:53be7c999edf2b5da8c31198d2e78dd5906217c2 2022-01-05T17:10:03+00:00 jsing 2022-01-05T17:10:03+00:00 urn:sha1:767ff39662be70f355eac7cf069fd9c23c34580d In preparation to use the key share code in both the TLSv1.3 and legacy stacks, rename tls13_key_share to tls_key_share, moving it into the shared handshake struct. Further changes will then allow the legacy stack to make use of the same code for ephemeral key exchange. ok inoguchi@ tb@ 2021-10-23T13:12:14+00:00 jsing 2021-10-23T13:12:14+00:00 urn:sha1:3262c76ed1f7d7ad4c2133bc12fc909491a69e83 This code will soon be used in the DTLSv1.2 and TLSv1.2 stack. Also introduce tls_internal.h and move/rename the read/write/flush callbacks. ok beck@ tb@ 2021-09-04T16:26:12+00:00 jsing 2021-09-04T16:26:12+00:00 urn:sha1:fb975bbc325bbf4283ef4fa3886bde95fe20607e Currently, the plaintext content from opened TLS records is handled via the rbuf code in the TLSv1.3 record layer. Factor this out and provide a separate struct tls_content, which knows how to track and manipulate the content. This makes the TLSv1.3 code cleaner, however it will also soon also be used to untangle parts of the legacy record layer. ok beck@ tb@