4 ms·

Honest question but no deep answer requested, why do we have to choose the ciphers? Not only it adds 2^(number of ciphers) ways to misconfigure the server with

Honest question but no deep answer requested, why do we have to choose the ciphers? Not only it adds 2^(number of ciphers) ways to misconfigure the server with a gaping security leak, but names are obscure and strings are NEVER the same between nginx and the SSLlabs website which advises what is correct, plus who knows whether SSLLabs is a trustworthy website. Also, 6 months later the ciphers might not be up to date. Why do I have to even choose ciphers? Why isn’t this TLS 1.2.1, then 1.2.2, and so on? It’s like going to Amazon, choosing n resistors by guessing their value, going to m people asking them if it’s 12 ohms, most of them having no clue what they are talking about, and using it for an airport security device that can put people in jail.

shaicoleman 6y ago
Different ciphers have different tradeoffs (security/vulnerablities/performance/hardware acceleration/compatibility/newness/etc.). Indeed, more choice means more ways to mess things up, more complexity, more bugs and more vulnerabilities. That's why TLS 1.3 reduces the cipher suite choice to 5 ciphers, down from 37 from TLS 1.2 (in previous versions there were 319 in total) [1] 1. https://owasp.org/www-chapter-london/assets/slides/OWASPLondon20180125_TLSv1.3_Andy_Brodie.pdf https://owasp.org/www-chapter-london/assets/slides/OWASPLond...
lmm 6y ago
Back when TLS (or rather SSL) was originally designed, people were very aware of cipher vulnerabilities - there was a lot of academic attention on them, there was a recent history of ciphers being broken, and US export restrictions forced international programs to support a known-weak cipher (DES). People were much less aware of protocol vulnerabilities - security protocols were nowhere near as widespread and weren't really the subject of academic study. So at the time people expected to need to upgrade ciphers relatively often but upgrade the protocol rarely, if at all, and designing the majority of the protocol to be fixed with the ciphers as a pluggable, swappable part made sense.
tialaramex 6y ago
In some ways this is OpenSSL's fault. So the first answer is, your tooling decided to make you answer this question instead of picking its own answer based on the expertise of the authors. A 1990s TV could have a UI where you need to explicitly configure which pins of a SCART connector have what signals on them, but that would be crazy so the TV just worked with the usual SCART pins as defined and if your pin-out is weird it won't work. The TLS 1.2 standard itself doesn't say "Make the user or administrator pick from this huge list". You can make cipher suite decisions like this in SSH too, but you probably mostly don't because the defaults are fine. Now, the technical answer as to why there's something to pick from at all goes like this: TLS is a negotiated protocol. Some HN regulars are convinced negotiation is a bad idea, and indeed they will point to TLS as an example. But the idea is that with a vast population of servers and clients on the Internet it isn't actually practical to hold a flag day (replacing all software on clients and servers immediately) to upgrade TLS. Different clients and servers may have different priorities, so we'd like them to be able to agree each time on something they're both content with. For example on your general purpose laptop there is hardware AES, so AES ciphers are fast and secure, but some cheap devices don't have that, so for them AES is annoyingly slow/ power hungry. As a result they'd prefer ChaCha20 if possible. How did the list get so long? There's a point around the turn of the century when countries realise oh, this Internet thing is important, and you get a rash of "cryptographic nationalism" where a government that likes to think of itself as important notices the US government made things like DES and it decides it can do that too, resulting in vanity ciphers which are less analysed, less popular, and basically have no reason to exist. TLS 1.2 doesn't explicitly discourage you from supporting these, and OpenSSL is a stamp collector's library, if a cipher exists and you can implement it, why not? So you get this unwieldy list nobody actually needs, and then apps present it to non-experts like "Pick from this list or be doomed". You can get advice on how to configure web servers from Mozilla, https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/ For other types of TLS server you should seek advice from experts in the appropriate protocol. In TLS 1.3 they learned from this mistake and discourage cryptographic nationalism, you have a literal handful of choices, all of them are currently believed to be safe, some are likely poor (slow, power hungry) choices on simple hardware, some would be weak if large quantum computers were actually cheap and readily available, rather than horribly expensive and non-existent. So "I don't care, whatever" is thus safe in TLS 1.3 although presumably OpenSSL still expects you to actually pick anyway.

