chiisana

There’s two ways around the symptoms you’re trying to treat:

1. Don’t bother with internal vs external. Always route through external which gets encrypted by the origin cert to CloudFlare and then CloudFlare to your browser. This is simplest in that you don’t need to manage two sets of DNS records and you don’t end up with different certificates for the same domain (in the odd event where you end up needing to do something like certificate pinning). Or;
2. Just add the origin cert to your systems’ trust store. You know the certificate, it will encrypt the traffic anyway, also you’re accessing the service via intranet so there’s really no attack vector here.

Probably worth calling out that although 1 feels like there’s more hops (and there absolutely are), with any decent internet, you’re probably not going to feel it. This is because the edge server is probably situated very close to your ISP (that’s how they make sure everything responds quickly) so your over all round trip should only be affected by a negligible amount of time that you most likely won’t notice.

Countries like Singapore where there’s death penalty for drug possession/trafficking — whether we agree with it or not is secondary here, just highlighting purely from a whether or not it is working point of view — seems to be working.

I’m not condoning the death penalty, far from it; but I’m inclined to think actual enforcement (instead of catch and release that we have now), with support programs to get people off the stuff, will steer the needle towards better direction, as opposed to decriminalizing it and let people who needs help continue to abuse illicit drugs the way they want, where they want, when they want.

The RAID rebuild time is going to be longer than the OEM warranty… love it!

Fortunately, you’d be very hard pressed to find bandwidth pricing from 18 years ago.

The point is the claimed issue is really a non issue, and there are much more effective ways to stress websites without needing the intermediary of fediverse.

AWS charges $0.09/GB. Even assuming zero caching and always dynamically requested content, you’d need 100x this “attack” to rack up $1 in bandwidth fees. There are way faster ways to rack up bandwidth fees. I remember the days where I paid $1/GB of egress on overage, and even then, this 100MB would’ve only set me back $0.15 at worst.

Also worth noting that those who’d host on AWS isn’t going to blink at $1 in bandwidth fees; they’d be hosting else where that offers cheaper egress (I.e. billed by megabits or some generous fixed allocation); those that are more sane would be serving behind CDNs that’d be even cheaper.

This is a non-issue written by someone who clearly doesn’t know what they’re talking about, likely intended to drum up traffic to their site.

If you’ve skimmed over the original publication, it is actually worse: it is a non problem. Other users have pointed out already: ~100MB served over 5 minutes period is quite literally nothing for even one small VPS serving the content independently, let alone a site with CloudFlare in front like they claim to have.

Or 4) Ignore noise and do nothing; this is a case of user talking about things they don’t understand at best, or a blog intentionally misleading others to drum up traffic for themselves at worst. This is literally not a problem. Serving that kind of traffic can be done on a single server without any CDN and they’ve got a CDN already.

I think this might work, I haven’t done it for too long to know for certain if two same plain text encrypted with two same public key would yield two identical encrypted blobs.

I’ve self replied another possible implementation, that I’m pretty proud of figuring out literally 1AM. If you have time, please do give it a glance and see if you can spot any weakness.

Aha! Something just clicked — been thinking continuously since before the original reply. The answer is … more signing and maybe even more keys!

A message would be signed multiple times.

If Bob wants to send Alice “Hello, how are you?” the plain text would be signed with Bob’s general private key that could be verified with Bob’s general public key. This would allow Alice to forward this message to anyone while they could still verify it did indeed came from Bob.

The plain text and signature is then encrypted with one of Alice’s public keys, so only Alice could decrypt it to see the message and signature. This may be a thread specific key pair for Alice so they’re not re-using same keys between different threads.

The encrypted message is then again signed by Bob, using one of Bob’s private key, so that Alice can know the encrypted message has not been altered. This here could also be the thread specific key as noted above.

If Alice were to report Bob, Alice will need to include both the plaintext and the internal signature. This way the internally signed message could be reviewed if the plaintext and signature were forwarded to moderation for review by Charlie (just need to verify the signature against plaintext with Bob’s public key), while the exchange should be secure to only Alice and Bob.

Et voila!

Been forever since I did any work with cryptography, but if my memory is correct:

Alice needs Bob’s public key to verify a signed message from Bob haven’t been altered;

Bob needs Alice’s public key to encrypt a message that can only be decrypted by Alice;

If Bob sends Alice a message encrypted with Alice’s public key, signed with Bob’s private key, containing “Hello, how are you?” ; this message could be verified as authentic by Charlie using Bob’s public key but Charlie cannot see the contents of the message as Charlie does not have Alice’s private key.

Without Alice disclosing their private key, how can Charlie review the content of a reported message from Alice claiming Bob sent them something inappropriate?

I.e. how can Charlie be certain if Alice claims Bob sent “cats are evil” when Charlie cannot decrypt the original message, only verify the original message have not been altered via Bob’s public key.

If you’re feeling that it will take too much time to maintain something you’re deploying, then there may also be toolset/skillset mismatch. Take Docker/K8s that you’ve called out for example; they’re the graduated steps to deploy things in the industry. Things deployed via Docker drastically reduces the amount of time to get up and running by eliminating large swaths of dependency management, as well as gives option to use tools on platform to manage self updates if that’s something desired (though this could potentially introduce failures by manual upgrade steps where required). You’d graduate to k8s as your infrastructure footprints start to grow. Learning the correct tools could potentially reduce the barrier to entry and time requirements on the apps front.

Having said that, it is probably better to ask the inverse: what is it that you’re trying to achieve and why?

Without a reason that resonates well with you, you’re not going to find time in your allegedly already life to maintain to keep it working. Nor will you be willing to find the time to learn the correct tools to deploy these things.

I played with it forever ago, but from memory, that is most likely due to the way it is designed to conserve battery. The app waits for significant location update notifications from the OS and then sends the updated location to the tracking server. It doesn’t (or I should say it didn’t as I don’t know about now) actively poll the location on fixed intervals.