Re: Adding Security Considerations regarding interception to p1

On 20/09/2013, at 3:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> 
> Then what do you think about just describing the current state without
> giving any guidance about how to protect, so that the reader informs
> himself on the subject if he feels concerned ?


Personally - I think that'd be a big improvement over saying nothing. However, AIUI the security folks like to see a listing of both threats *and* mitigations for them. Stephen?

The second proposal I made (copied below) tried to make it clear that while TLS might help, it's not a panacea. Are you still against it? Would adding further qualifications about TLS help?

Regards,

---8<---

Interception

Common use of HTTP often contains a considerable amount of sensitive data; this might include cookies [RFC6265], application data, and even patterns of access.

When used without encryption, HTTP makes this data vulnerable to passive interception. There are known instances when third parties have exploited the in-the-clear nature of "http://" URIs to obtain sensitive information, for a variety of purposes. Use of TLS [RFC2818] can help to mitigate such passive interception attacks. Note that TLS itself has many modes of use with different security properties, and there are currently known attacks against server authentication in "https://" URIs.

Moreover, like other clear text protocols, HTTP/1.1 is subject to an active man-in-the-middle attack.  That is, it is possible for an intermediary
device to terminate a client TCP connection and respond as if it had the IP address of the intended HTTP server.  An attacker may insert or delete content or redirect the client to a completely different web site.  Using TLS [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors. 

--->8---

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 20 September 2013 05:15:01 UTC