-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to allow HttpClient to follow HTTPS -> HTTP redirects #28039
Comments
If you need to follow HTTPS -> HTTP redirects, the currently solution is to disable automatic redirection, HttpClientHandler.AllowAutoRedirect. Then do the redirection manually by reading the Location: response header on the 3xx response. |
Yes, I know. But it'd be easier just to construct |
You can also create a delegating handler (based on HttpMessageHandler or DelegatingHandler). In that handler you can do the manual redirection there. See examples: https://stackoverflow.com/questions/11970313/delegatinghandler-for-response-in-webapi |
Given that (1) this behavior is disabled for security reasons, and (2) there are well supported methods for working around its limitations, I don't think that we should change anything here. I think that by leaving the process as slightly more involved, we increase the likelihood that anyone who enables insecure redirects actually understands the risk. |
What is the security risk that this mitigates? It seems that if the server (deliberately) redirects to an HTTP url then so be it. |
My primary concern is around the potential lack of transparency when we perform an https -> http redirect. For example, when a developer writes this code: var result = await client.GetAsync("https://contoso.com/account"); They reasonably expect to be getting the content over a secure connection, and may make assumptions about the integrity of the response. If we silently redirect from https to http those assumptions will not necessarily hold true. The current implementation does allow servers to break that assumption, but only if the client also explicitly opts in to that behavior by manually processing redirects or creating a delegating handler. We could make it easier for clients to opt in, but as I said above:
|
why make everyone have to go through the trouble of manually handling redirects when a property called many websites in the wild perform 301/302 redirects from HTTPS -> HTTP (which then gets redirected back from HTTP -> HTTPS) - so it would be nice to be able to control that behavior from a client's perspective where you have no control over the server - left with the only option of manually implementing yourself which seems less than ideal since its such a simple API to add. |
Triage: |
This needs work:
namespace System.Net.Http
{
public partial class SocketsHttpHandler
{
public bool DangerousAllowHttpsToHttpRedirection { get; set; }
}
} |
We already use the prefix 'Dangerous' here in 'HttpClientHandler'
public partial class HttpClientHandler : System.Net.Http.HttpMessageHandler
{
public static System.Func<System.Net.Http.HttpRequestMessage, System.Security.Cryptography.X509Certificates.X509Certificate2, System.Security.Cryptography.X509Certificates.X509Chain, System.Net.Security.SslPolicyErrors, bool> DangerousAcceptAnyServerCertificateValidator { get { throw null; } }
// ...
} |
Why make this API so complicated? Is this API really more dangerous than being able to easily bypass TLS certificate verification with the As long as this API default is 'safe' (i.e. don't do redirect from HTTPS to HTTP), then I don't see why making this API difficult to use will help developers. If we make it so complicated to use, they might as well turn off auto-direct and parse the 'Location' header themselves from the 3xx response. |
@bartonjs do the guidelines suggest when to use Dangerous vs Unsafe? In my mind Dangerous means “difficult to use at all in a safe way” whereas Unsafe means more like “removes some safety checks” but that’s just what I’d assumed. |
Nope. I also don't recall a Dangerous v Unsafe discussion in the meeting; only that maybe a context-providing delegate was a good balance between "do a bunch of work to do manual redirects" and "anything's fair game". According to apisof.net, we only have 4 Dangerouses: SafeHandle.DangerousAddRef, SafeHandle.DangerousRelease, SafeHandle.DangerousGetHandle, HttpClient.DangerousAcceptAnyServerCertificateValidator (then ASP.Net has a handful). But generally "Unsafe" means "pointer-type operations that may be lacking in bounds checking" and (for ThreadPool) "doesn't capture context". I'd call this one Dangerous if it's a boolean property, but that's because I like keeping Unsafe as being related to the unsafe code keyword. |
@davidsh there's a suggestion that you could do eg. |
Is there any ETA on this? We could really use this as well. |
@TonyValenti no ETA. |
Closing as Won't Fix for now due to complexity, security concerns and low demand. |
API Proposal:
Currently
HttpClient
does not follow HTTPS -> HTTP redirects. However, even though this increases security, sometimes it is necessary to follow these redirects.I suggest to add an option which would make HttpClient follow HTTPS -> HTTP redirects.
The text was updated successfully, but these errors were encountered: