Hi Adam,
On Monday, September 14, 2020 at 2:00:06 PM UTC+2 Adam Johnson wrote:
> one thing to consider might be that md5 is usually disabled for FIPS
>> enabled system
>>
>
> This is true, but if no one has complained, why "fix" it? As covered above
> one can always implement custom ETag header
Yes there's a risk of causing collisions if a user can control the
responses. But that doesn't mean there's really a security concern - since
the user creating the collision *can already upload arbitrary content to
the django site.* The collision wouldn't really do anything but cause a
stale asset
Hi,
one thing to consider might be that md5 is usually disabled for FIPS
enabled system (ie https://code.djangoproject.com/ticket/28401 ). So if we
are changing something here we might also consider this.
Cheers,
Florian
On Friday, September 11, 2020 at 9:41:51 AM UTC+2 gertb...@gmail.com wrot
I'm not so sure this is a problem (wrt to using md5 hash of response
content for ETags and likely also for cache keys). The probability of a
naturally occurring collision with MD5 is 1.47*10-29 [1] so the risk of
this scenario occurring by accident is extremely remote.
If we assume that User 2 is
If changing ConditionalGetMiddleware to use SHA-256
It also might be a good to change it on FileBasedCache,
_generate_cache_key, and generate_cache_header_key too
Also, _generate_cache_key is just blindly concatenating hashes, so ['foo',
'bar'] is equal to ['fo', 'obar'], I don't know it might be a
That attack doesn't work with the recommended production setup because
Django doesn't serve uploaded files in that setup.
That being said, some users might be doing that anyway since setting
up production-worthy upload hosting is such a pain, and even if they
don't, they might have other views tha
User 1 uploads a file
User 2 downloads it, and caches it
User 1 uploads a new file to the same URL, with the same MD5 hash
User 2 will keep using the old file indefinitely
Sure, user 1 has to upload two files with the same hash on purpose
On Thu, Sep 10, 2020 at 11:07 AM Adam Johnson wrote:
> W
What would this protect against?
On Thu, 10 Sep 2020 at 03:56, Francisco Couzo
wrote:
> I think it would be a good idea to make ConditionalGetMiddleware use a
> hash function that's not as easy to find a collision as MD5, most probably
> SHA-256 or BLAKE2.
> I don't see a problem with just chang
I think it would be a good idea to make ConditionalGetMiddleware use a hash
function that's not as easy to find a collision as MD5, most probably
SHA-256 or BLAKE2.
I don't see a problem with just changing it, it will just invalidate the
old cache.
If there's an agreement on changing the hash fu
