(Hi I'm not tptacek but I am also a Latacora principal and I co-edited this new version of the document)

When you're setting up ELB today you're probably getting ELBv2, specifically an ALB (since we're discussing TLS termination here). There are a few things I like a lot about the way you do TLS configuration for an ALB, but notably:

* Instead of giving you the ability to configure literally everything, they have a handful of profiles. Even the worst profile you can pick is still great. There's just no way to misconfigure ALB TLS, and there are LOTS of ways to misconfigure TLS in general.

* It is _super easy_ to get a cert for your ALB with ACM. There's somehow even less to do than if you're setting up Caddy or whatever + LE normally.

Remember: the goal of that document is to make the common case as simple as it can be and ALB does a pretty bang-up job there. If you don't have a good reason to keep that infra in-house, ALB is fine.

I don't think we have any special info about the security of ALB, but I think it's fair to say that if someone had a serious vuln in ALBs that'd be News(TM). And, if someone had a serious vuln in nginx or whatever, AWS would fix its infra faster than everyone will patch their nginxs :)

Does this hold for other AWS services that manage https endpoints? Especially Cloudfront which seems to be the de facto solution for anything serverless. Integration with ACM obviously also comes out of the box, but I haven’t looked under the hood at the implementation (besides IIRC a « you can have any color provided it’s black » approach to security options)

I'm not sure I follow with Cloudfront <-> serverless but generally: sure? I don't like giving blanket recommendations when I haven't audited everything I'm recommending but generally speaking: yes.

By cloudfront and serverless, I mean that if you want S3 hosting + https you need a Clousfront distribution. If you use a custom domain name with your API GW there’s a Cloudfront distribution created behind the scenes. And I believe the same holds for Lambda@edge. In other words, if you’re not relying on VMs + ELB (or Elastic Beanstalk) to host your application, it seems that the only way to use an https certificate is through Cloudfront.

Makes sense, thanks. Did the document mention ALB yesterday?

I didn’t put it up, but I think I mentioned ALB in one of the editing passes. Could’ve missed it then though, so no idea :)

I've been working on ELB day-to-day since 2013, first as Principal engineer and now as one of the AWS services I focus on and help out. I do have some special insight - feel free to AMA.

I can get pretty deep on the TLS/SSL side if you have specifics; I'm also the main author of s2n, our Open Source implementation of TLS, and a participant in the TLS1.3 process.

Hey, this is largely off-topic but worth a punt: do you have any info on when AWS IoT (maybe other AWS services as well?) will move off the dependency on the Verisign RSA/SHA-1 CA? I'd love to get a certificate chain that was ECDSA or RSA sigs only (and would also love to be able to turn off SHA-1 for the obvious reason).