News for hackers. Stuff that matters.

A comment on Malicious attack on Wikipedia – what we know and what we’re doing. Parent comment

Re:Malicious attack on Wikipedia – what we know and what we’... by SahAssar on Sunday September 08, 2019 @08:55AM (#20910278)
Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain.

That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basically it is voluntary MITM.

Using a VPS like EC2 is a different story since the decryption happens within the layer that you control. Of course you need to make sure that you choose a vendor for that layer that you trust, but on EC2 the traffic that amazon sees is encrypted with keys they don't have and decrypted with keys stored on a layer that I control. Amazon could read out the memory of my EC2 to get the keys but their business depends on not doing so, so in this case either I have a vendor that always will decrypt and read traffic (Cloudflare), or a vendor whose business depends on hypothetically being able to but not doing it. There is a clear difference to me.

That is the same for most CDN's (including CloudFront and all the other major offerings), so I'm not trying to single out Cloudflare.

[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by acdha on Sunday September 08, 2019 @10:28AM (#20910737)
If you don’t trust Cloudflare, don’t use them but there’s no meaningful security distinction between what they do and what AWS does: in both cases you have a vendor with the capability of violating your security and a promise that they won’t abuse that access.

This is why having a threat model is so important: it keeps you from wasting effort on things which sound like security but aren’t actually changing anything meaningful.

[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by SahAssar on Sunday September 08, 2019 @02:02PM (#20912169)
There is a security distinction, and this has been shown by for example cloudbleed. Every step that has access to plaintext data is a potential attack vector and might be logging/leaking information.

There has also been times where cloudflare (when setup improperly as I mentioned in the previous comment) has misrepresented the security of a connection, as shown by https://www.theregister.co.uk/2016/07/14/cloudflare_investig...

[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by cramforce on Sunday September 08, 2019 @10:06AM (#20910616)
The MITM can be avoided by using Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exc...
[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by SahAssar on Sunday September 08, 2019 @02:04PM (#20912183)
That only works for static content, right?
[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by cramforce on Saturday September 14, 2019 @11:29PM (#20975401)
No, they can be created on the fly. That basically makes it a TLS signing Oracle.
[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by snazz on Sunday September 08, 2019 @09:33AM (#20910474)
Cloudflare’s business also depends on not messing with your traffic, right? It would certainly be easier for them to get your users’ content than for Amazon to do the same, but I think you still have to accept that risk with either. “Hypothetically being able to but not doing it” isn’t a whole lot of confidence if I were hosting some kind of shady website.
[ Parent | on HN ]
Re:Malicious attack on Wikipedia – what we know and what we’... by SahAssar on Sunday September 08, 2019 @02:11PM (#20912235)
Sure, but since Cloudflare’s business is actively "messing" with all your traffic, all the time it's a smaller technical step to do it some more, and can also lead to accidents like cloudbleed. Every step that has access to unencrypted data is a potential attack vector or might be logging/leaking data.
[ Parent | on HN ]