Really? Alright then, right now, off the top of your head: What are the set of TLS ciphers which are generally regarded by the security community to represent the highest security standards?

I have no clue. The AWS ALB 2016-08 security policy allows for ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384 and another 16 or so.

Of course, that's the default ALB policy. I didn't know that. There's a more strict TLS policy available: TLS-1-2-2017-01. Do you know what the difference between the 2016-08 and TLS-1-2-2017-01 policies are? I don't. I could look it up. Well, beyond disallowing TLS 1.0 and 1.1, TLS-1-2-2017-01 also disallows the ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA and ECDHE-ECDSA-AES256-SHA ciphers. Cool.

This shit is VERY domain specific. Its arcane. The way I worded those last three paragraphs was patronizing, to establish a point: No one knows this off the top of their heads. This naturally leads to two things I believe are true at any company (beyond a certain "garage"-scale): As few people as possible should worry about this, and even those people should encode it in some kind of automation that guarantees they don't have to be hands-on when configuring future resources which need this information.

Otherwise: YOU WILL GET IT WRONG. Guaranteed, at some point, maybe today, maybe in eight months, if you let every developer at a company worry about TLS ciphersets, one of them will screw it up. That's not patronizing; that's human nature. We're fallible. We don't all have massive domain expertise, and even the ones who do make mistakes. Manually configuring things is a guaranteed recipe for mistakes.

I'm using ciphersets as an example, but these things are everywhere. I don't trust any developer, including myself, to remember that by default most JWT libraries allow an alg of "none" to pass verification. I don't trust anyone to remember that S3 buckets by default allow per-object public read settings without a separate non-default bucket-level setting to block it. I don't trust anyone to remember that SQS FIFO queues only allow one concurrent reader per read group (nor understand what that means in practice, because this issue is Literally a weekly thing on /r/aws), or to know that hosting a public website on S3 is startlingly easy to DoS via egress network charges and AWS wont refund it.

Capital One, one of the biggest banks on the planet, was hacked because of a misconfigured S3 bucket. I have relieved myself of the hubris of believing I can do this on my own, a hubris every developer needs to relieve themselves of. Encode this stuff into automation and have every eye you can find inspect your changes. And while there's room to give developers a lot of power in this setup, part of that is not "here's an AWS account, have fun".

I agree that developers make mistakes and humans are fallible. Why then do you want me to list permissible cipher systems off the top of my head? Of course I would look that up. (I’ve got a JIRA issue from a couple of years ago about this topic.)

By saying that I want developers to worry about TLS algorithms, I mean that I want developers to worry about everything and understand that they have shared ownership of the production system.

I lead a small dev team working in a reasonably sized division of a large company. We’re accountable for both operations and development, and we’re security-sensitive (I have domain expertise in DFIR). It’s my ass if we screw up any of the ways you cite. We mitigate that risk in a lot of different ways, and I try to seek out new things we can do to ratchet up the quality of our build products.

Again, I think your insistence that things be a certain way doesn’t fit my situation. Have a good evening.