[
https://issues.apache.org/jira/browse/PROTON-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118635#comment-18118635
]
ASF subversion and git services commented on PROTON-2974:
---------------------------------------------------------
Commit d65168bbef23cac2dda2fbef05cdc9aa6e71651e in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=d65168bbe ]
PROTON-2974: Verify TLS peer hostnames according to RFC 9525
The hand-rolled wildcard matcher computed the start of its suffix comparison as
slabel + (strlen(slabel) - suffix_len). strlen() returns size_t, so when a name
in the peer certificate had a longer suffix than the corresponding label of the
configured hostname the subtraction wrapped and the comparison read stack memory
preceding the buffer. A certificate name of "*abcdef.example.com" checked
against "x.example.com" reads six bytes starting five bytes before it.
Hand the name check to OpenSSL instead, via X509_VERIFY_PARAM_set1_host() with
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, and delete the matcher. That also settles
two ways the old code diverged from RFC 9525 s6.3: a wildcard is now honoured
only as the complete left-most label and spans exactly one label, so
"ba*.example.com" and "a.*.example.com" are rejected; and the subject CommonName
is consulted only when the certificate carries no DNS SubjectAltName, where
before it was tried whenever no SubjectAltName matched, letting a permissive
legacy CN override tighter SANs. A mismatch now reports
X509_V_ERR_HOSTNAME_MISMATCH rather than X509_V_ERR_APPLICATION_VERIFICATION.
Not SSL_set1_host(), which looks like the obvious call: from 3.0 it converts a
name that parses as an IP literal into an iPAddress-SubjectAltName-only check,
so a peer addressed as "127.0.0.1" presenting a certificate with CN=127.0.0.1 -
which is what our own client-certificate.pem is - stops verifying. Older OpenSSL
does not convert, so the same call would mean different things on different
builds. X509_VERIFY_PARAM_set1_host() asks for the name check and nothing else.
An iPAddress SubjectAltName is picked up in verify_callback instead, by trying
X509_check_ip_asc() on a name that got no DNS match - a form the old matcher
never handled at all.
OpenSSL reads a reference name with a leading dot as "any sub-domain of", so
delegating to it would have widened what a peer may present - ".one.com" would
match "alternate.name.one.com". A DNS name cannot begin with a dot, so treat
that as a configuration error and fail the handshake, alongside the existing
check for VERIFY_PEER_NAME configured with no hostname at all. Both are rejected
in verify_callback rather than where the name is set, so the outcome does not
depend on whether the name arrives before or after the socket exists.
SChannel keeps its own matcher, tightened to the same rules and given the same
SubjectAltName precedence. It compares only against DNS names, as it always has,
so the iPAddress match is OpenSSL-only and the two cases covering it are skipped
on Windows.
SSL_set_hostflags() arrived in OpenSSL 1.1.0, which becomes the minimum;
Drop the version guards that distinguish between earlier versions.
server-wc is reissued with "*.wildcard.domain.com" and 127.0.0.1 as
SubjectAltNames. Its CommonName is left as "*.prefix*.domain.com" deliberately:
a CN the old matcher would have accepted is what makes the SubjectAltName
precedence testable, and it means 127.0.0.1 can only match through the iPAddress
entry. The four wildcard cases become a table of eleven, plus two more where an
iPAddress SubjectAltName is matched, and the two
neighbouring cases that asserted nothing now assert that the handshake
completed.
Assisted-By: Claude Opus 5 <[email protected]>
> TLS peer hostname verification should proceed according to RFC9525
> ------------------------------------------------------------------
>
> Key: PROTON-2974
> URL: https://issues.apache.org/jira/browse/PROTON-2974
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
> Fix For: proton-c-0.41.0
>
>
> Our current TLS peer hostname verification is home grown and not in
> accordance with modern standards. The modern standards are actually much
> stricter and simpler than what we implemented.
> Since this code was written OpenSSL has got the ability to do this and we can
> just require a base version of OpenSSL which can do it.
> The SChannel Win32 code can implement the stricter checks too in custom code
> which is much simplified from the original.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
