News for hackers. Stuff that matters.
Re:Malicious attack on Wikipedia – what we know and what we’... by SahAssar on Saturday September 07, 2019 @06:22PM (#20906999)
> What’s wrong with having an upstream provider for caching close to the user and other features when you’re not under attack?

The problem is that you are basically mitm:ed all the time.

Re:Malicious attack on Wikipedia – what we know and what we’... by acdha on Saturday September 07, 2019 @08:44PM (#20907757)
That’s not what MITM means. I get that you don’t like Cloudflare but voluntary use of a CDN isn’t a MITM any more than, say, Amazon is a MITM because you host on EC2.
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.

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.

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

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...
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?
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.
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.
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.
Re:Malicious attack on Wikipedia – what we know and what we’... by dangxiaopin on Saturday September 07, 2019 @09:40PM (#20908010)
You upload your private SSL key to Cloudflare for example. And I was talking about hosting on your own hardware/colos like most large sites do (7x cheaper than AWS list prices on avg)
Re:Malicious attack on Wikipedia – what we know and what we’... by acdha on Saturday September 07, 2019 @09:42PM (#20908025)
Please specify in detail how you believe that’s an MITM using the standard industry definition. In particular, consider whether “attack” and “voluntary business agreement” are synonyms.
Re:Malicious attack on Wikipedia – what we know and what we’... by lazyguy2 on Sunday September 08, 2019 @01:33AM (#20908785)
MITM is not a uncommon term to use when you do things like install corporate SSL certs on laptops so you can monitor people's activities.
Re:Malicious attack on Wikipedia – what we know and what we’... by detaro on Sunday September 08, 2019 @05:57AM (#20909544)
Breaking open encryption to monitor activity between users and other sites is a completely different thing than having a provider handle hosting for your site.
Re:Malicious attack on Wikipedia – what we know and what we’... by judge2020 on Saturday September 07, 2019 @08:57PM (#20907815)
A better comparison would be Cloudfront and Application Load Balancers since you can expose your own ec2 server or load balancer and be e2e encrypted (unless AWS wanted to run commands on your instance, which they could do, but that's a different threat vector entirely).
Re:Malicious attack on Wikipedia – what we know and what we’... by acdha on Saturday September 07, 2019 @09:40PM (#20908018)
That was the model I had in mind but it’s not really a meaningful distinction since the host could almost certainly compromise those servers as well. In any case, you’re trusting a third party rather than having their involvement maliciously imposed.