Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-httpbis-rfc7238bis-02: (with DISCUSS)

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Feb 2015 07:23:43 +0100

On 2015-02-04 02:05, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-httpbis-rfc7238bis-02: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc7238bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I have a question on the security considerations, since the session isn't
> necessarily encrypted.
>
> Couldn't an attacker substitute the URI that the user gets permanently
> redirected to a malicious site or a competitor, etc.?  The security
> considerations of RFC7231 are pretty thorough, but I didn't see mention
> of using TLS to prevent session interception for this type of attack or
> for the privacy protection section.
>
> If I missed something, please let me know where to look.
>
> Thank you.

No, you didn't miss something. Also, what you say essentially means that 
permanent redirects couldn't be used over HTTP at all.

If it's a concern for 307 it's a concern about 308 as well, in which 
case we should address it in a revision of RFC 7231.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Feb 2015 14:16:26 +0100

On 2015-02-04 14:06, Ted Lemon wrote:
> On Feb 3, 2015, at 11:23 PM, Julian Reschke <[email-masked]> wrote:
>> No, you didn't miss something. Also, what you say essentially means that permanent redirects couldn't be used over HTTP at all.
>>
>> If it's a concern for 307 it's a concern about 308 as well, in which case we should address it in a revision of RFC 7231.
>
> It is perhaps worth pointing out that a permanent redirect only applies to the specific URL that was queried, if I understand it correctly.   So an http:// URL is never secure, and always vulnerable to an MITM attack using the permanent redirect.   But an otherwise identical https:// URL would not be covered by the redirect.

That's true for any redirect.

> And also, AFAIK, a permanent redirect is more for caches and robots than for browsers, isn't it?   I.e., my copy of Chrome isn't going to remember a redirect forever?

I wouldn't say it's "more" for these. But yes, it's likely that 
different components have different ideas about what "permanent" means.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Feb 2015 15:00:07 +0100

On 2015-02-04 14:53, Kathleen Moriarty wrote:
> Hi Julian,
>
> Thanks for your quick response.  My intent wasn't to hold this up,
> although the thought of eliminating vulnerabilities that could be
> sources of compromise is really attractive having managed incident
> response teams. :-)
>
> Yes, I agree this also applies to redirects and that would require an
> update to RFC7231.  For this, could you write text to strongly
> recommend use of TLS with this feature explaining the hazards?

Updating RFC 7231 requires consensus in the WG (and in the IETF, for 
that matter). I also don't believe we have consensus for a 
recommendation not to use permanent redirects on HTTP.

We *could* point out the problem, but then, there are so many other 
similar problems applicable to non-encrypted HTTP that I really don't 
see why this one deserves to be called specifically.

> ...

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Feb 2015 09:26:43 -0500

>> We *could* point out the problem, but then, there are so many other similar
>> problems applicable to non-encrypted HTTP that I really don't see why this
>> one deserves to be called specifically.
>
> The reason is that this draft is just about that feature.  Since it's
> a risk not covered in the pointer, it should be in this draft.  If we
> don't point these things out, stuff won't ever get better.   I'm not
> asking for MUSTs, although I'd like it, I don't think it's practical.

For what it's worth, my view as responsible AD:

- Julian is right that this belongs in the HTTP spec, not in this
document, but...

- This document is an available and reasonable place to make the
point, as an informative thing.

I would not object, and I think it would be a good idea, to include a
very short paragraph that goes something like this:

<< Unsecured http is always subject to redirect attacks, in that a
"man in the middle" can replace any http response with a redirect
(such as to a malicious site or one benefiting the attacker).  Such an
attack can use "permanent" redirect codes (301 or 308) to convince
clients or proxies to cache the malicious information.  Secured https
is not subject to these sorts of attacks. >>

I can't imagine that there'd be any controversy about text such as
that... and it only informs, and does not give any new requirements.

Julian, Mark, others: what do you think?

Barry

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Feb 2015 15:27:45 +0100

> Julian, Mark, others: what do you think?

LGTM.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Feb 2015 09:35:26 -0500

> Thanks, Barry.  That's what I was looking to see and think it will be helpful.

Great; and, as Julian has accepted that, feel free to clear the
DISCUSS, and he and I will make sure it get into the next revision.

Barry

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 4 Feb 2015 09:35:08 -0800

I am really getting tired of this level of reasoning around use of TLS. It ONLY secures the communication path between the client that establishes and authenticates a secure connection and the server that terminates and decrypts that connection. It secures TCP/IP, not HTTP. 

As a result, there are many ways in which https remains vulnerable to redirect attacks because TLS processing is not truly end to end and not always authenticated.

Furthermore, redirect attacks are not relevant to plain unsecured TCP because the content itself is unsecured. Hence, an attacker can just as easily supply content directly that is marked as cacheable, which is more effective than redirecting to a different site due to the same origin restrictions.

I suggest we stop filling the APPS area specifications with sales pitches for TLS. If you want to add "unsecured TCP is vulnerable to man in the middle attacks" in every spec, then just say that directly.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 4 Feb 2015 16:08:42 -0800

On Feb 4, 2015, at 9:44 AM, Kathleen Moriarty wrote:

> Sure, my point is that this redirect can be exploited and that should
> be listed as a security consideration.  Can you take a look at the
> wording proposed by Barry and offer a suggestion that better explains
> the full security consideration, which is broader than just using TLS
> on the points of the session that get encrypted (load balancers, etc.
> may be a termination point)?  TLS doesn't fully mitigate this
> vulnerability, but helps with some level of mitigation.

I do not believe it is appropriate to say much more here, for the simple
reason that I don't want to describe every potential application security
vulnerability in every spec that extends HTTP.

What I would expect to see is a discussion of what additional security
concerns (beyond use of HTTP) are created by the addition of a 308 status
code.  In this case, due to the existing 301 status code, the only
additional security concern would be permanently redirecting the
destination of a POST form such that future POSTs of that same form
(beyond the immediate redirect) are sent directly to the redirect
target.  We used to have a paragraph that forbid automatically
redirecting unsafe requests, which was sufficient to cover this case,
but that was routinely ignored by browser developers.

It would be better to enhance RFC7231 to add a security consideration
on permanent redirects.  If you want to do that here, instead (or as
a prequel), I would point again to what authority means for HTTP
[RFC7230, sec. 9.1] and explain why the permanence of permanent redirects
ought to be treated with a level of skepticism inversely proportional to
how much trust the user has that the message is truly authoritative.
Use of TLS is one way of improving that trust, but does not prevent
misdirection from occurring due to untrusted content or shared
applications within the origin server.

In practice, people don't use permanent redirects to attack clients
because nobody browses untrusted sites with link-editing software,
cache poisoning is far more effective with a fake 200 response than
a fake redirect, and an attack on temporary redirects would be just as
effective (and more likely deployable).  Likewise, the distinction
between permanent and temporary redirects is really only significant
to a specific class of client (e.g., authoring tools).

This doesn't mean permanent redirects don't have a valuable meaning
in certain contexts, such as content management systems, or ought
to be disallowed because they can't always be trusted.  It is just
a gray scale of trust, like everything else on the Internet.

....Roy