SocketsHttpHandler should throw instead of returning proxy response message when proxy tunnel creation fails

[geoffkizer]

Description

For secure HTTP connections, we attempt to create a proxy tunnel using the CONNECT method against the proxy endpoint. This allows us to create an end-to-end secure SSL connection between client and destination server.

If the proxy CONNECT request fails, (i.e. returns a status other than 200), we return the proxy's response to the user. However, this means the user can't distinguish whether the response came from the proxy or the destination server. This is problematic because the user is using SSL and thus reasonably expects that any response has been securely delivered via the end-to-end secure connection.

I think we should change this behavior, and instead throw an HttpRequestException when a proxy tunnel CONNECT request fails. Something like "The proxy tunnel request to proxy {proxyUri} failed with status code {statusCode}."

Note that for non-secure requests, we always return the proxy response and the user can't tell whether the response came from the destination server unmodified, or was modified by the proxy, or was simply generated by the proxy without even contacting the destination server. This is intentional; for non-secure requests, proxies are explicitly allowed to do whatever they want to a request, including modifying it, blocking it entirely, etc.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

For secure HTTP connections, we attempt to create a proxy tunnel using the CONNECT method against the proxy endpoint. This allows us to create an end-to-end secure SSL connection between client and destination server.

If the proxy CONNECT request fails, (i.e. returns a status other than 200), we return the proxy's response to the user. However, this means the user can't distinguish whether the response came from the proxy or the destination server. This is problematic because the user is using SSL and thus reasonably expects that any response has been securely delivered via the end-to-end secure connection.

I think we should change this behavior, and instead throw an HttpRequestException when a proxy tunnel CONNECT request fails. Something like "The proxy tunnel request to proxy {proxyUri} failed with status code {statusCode}."

Note that for non-secure requests, we always return the proxy response and the user can't tell whether the response came from the destination server unmodified, or was modified by the proxy, or was simply generated by the proxy without even contacting the destination server. This is intentional; for non-secure requests, proxies are explicitly allowed to do whatever they want to a request, including modifying it, blocking it entirely, etc.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	6.0.0

[wfurt]

make sense to me. basically treat CONNECT failures as form of connect() failure. How about authentication failures? They should have distinct status code, right?

[geoffkizer]

Yeah, an auth failure will show up as a 407 status code.