A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_7_BASE 2025-03-13T10:44:36+00:00 2025-03-13T10:44:36+00:00 sthen 2025-03-13T10:44:36+00:00 urn:sha1:181f99fca485a8c857ea69a0c27cd192bb2d93f4 code #ifdef'ing these and compiled with new headers won't work as expected on earlier libraries minor libtls bump to match libssl bump ok tb@ 2025-03-09T15:55:23+00:00 tb 2025-03-09T15:55:23+00:00 urn:sha1:03c85ab803a26b62081f7094f3db37752fe0c26d 2024-12-10T08:42:12+00:00 tb 2024-12-10T08:42:12+00:00 urn:sha1:c94b3b4a953c20b000c195ce5e2ef6683eed6964 ok beck 2024-12-10T08:41:04+00:00 tb 2024-12-10T08:41:04+00:00 urn:sha1:33875d389c8fd1dfd905c7df51d2a99c0e2a197c 2024-12-10T08:40:45+00:00 tb 2024-12-10T08:40:45+00:00 urn:sha1:db054d1724c886cd5458cd093791310cf44fb0ae 2024-12-10T08:40:30+00:00 tb 2024-12-10T08:40:30+00:00 urn:sha1:d3da05396af6da5d0c94da0425031aa4fd529ac9 There is currently no sane way of getting your hands on the common name or subject alternative name of the peer certificate from libtls. It is possible to extract it from the peer cert's PEM by hand, but that way lies madness. While the common name is close to being deprecated in the webpki, it is still the de facto standard to identify client certs. It would be nice to have a way to access the subject alternative names as well, but this is a lot more difficult to expose in a clean and sane C interface due to its multivaluedness. Initial diff from henning, with input from beck, jsing and myself henning and bluhm have plans of using this in syslogd. ok beck 2024-11-12T22:50:06+00:00 tb 2024-11-12T22:50:06+00:00 urn:sha1:fee58a01d3e38dbf53d13d5b43fb040439348421 A certificate must have a subject, so X509_get_subject_name() cannot return NULL on a correctly parsed certificate, even if the subject is empty (which is allowed). So if X509_get_subject_name() returns NULL, error instead of silently ignoring it in tls_check_common_name(). This is currently no issue. Where it matters, the match against the common name will fail later, so we fail closed anyway. ok jsing 2024-08-31T10:54:12+00:00 tb 2024-08-31T10:54:12+00:00 urn:sha1:71ba87c7b967350832d234fc05a24f33898e3408 2024-08-12T21:02:24+00:00 tb 2024-08-12T21:02:24+00:00 urn:sha1:252403d7ae62fce4218c94b3714a4d666fe438b7 2024-08-02T15:00:01+00:00 tb 2024-08-02T15:00:01+00:00 urn:sha1:b406bf2119594dc725dd7e537eb049151f94db87 Redefining TLS_PROTOCOL_TLSv1_0 and TLS_PROTOCOL_TLSv1_1 to be the same as TLS_PROTOCOL_TLSv1_2 had undesired side effects, as witnessed in the accompanying regress tests. The protocol string all:tlsv1.0 would disable TLSv1.2 (so only enable TLSv1.3) and tlsv1.2:!tlsv1.1 would disable all protocols. It makes more sense to ignore any setting of TLSv1.0 and TLSv1.1, so if you request 'tlsv1.1' you get no protocol, but 'all:!tlsv1.1' will enable the two supported protocols TLSv1.3 and TLSv1.2. Restore the defines to their original values and adjust the parsing code to set/unset them. Issue reported by Kenjiro Nakayama Fixes https://github.com/libressl/openbsd/issues/151 with/ok jsing