wary solar
if you service behind ssl terminating proxy, then it's common to keep unencrypted communication in this case
#is it a good idea to remove TLS from my tokio axum server?
grand skiff
use a proxy. separation of concerns and all tha
sand tendon
++ i generally treat tls termination at the app layer as a last resort. Even without a totally separate load balancer, you can always run a lightweight reverse proxy on host via something like envoy (or nginx)
What is the architecture between cloudfront and your app? Are you able to use origin cloaking? Is your app exposed on the public internet?
user requests go through cloudfront and then cloudfront forwards the request to my server
This is the expected path, but are other paths possible?
It's true that cloudfront will terminate tls for you. Generally you will want to load your own tls cert into cloudfront since you want to front with a custom domain
But for the cloudfront -> app hop, you'll generally want to lock down the network layer somehow. Origin cloaking is convenient. There are other approaches though depending on your origin.
As a side note, there is a non-zero perf cost from TLS termination that actually is currently worse in async rust than other languages. It has to do with how compute-heavy workloads are handled w/r/t the async worker threads. It can interfere with quicker tasks due to extended blocking.
For cloudfront -> app, cloudfront keeps long-lived connections open so it's not that big a deal. But if you have for instance NLB health checks operating over TLS, that might be noticeable. Or large spikes in connection count that might require cloudfront to spin up many new connections.
It's something I'm working on improving, probably not a critical factor, the biggest benefit is separation of concerns. But it's something I've been seeing impact from of late (if you have large numbers of connections being established). For the occasional new connection, though, it's marginal impact.
grand skiff
why not?
i'd imagine because cloudfront is an AWS product there's a way to set them up together on a private network
sand tendon
Yes, origin cloaking is one way
There also is a managed prefix list for cloudfront if you don't have something supporting origin cloaking but do have a security group
Keep in mind that cloudfront hosts are multi tenant so even with your network locked down to cf, you want to further lock it down to your own distribution only
Where does your app live
What kind of host
sand tendon
Yes, I work for aws
grand skiff
ooo cool
sand tendon
I believe light sail is backed by ec2
I'm not sure if origin cloaking is natively supported, but I can poke around later
Hah, probably a mix of both. It was back in my bicycle courier days, less road rash lately
sand tendon
Lightsail is actually really locked down... you don't have access to security groups to add cloudfront managed prefix list on, nor the underlying ec2 instance to use cloudfront origin access control with.
probably best you could do would be follow the 'access control based on shared secret key' here: https://aws.amazon.com/developer/application-security-performance/articles/origin-cloaking/
and inject a custom header with a secret key, and then validate it on the application layer. and drop all traffic early that doesn't have that header
wouldn't defray infra costs though if somebody malicious started spamming you with traffic directly or via a different cloudfront distribution. if that starts to become a problem, probably move from lightsail to something like ec2 or ecs fargate
anyway, the TLDR is, unless you have a specific security or compliance reason to be https in transit from cloudfront to origin, http is probably fine. aws does implicitly does have some encryption in the transport layer that is used for vpc / amazon backbone though that isn't a substitute for using https. but you probably don't need it
i mean i personally wouldn't use lightsail, but if you just want something turnkey, it is designed to be really simple. depends on how much you care to learn aws
yeah, then maybe just use lightsail until you start to hit issues.
https -> http doesn't really have much to do with that security posture
the question is whether your server will accept connections from clients besides your own distribution. regardless of whether it is http or https
the answer is, without a lot of effort, you can't really reject those connections at the network level (though you can close all ports you aren't using). so you're still going to have scanners reaching you, etc.
but you can inject a secret header with cloudfront and at least drop traffic early once connection is open, if header is absent
you do have access to the cloudfront console by the way, if you go outside lightsail console.
you can also install fail2ban or something like that
the benefit of cloudfront is that it has a lot of implicit ddos controls
so if somebody can reach you directly, you can't rely on that
though if you're going to start getting into managing your environment and installing things like fail2ban, you are still learning sysadmin/devops ^^ just for linux rather than cloud services
that is trustworthy if cloudfront sends it, but only the final entry in it. before that is spoofable. also anything sent by a non-trusted proxy (ie, not cloudfront). and unless you want to manage retrieving the cloudfront ip list at runtime to validate, you're not going to know,.
ie, don't use it just for security, but if it's useful for eg localization, go for it
if you want to lock down app to only your origin, you want to inject a custom header with a secret value
you would need to be able to validate the ip address or rdns lookup of anybody presenting a xff header. so the direct proxy for the last entry, the last entry for second to last, etc. you need a trust relationship. since clients can specify an arbitrary header.
those libraries are just letting you ergonomically interact with it.
if you are going to throttle/fail2ban, definitely use the XFF header since otherwise you'll throttle cloudfront which is quite bad. but it isn't foolproof without a trust relationship.
they are referring to special headers set by a cdn like cloudfront. if they have logic in their code to lookup the terminating ip address to validate authenticity before using the header, then great. otherwise this is a tool to be used alongside validating the ip
this is all it is: https://github.com/imbolc/axum-client-ip/blob/main/src/secure.rs
so while they can retrieve the right header, they rely on the caller to say, 'yes this is definitely cloudfront'
sure, browse it at your own pace. good luck! seems like you have is ok for now, anyway if you get slammed with a ddos, generally aws will comp your first 'whoopsie'. so you can always harden later
don't quote me, obviously, but i see it very frequently 😛