[
https://issues.apache.org/jira/browse/THRIFT-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-6201.
--------------------------------
Fix Version/s: 0.25.0
Assignee: Sylwester Lachiewicz
Resolution: Fixed
> Python peer address matcher does not reduce IPv4-mapped IPv6 addresses
> ----------------------------------------------------------------------
>
> Key: THRIFT-6201
> URL: https://issues.apache.org/jira/browse/THRIFT-6201
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
> Reporter: Sylwester Lachiewicz
> Assignee: Sylwester Lachiewicz
> Priority: Major
> Fix For: 0.25.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{match_peer_ipaddress}} compares the peer address to the certificate's
> {{subjectAltName}} entries without reducing IPv4-mapped IPv6 addresses, so a
> peer that arrives on a dual-stack listener never matches a certificate that
> carries the plain IPv4 address.
> A dual-stack listener reports an IPv4 peer as {{::ffff:127.0.0.1}}. A
> certificate normally carries {{IP Address:127.0.0.1}}.
> {{ipaddress.ip_address('127.0.0.1') !=
> ipaddress.ip_address('::ffff:127.0.0.1')}}, so the loop finds no match and
> the connection is refused:
> {noformat}
> WARNING:thrift.transport.TSSLSocket:Failed to validate client certificate
> address: ::ffff:127.0.0.1
> File ".../thrift/transport/TSSLSocket.py", line 422, in accept
> self._validate_callback(client.peercert, addr[0])
> File ".../thrift/transport/sslcompat.py", line 112, in match_peer_ipaddress
> raise TTransportException(
> TTransportException: Peer address "::ffff:127.0.0.1" is not covered by the
> certificate it presented
> {noformat}
> The two spellings are the same address and have to compare equal. Reducing
> both sides with {{IPv6Address.ipv4_mapped}} before comparing is enough.
> h3. Scope
> This does not on its own make the cross tests pass. They also fail because
> {{test/keys/client.crt}}, which {{client.p12}} wraps and the cross-test
> clients present, carries no extensions at all and therefore no
> {{subjectAltName}} - {{test/keys/keygen/make-serverkey.sh}} signs it without
> {{-extensions v3_req}} on purpose, with {{client_v3.crt}} as the variant that
> has them. Whether a server should match a client certificate against the
> address the connection arrived from is a separate question, and a separate
> ticket if the answer is no.
> The path only started running on Python 3.12 and later in 0.25.0. Before that
> the shim on those versions was a function returning True, so nothing reached
> the comparison.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
