Recently moved from Google Cloud (8x less price - 4x more power) and we got ~100kb/s of constant traffic from countries like china. fail2ban usually locks me for day or two until i disabled password-based auth and fail2ban.
DDoS protection
161–170 of 175 posts
Re: DDoS protection
#162Recently moved from Google Cloud (8x less price - 4x more power) and we got ~100kb/s of constant traffic from countries like china. fail2ban usually locks me for day or two until i disabled password-based auth and fail2ban.
Disabling fail2ban doesn't sound like the best solution.
Why did it lock you out? If your username is not public and root has no password the locks shouldn't affect you.
Re: DDoS protection
#163Earlier quoted context omitted.
Except MiTM is used primarily, if not exclusively, in attack scenarios. Otherwise any third-party you use as a website owner is a MiTM.
If they’re stripping encryption and reapplying they’re MITM. Seems pretty straightforward.
Simply decrypting and re-encrypting web traffic in an intentional and authorized way is not MITM and should not called that.
So, why do people call CloudFlare MITM?
1) They honestly don't know that MITM is just the name for an attack, not a neutral term.
2) They think any mid-route decryption/re-encryption is bad and dangerous.
3) They are mad about some aspect of CloudFlare's service, and call it MITM to make it sound worse to everyone else.
Folks in the 1 and 2 camp just need to get educated. Folks in the 3 camp might have good points on the substance, but they are contributing to the misunderstandings of 1 and 2.
Re: DDoS protection
#164Earlier quoted context omitted.
If they’re stripping encryption and reapplying they’re MITM. Seems pretty straightforward.
Simply decrypting and re-encrypting web traffic in an intentional and authorized way is not MITM and should not called that. So, why do people call CloudFlare MITM? 1) They honestly don't know that MITM is just the name for an attack, not a neutral term. 2) They think any mid-route decryption/re-encryption is bad and dangerous. 3) They are mad about some aspect of CloudFlare's service, and call it MITM to make it sou…
Assumption: End-to-end encryption to the name on the certificate.
Reality: Someone else (Cloudflare) claims to be the name on the certificate, whereas in reality they’re not.
That’s the textbook definition of MITM attack, whether you like it or not.
Of course all CDNs work like that. No one’s claiming otherwise. Cloudflare is just bringing all the ways internet is fundamentally broken to the forefront. Their unapologetic and extensive abuse of those design flaws (captcha pages) are a constant reminder of just how a hopeless mess the internet is.
Re: DDoS protection
#165Earlier quoted context omitted.
If they’re stripping encryption and reapplying they’re MITM. Seems pretty straightforward.
It's amazing how you can redeclare the meaning of words and distort reality just to fit your narrative. Stripping encryption implies that there was, at some point, some sort of encryption between the browser and the website itself, which there never ever was . In the Cloudflare architecture the browser never ever interacts with the website, always with the Cloudflare servers. When you've got the small lock, it never…
The name on the certificate is not Cloudflare’s. It’s origin’s. There’s no legitimate mechanism for reverse proxies to operate HTTPs sites, other than to act as a dumb pipe. Calling it MITM is therefore entirely appropriate. Whether this protocol abuse is sanctioned by origin or not is entirely beside the point.
Re: DDoS protection
#166Earlier quoted context omitted.
Simply decrypting and re-encrypting web traffic in an intentional and authorized way is not MITM and should not called that. So, why do people call CloudFlare MITM? 1) They honestly don't know that MITM is just the name for an attack, not a neutral term. 2) They think any mid-route decryption/re-encryption is bad and dangerous. 3) They are mad about some aspect of CloudFlare's service, and call it MITM to make it sou…
Assumption: End-to-end encryption to the name on the certificate. Reality: Someone else (Cloudflare) claims to be the name on the certificate, whereas in reality they’re not. That’s the textbook definition of MITM attack, whether you like it or not. Of course all CDNs work like that. No one’s claiming otherwise. Cloudflare is just bringing all the ways internet is fundamentally broken to the forefront. Their unapolog…
And where is the website hosted? If you're on AWS, guess what, Amazon is decrypting the traffic, not the website owner.
Calling Cloudflare MITM but not Amazon is just demonstrating that you haven't thought carefully about how professional service providers work together to deliver a website.
The certificate authenticates that you are seeing the website that the website owner intended you to see. If the website owner hires Cloudflare as a professional service provider, that premise is not violated!
Re: DDoS protection
#167Earlier quoted context omitted.
Assumption: End-to-end encryption to the name on the certificate. Reality: Someone else (Cloudflare) claims to be the name on the certificate, whereas in reality they’re not. That’s the textbook definition of MITM attack, whether you like it or not. Of course all CDNs work like that. No one’s claiming otherwise. Cloudflare is just bringing all the ways internet is fundamentally broken to the forefront. Their unapolog…
And where is the website hosted? If you're on AWS, guess what, Amazon is decrypting the traffic, not the website owner. Calling Cloudflare MITM but not Amazon is just demonstrating that you haven't thought carefully about how professional service providers work together to deliver a website. The certificate authenticates that you are seeing the website that the website owner intended you to see. If the website owner…
The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature.
Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really all I’m arguing here. There’s plenty of better reasons to hate Cloudflare anyway.
Re: DDoS protection
#168Earlier quoted context omitted.
And where is the website hosted? If you're on AWS, guess what, Amazon is decrypting the traffic, not the website owner. Calling Cloudflare MITM but not Amazon is just demonstrating that you haven't thought carefully about how professional service providers work together to deliver a website. The certificate authenticates that you are seeing the website that the website owner intended you to see. If the website owner…
The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really al…
> The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature.
This puts you into segment #3 in my list above. And I agree with you: the CloudFlare "flexible" SSL that sends last-leg traffic in the clear over the open Internet is a terrible idea.
But while that terrible idea opens up the potential for MITM attacks, it is not, itself, a MITM because the website owner has authorized CloudFlare to do that.
And of course there are levels of CloudFlare service that do properly re-encrypt the last leg to the origin.
> Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really all I’m arguing here.
You need to understand that you are not correct on the technicality. None of the protocols used in HTTPS are violated by decrypting or encrypting a session using the proper keys, even if it happens several times along the way.
Not every bad idea is a technical protocol violation. Not every bad idea is equivalent to an attack.
Abusing the term "MITM" makes it harder to talk with specificity about actual MITM risks. If CloudFlare itself is always a "MITM", then how do we explain why their Flexible SSL service is riskier than their Full/Strict SSL service? The former makes it easier for some mid-point to impersonate or alter the origin website. But now what do we call that? An "actual" MITM? A "real" MITM?
Let's just leave MITM to mean an attack. It's a lot clearer that way.
Re: DDoS protection
#169Earlier quoted context omitted.
The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really al…
> The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. This puts you into segment #3 in my list above. And I agree with you: the CloudFlare "flexible" SSL that sends last-leg traffic in the clear over the open Internet is a terrible idea. But while that terrible idea opens up the potential for MITM attacks, it is n…
I think not having explicit support for proxies in HTTPs is a fundamental design mistake, so seeing how you’re keen on putting me in a camp, I’d like to volunteer for that one.
The term MITM is appropriate because it shows the whole thing is a charade. If handing off secret keys to third parties with absolutely no transparency past the first hop is the standard modus operandi then the entire protocol is a big fat joke. The only purpose, as far as I can tell, is to further centralize the web. First it was ICANN with domain registration, now it’s certificate authorities. Soon you’ll need a special permission from government to host a website.
HTTP(s) needs to be burned to the ground and replaced with something better. Liberty and freedom are at stake. How’s that for FUD.
Re: DDoS protection
#170Earlier quoted context omitted.
So carrier-grade NATs should also be captchad to hell. Somehow, they aren’t. Very mysterious, indeed.
Pure rough estimates, but consumer ISP subnets are probably ~1-3% malicious, while with Tor's rotating IPs, if you look over the past 5 years odds are at least 40% of exit node IPs have been associated with malicious activity at least once. It makes perfect sense to add additional verification challenges for Tor users. Also, anecdotal, but I work in infosec for a large US company and see a lot of traffic and read a l…
> It makes perfect sense to add additional verification challenges for Tor users.
I’m actually perfectly fine with that. The issue is how Cloudflare does it. They should just offer something like X-Cloudflare-Fraud-Score header or even tag (they’re already doing SSI), but instead they just nuke the hell out of everything.
The way they do ‘protection’ is openly hostile to open web, or even neutral web. Whether this affects Tor disproportionately or not is a minor point.