5 ms·

I think introducing some friction here is a good idea, pre 1.2 tls/ssl are objectively broken, insecure protocols. Unless some of these people experience some

by throwaway2048 9y ago

I think introducing some friction here is a good idea, pre 1.2 tls/ssl are objectively broken, insecure protocols. Unless some of these people experience some pain and fix their shit, they will never upgrade, and by extension keeping everyone that wishes to communicate with them vulnerable as well (due to BAD_GUY being able to force protocol downgrades) Is it the right solution to accommodate them (not to mention by default out of the box which means it hurts your users without them being aware of it or able to make an informed choice) and pretend it isn't a problem, and thus putting yourself at risk too? For the same reasons i think its highly irresponsible people like FreeBSD patch in garbage like null cipher support into ssh. It is broken let the people who have to use it for whatever weird reason deal with the burden of their broken shit, don't force it on everyone else and weaken their security.

pilif 9y ago
> not to mention by default out of the box 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.
- throwaway2048 9y ago
  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.
  - pilif 9y ago
    (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.
    - madez 9y ago
      The solution seems straight forward. Okay with being eavesdropped? Do it unencrypted. Not okay with being eavesdropped? Use not broken cryptography.
      - pilif 9y ago
        Company regulations require all communication to be encrypted, but they don't specify the protocol to use, so TLS 1.1 is fine but no TLS is banned. I'm not making this up.
        madez 9y ago
        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.
        majewsky 9y ago
        > 2 years Also, you can stay on oldstable for a while if you absolutely cannot upgrade.
- filmor 9y ago
  Shouldn't recompiling OpenSSL be enough? It's usually dynamically linked, isn't it?
  - pilif 9y ago
    That depends on the daemon software. It might compile-time feature-check OpenSSL
  - cft 9y ago
    You might have to recompile the entire stack on top of it, for example python , Apache, mod_python etc. It's a lot of work just to enable tls 1.1
- jwilk 9y ago
  The null cipher in SSH is not pointless. 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.
  - cesarb 9y ago
    > I wish my SSH supported the null cipher. That's very risky. 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.
  - greenhouse_gas 9y ago
    If you don't wasn't encryption, why not just use telnet?
    - jwilk 9y ago
      I want public key authentication and non-interactive sessions.

pilif 9y ago

> not to mention by default out of the box 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.

throwaway2048 9y ago
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.
- pilif 9y ago
  (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.
  - madez 9y ago
    The solution seems straight forward. Okay with being eavesdropped? Do it unencrypted. Not okay with being eavesdropped? Use not broken cryptography.
    - pilif 9y ago
      Company regulations require all communication to be encrypted, but they don't specify the protocol to use, so TLS 1.1 is fine but no TLS is banned. I'm not making this up.
      - madez 9y ago
        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.
        majewsky 9y ago
        > 2 years Also, you can stay on oldstable for a while if you absolutely cannot upgrade.
filmor 9y ago
Shouldn't recompiling OpenSSL be enough? It's usually dynamically linked, isn't it?
- pilif 9y ago
  That depends on the daemon software. It might compile-time feature-check OpenSSL
- cft 9y ago
  You might have to recompile the entire stack on top of it, for example python , Apache, mod_python etc. It's a lot of work just to enable tls 1.1
jwilk 9y ago
The null cipher in SSH is not pointless. 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.
- cesarb 9y ago
  > I wish my SSH supported the null cipher. That's very risky. 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.
- greenhouse_gas 9y ago
  If you don't wasn't encryption, why not just use telnet?
  - jwilk 9y ago
    I want public key authentication and non-interactive sessions.