shaicoleman 6y ago

Different ciphers have different tradeoffs (security/vulnerablities/performance/hardware acceleration/compatibility/newness/etc.). Indeed, more choice means more ways to mess things up, more complexity, more bugs and more vulnerabilities. That's why TLS 1.3 reduces the cipher suite choice to 5 ciphers, down from 37 from TLS 1.2 (in previous versions there were 319 in total) [1] 1. https://owasp.org/www-chapter-london/assets/slides/OWASPLondon20180125_TLSv1.3_Andy_Brodie.pdf https://owasp.org/www-chapter-london/assets/slides/OWASPLond...

lmm 6y ago

Back when TLS (or rather SSL) was originally designed, people were very aware of cipher vulnerabilities - there was a lot of academic attention on them, there was a recent history of ciphers being broken, and US export restrictions forced international programs to support a known-weak cipher (DES). People were much less aware of protocol vulnerabilities - security protocols were nowhere near as widespread and weren't really the subject of academic study. So at the time people expected to need to upgrade ciphers relatively often but upgrade the protocol rarely, if at all, and designing the majority of the protocol to be fixed with the ciphers as a pluggable, swappable part made sense.

tialaramex 6y ago

In some ways this is OpenSSL's fault. So the first answer is, your tooling decided to make you answer this question instead of picking its own answer based on the expertise of the authors. A 1990s TV could have a UI where you need to explicitly configure which pins of a SCART connector have what signals on them, but that would be crazy so the TV just worked with the usual SCART pins as defined and if your pin-out is weird it won't work. The TLS 1.2 standard itself doesn't say "Make the user or administrator pick from this huge list". You can make cipher suite decisions like this in SSH too, but you probably mostly don't because the defaults are fine. Now, the technical answer as to why there's something to pick from at all goes like this: TLS is a negotiated protocol. Some HN regulars are convinced negotiation is a bad idea, and indeed they will point to TLS as an example. But the idea is that with a vast population of servers and clients on the Internet it isn't actually practical to hold a flag day (replacing all software on clients and servers immediately) to upgrade TLS. Different clients and servers may have different priorities, so we'd like them to be able to agree each time on something they're both content with. For example on your general purpose laptop there is hardware AES, so AES ciphers are fast and secure, but some cheap devices don't have that, so for them AES is annoyingly slow/ power hungry. As a result they'd prefer ChaCha20 if possible. How did the list get so long? There's a point around the turn of the century when countries realise oh, this Internet thing is important, and you get a rash of "cryptographic nationalism" where a government that likes to think of itself as important notices the US government made things like DES and it decides it can do that too, resulting in vanity ciphers which are less analysed, less popular, and basically have no reason to exist. TLS 1.2 doesn't explicitly discourage you from supporting these, and OpenSSL is a stamp collector's library, if a cipher exists and you can implement it, why not? So you get this unwieldy list nobody actually needs, and then apps present it to non-experts like "Pick from this list or be doomed". You can get advice on how to configure web servers from Mozilla, https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/ For other types of TLS server you should seek advice from experts in the appropriate protocol. In TLS 1.3 they learned from this mistake and discourage cryptographic nationalism, you have a literal handful of choices, all of them are currently believed to be safe, some are likely poor (slow, power hungry) choices on simple hardware, some would be weak if large quantum computers were actually cheap and readily available, rather than horribly expensive and non-existent. So "I don't care, whatever" is thus safe in TLS 1.3 although presumably OpenSSL still expects you to actually pick anyway.