4 ms·

> thinking of setting my personal site to TLS 1.3 only I wouldn't recommend doing that. You might end up blocking users using a proxy (e.g. for privacy reasons

> thinking of setting my personal site to TLS 1.3 only I wouldn't recommend doing that. You might end up blocking users using a proxy (e.g. for privacy reasons), people on corporate networks, people in China [1], and many other non-traditional browsers (e.g. browsers for the blind, game consoles), users on older versions of curl/wget/lynx, older mobile phones, etc. TLS 1.2 when correctly configured is still perfectly fine. And users with modern browsers will connect with TLS 1.3. TLS 1.3 also has protections against downgrade attacks. Another good scanner for SSL is Qualys SSL Server Test [2]. Getting an A+ score there doesn't require disabling TLS 1.2 For secure configuration, you can use Mozilla SSL Configuration Generator [3] 1. https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/ https://www.zdnet.com/article/china-is-now-blocking-all-encr... 2. https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ 3. https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/

staticassertion 6y ago
> perfectly secure. I think you're trying to use 'perfectly secure' here the way one might say 'perfectly fine', which changes the reading a lot from a first pass. That said, I agree, there is a subset of TLS 1.2 that is suitable.
- shaicoleman 6y ago
  Agreed, updated that
laurent92 6y ago
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.
throwaways885 6y ago
> people on corporate networks, people in China By supporting older protocols on sites, we're enabling this kind of abuse to run rampant. Maybe it's best to just cut them off.
- shaicoleman 6y ago
  I believe that ends up with hurting more the people who are already affected by these policies. In the end they just get replaced with something worse. e.g. I think that Google offering censored search in China is a lesser evil than Baidu, which is not only censored, but likely also tracks and reports all your searches to the government
lazyweb 6y ago
Hm, thanks for your reply. I'm already obsessing over the SSL test in your 2nd link, having set everything to achieve an A+, including DNS CAA and all the recommended technical mitigations. But your point regarding accessibility is an important one, I think. Even though my page doesn't generate a lot of traffic that's something I wouldn't want to shut out.

staticassertion 6y ago

> perfectly secure. I think you're trying to use 'perfectly secure' here the way one might say 'perfectly fine', which changes the reading a lot from a first pass. That said, I agree, there is a subset of TLS 1.2 that is suitable.

shaicoleman 6y ago
Agreed, updated that

laurent92 6y ago

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.

throwaways885 6y ago

> people on corporate networks, people in China By supporting older protocols on sites, we're enabling this kind of abuse to run rampant. Maybe it's best to just cut them off.

shaicoleman 6y ago
I believe that ends up with hurting more the people who are already affected by these policies. In the end they just get replaced with something worse. e.g. I think that Google offering censored search in China is a lesser evil than Baidu, which is not only censored, but likely also tracks and reports all your searches to the government

lazyweb 6y ago

Hm, thanks for your reply. I'm already obsessing over the SSL test in your 2nd link, having set everything to achieve an A+, including DNS CAA and all the recommended technical mitigations. But your point regarding accessibility is an important one, I think. Even though my page doesn't generate a lot of traffic that's something I wouldn't want to shut out.