On 2022-08-22 at 09:04:34, Jeff King wrote:
> On Sun, Aug 21, 2022 at 12:32:54AM +0200, Daniel Stenberg wrote:
> 
> > I would not mind having a discussion in the curl project to see if we should
> > possibly consider adding a middle-ground where we allow sending credentials
> > to another port for the same host name, but I am personally NOT sold on the
> > idea. I think such redirects should rather be fixed and avoided - since I
> > believe users will not understand the security implications of doing them.
> 
> I'm not 100% on it either. When it comes to security restrictions,
> sometimes simple-and-stupid is the best way. I was literally thinking of
> something as basic and restricted as:
> 
>   if (from_port == 80 && to_port == 443 &&
>       from_protocol == HTTP && to_protocol == HTTPS)
>         /* ok, allow it */
> 
> just because https upgrade is such a common (and presumably harmless)
> redirect.  But possibly even that leaves wiggle room for bad things to
> happen. I'm happy to defer to you and other curl folks there.

I think it's actually better to fail in this case, and here's why.  If
someone is using HTTP and getting redirected to HTTPS, there's no
security if an attacker intercepts the HTTP connection.  Anyone who
knows how a captive portal works will recognize this immediately, and
it's why we have Strict Transport Security in browsers.

If we fail when a user redirects, then they'll fix their URL to use
HTTPS, at which point their connection is prevented from tampering
effectively forever.  If we redirect, then when they make a connection,
they'll be vulnerable to tampering every time, possibly sending
credentials over the wire in plaintext or being redirected to a rogue
site.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA