Socketpair authentication fails while Proxifier is enabled

[mathiascode]

Bug report

Bug description:

In the fallback socketpair implementation for Windows, socket authentication fails while Proxifier (and likely similar tools) are enabled. The following exception is always raised:

cpython/Lib/socket.py

Lines 644 to 648 in e41ec8e

	if (
	ssock.getsockname() != csock.getpeername()
	or csock.getsockname() != ssock.getpeername()
	):
	raise ConnectionError("Unexpected peer connection")

Originally spotted in: nicotine-plus/nicotine-plus#3265

Relevant discussion on curl's issue tracker: curl/curl#10144

CPython versions tested on:

3.12

Operating systems tested on:

Windows

[gpshead]

This is working as intended. You're running software that interferes with expected functionality. #122134 to fix CVE-2024-3219 caused it to show up, before this your man-in-the-middle software was snooping the localhost connections being used to build a socket pair work-alike for inter process communication on Windows without being noticed.

If you wanted to propose a workaround PR for this to go back to not caring about sockets being intercepted and snooped on, it would wind up requiring doing authentication handshake through both ends of the socket to ensure they were communicating with one another. (and only doing the existing raise if that handshake fails)

I do not consider that a good idea... This smells like a Proxifier bug, it should not be intercepting localhost sockets.

[slook]

This is working as intended

I disagree. Throwing an error isn't working as intended because according to curl/curl#10144 (comment) "The problem is not Proxifier specific... any MITM tool including some antiviruses can cause this", so the upshot is that #122134 has caused a regression which leads to an unexpected crash in several dependencies which scripts whose socketpairs are not explicitly defined may be unknowingly depending upon.

it should not be intercepting localhost sockets

I agree. However this undesirable behavior on the affected platform cannot be easily influenced so a workaround in cpython seems to be required, unfortunately.

it would wind up requiring doing authentication handshake

The authentication doesn't have to be strong because it is confined to localhost. The workaround in curl seems to be satisfactory enough to send and validate a dummy packet containing the current time, or otherwise a random check digit or suchlike might be desired if spoofing local sockets is really that much of a concern.

Alternatively, the error message could be improved to mention "socketpair" and/or with details about the local peers who are involved with the connection in order to more easily identify where the problem is coming from.

[gpshead]

Yep, simple is fine; just sending & verifying receipt of 20 bytes of os.urandom data is sufficient.

…

On Wed, Feb 5, 2025, 5:15 AM slook ***@***.***> wrote: This is working as intended I disagree. Throwing an error isn't working as intended because according to curl/curl#10144 (comment) <curl/curl#10144 (comment)> "The problem is not Proxifier specific... any MITM tool including some antiviruses can cause this", so the upshot is that #122134 <#122134> has caused a regression which leads to an unexpected crash in several dependencies which scripts whose socketpairs are not explicitly defined may be unknowingly depending upon. it should not be intercepting localhost sockets I agree. However this undesirable behavior cannot be easily influenced so a workaround in cpython seems to be required, unfortunately. it would wind up requiring doing authentication handshake The authentication doesn't have to be strong because it is confined to localhost. Perhaps it would be satisfactory enough to send and validate a dummy packet containing an agent string with a random check digit or suchlike. Alternatively, the error message could be improved to mention "socketpair" and/or with details about the local peers who are involved with the connection in order to more easily identify where the problem is coming from. — Reply to this email directly, view it on GitHub <#129676 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQXC2663Y5LJH5RU3YNX32OIFF7AVCNFSM6AAAAABWQCOHY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZWHAZDMOBSHA> . You are receiving this because you commented.Message ID: ***@***.***>