Subject: Fwd: Secdir review of draft-ietf-httpbis-p6-cache-20

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Sep 2012 11:56:37 +1000

FYI.

Begin forwarded message:

> Resent-From: [email-masked]
> From: Tero Kivinen <[email-masked]>
> Subject: Secdir review of draft-ietf-httpbis-p6-cache-20
> Date: 4 September 2012 11:51:01 PM AEST
> Resent-To: [email-masked], [email-masked], [email-masked], [email-masked],, [email-masked], [email-masked]
> To: [email-masked], [email-masked], [email-masked]
> 
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> 
> This document is part 6 of the HTTP/1.1 and covers the caching in
> http.
> 
> The security considerations section is quite short covering the case
> that caches are attractive targets for attackers and that the fact
> that cache can reveal information long after the information has been
> removed from the network.
> 
> I think the security considerations section should list other attacks
> too. Things that comes to my mind:
> 
> - Cache poisoning attacks, i.e. attacker who can control the
>  www-server for a moment could pre-load cache with stuff that will
>  stay there for long time (as long as the cache control attributes
>  say). This includes negative result (404) caching.
> 
> - Cache caching stuff that was not supposed to be cached, like
>  authentication credentials in forms of cookies (the RFC6265 - "HTTP
>  State Management Mechanism" says that the presense of the cookies
>  does not preclude HTTP caches from storing and reusing a response).
>  This can be problem unless all applications using cookies actually
>  make sure that they set all pages as non-cacheable.
> 
> - Cache might leak out information to other users of the cache who
>  fetched the page in the first time. This leaking can happen in
>  multiple ways (for example cookies, etc). Actually just timing can
>  tell that someone has already fetched the page to the cache, which
>  in some cases might be enough to leak information out.
> 
> There most likely are still other attacks which I did not list above.
> 
> Also as cookies are quite often used in various things like
> authentication, session identifiers, language selection etc, I think
> the section 3 should mention something about them, especially mention
> that RFC6265 says they can be cached (this was suprise for me, I would
> have expected cookies to be counted in the same category as
> authorization fields i.e. fields thta disable caching).
> 
> I was also suprised not to find warning about the caching of the
> cookies in the RFC6265, but perhaps we should add note here in
> security considerations section saying that by default cookies are
> cachable, so applications using them must make sure they are not
> cached unless wanted so. It might not be able to reach its intended
> users (the ones writing web applications), but at least it might
> spread the information to some relevant parties.
> 
> In summary I think this document needs bit more work in security
> considerations section.
> -- 
> [email-masked]

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Sep 2012 12:11:31 +1000

Hi Tero,

CC:ing the HTTP mailing list.

These all seem reasonable. I'll work to update the Security Considerations and publish in -21, will ping you once that happens.

Thanks,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Sep 2012 13:53:13 +1000

[ removing the IESG from the CC list]

Please see:
  https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Sep 2012 13:19:16 -0700

On 18/09/2012, at 1:53 AM, Tero Kivinen <[email-masked]> wrote:

> Mark Nottingham writes:
> The current text for this seems to be ok (from the work in progress
> draft):
> 
> 	Implementation flaws might allow attackers to insert content
> 	into a cache ("cache poisoning"), leading to compromise of
> 	clients that trust that content. Because of their nature,
> 	these attacks are difficult to mitigate.
> 
> Same for this:
> 	Likewise, implementation flaws (as well as misunderstanding of
> 	cache operation) might lead to caching of sensitive
> 	information (e.g., authentication credentials) that is thought
> 	to be private, exposing it to unauthorised parties.
> 
> 	Note that the Set-Cookie response header [RFC6265] does not
> 	inhibit caching; a cacheable response with a Set-Cookie header
> 	can be (and often is) used to satisfy subsequent requests to
> 	caches. Servers who wish to control caching of these responses
> 	are encouraged to emit appropriate Cache-Control response
> 	headers.
> 
> This was not added to security considerations at all. Was this
> intentional, or just left out by accident? Was there something unclear
> about this attack? 

I didn't see how it was materially different than the previous one (unintentional caching of sensitive information). Could you explain how it is?

Regards,

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