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

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


On Feb 4, 2015, at 6:26 AM, Barry Leiba <barryleiba@computer.org> wrote:

>>> 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
>

Received on Wednesday, 4 February 2015 17:35:51 UTC