sure. Disable it by default, but leave it compiled in, so an admin can re-enable it by changing a config setting instead of recompiling half a distro.
> and thus putting yourself at risk too
I'm not at risk if some big restaurant chain orders their supplies over TLS 1.1 instead of TLS 1.2. I'm not at risk if their email server sends us support tickets over TLS 1.1 instead of 1.2.
However, my business is at risk if they can't order their supplies and if I then can't receive the support email telling me so.
> patch in garbage like null cipher support into ssh
there's a huge difference there: null-ciphers are completely pointless and no known client out there only supports null-ciphers.
But about 30% of the internet doesn't support TLS 1.2.
Its unfortunate that this situation causes you problems, but there is literally no other way that some people will ever upgrade their shit, you could wait 10 years and they will still be using tls1.1.
Its important to at least make it harder than flip some switch and forget about it forever, or nothing is going to change.
I agree that there is the absolute need for advocacy. I agree that we need to get rid of old TLS. But I disagree that it’s up to the OSes to make this a compile time issue.
If Debian comes out in 2019 in a state where 30% of the internet can’t talk to it without recompiling the daemon packages, then people will switch to „more compatible“ distros.
I have the infrastructure to quickly deploy patched packages, so for me this is just an annoyance (also because these self-built packages I have to security-patch myself, which is actually putting me at risk), but others don’t. For them this will be a reason to switch distros
thing is chrome and firefox are almost certainly going to disable it well before then, and thats gonna make a shitload of people enable it, not everyone granted, but its going to be a lot lower than 30%
(Edit: this reply is a reply to a your comment before your edit that stated I was at risk because of non-mitigatable issues in 1.1)
My 1.1 supporting customers are at risk. I'm not at risk.
If they take the (unwise) decision that the risk of their connections being eavesdropped is less significant that the amount of work it takes to update their internal network, than its their decision. I am absolutely not in the position to do advocacy there.
And neither are other companies who have to serve enterprise customers.
„But allowing 1.1 will allow attackers to force secure 1.2 supporting clients to downgrade“ you might say. To which I reply: why are they still supporting 1.1? If they are security conscious enough to update their infrastructure to support 1.2, they can disable anything else when talking to me.
Then the regulations need to have a mechanism to be updated in the case of new knowledge. If the regulations have no process to be updated then that is a more fundamental problem to solve.
After all, Debian is set to give the process of change 2 years. That is plenty of time for updating the regulation and processes.
Any joker can start a company and declare any regulation they like. I could require that all software be written in COBOL by moustachioed developers standing on one foot.
If I did that, I think Debian would not change their software to meet my bizarre "company regulations"
When I talk to my virtual machines over the loopback device, I have to encrypt and then decrypt the traffic. That is pointless. I wish my SSH supported the null cipher.
If it supported the null cipher by default, users would be a single misconfiguration away from losing all security. By forcing the few who have a legitimate need for a null cipher to patch and recompile, this risk is reduced.
It's the same reason reputable crypto libraries avoid implementing things like the TLS null cipher suites (they exist), and also why the new TLS 1.3 protocol has only PFS suites and AEAD.
sure. Disable it by default, but leave it compiled in, so an admin can re-enable it by changing a config setting instead of recompiling half a distro.
> and thus putting yourself at risk too
I'm not at risk if some big restaurant chain orders their supplies over TLS 1.1 instead of TLS 1.2. I'm not at risk if their email server sends us support tickets over TLS 1.1 instead of 1.2.
However, my business is at risk if they can't order their supplies and if I then can't receive the support email telling me so.
> patch in garbage like null cipher support into ssh
there's a huge difference there: null-ciphers are completely pointless and no known client out there only supports null-ciphers.
But about 30% of the internet doesn't support TLS 1.2.