111–120 of 140 posts
Wont this just prompt NSA to crack the others if they see a spike in disabled crackables?
Fortifying the current weakest link raises the overall security of the remaining system. Whether your threat model includes the NSA or not, disabling the weakest TLS algos is likely to increase your network security.
Earlier quoted context omitted.
Do you know what VPN protocol it is? I wonder if it would be easy to figure out in Wireshark if you had a recording of the beginning of a session.
QUIC is what WireShark says I am looking at. I can see the DNS lookup, and then a stream of encrypted UDP packets with not much plain text in the payloads. I get what the other poster says about asking the provider, but I wouldn't have much confidence in the answer.
If you're having trouble following the instructions to secure SSH on OSX, try following the directions here: https://mochtu.de/2015/01/07/updating-openssh-on-mac-os-x-10... Without using the brew dupe and ` --with-keychain-support` flag, I was getting cipher errors when trying to use SSH after following the instructions linked to in TFA. NB: I am not a security expert.
Earlier quoted context omitted.
> don't use weak moduli. By this do you mean don't use 1024 bit keys? Would using 2048 bit (or larger) mean that the NSA wouldn't be able to buy a computer that could do the computation within a year? Why don't we all use 2048 bit keys then? Is the communication and processing overhead so high that we'd rather be vulnerable? Edit to add: I'm not an expert, but I'm competent enough to force a certain level of crypto o…
> By this do you mean don't use 1024 bit keys? Would using 2048 bit (or larger) mean that the NSA wouldn't be able to buy a computer that could do the computation within a year? Keep in mind, going from 1024 to 2048 bit DH parameters doesn't double the search space, it raises it from 2^1024 to 2^2048. At some point the search space gets so large that you'd need more energy than required to boil all of Earth's oceans…
Earlier quoted context omitted.
Why is it not a reasonable assumption that the NSA (and possibly other actors with the means) are doing so? / Why wouldn't you do it in their position?
Because this particular military spy organisation is being deployed by the US government against its own citizens, en masse, as an end-around well-established due process and constitutional protections that require individualised suspicion of wrongdoing. It also represents a giant exfiltration target for other state actors, like those who breached OPM. NSA hurts the security of Americans under the guise of preventing…
But it's not. That's the problem. There's no evidence whatsoever of it doing that.
If you're having trouble following the instructions to secure SSH on OSX, try following the directions here: https://mochtu.de/2015/01/07/updating-openssh-on-mac-os-x-10... Without using the brew dupe and ` --with-keychain-support` flag, I was getting cipher errors when trying to use SSH after following the instructions linked to in TFA. NB: I am not a security expert.
If you are on El Capitan, it is not needed to install a brewed openssh. OpenSSH pre-bundled with El Capitan is already pretty up-to-date and includes most of the new ciphersuites.
OpenSSH 7.0 and above disable group 1 Diffie-Hellman by default.
From http://www.openssh.com/txt/release-7.0:
Support for the 1024-bit diffie-hellman-group1-sha1 key exchange is disabled by default at run-time. It may be re-enabled using the instructions at http://www.openssh.com/legacy.html
Is there any reason why in TLS the DH g^x the client sends is not encrypted with the server's RSA key? That way, a DH compromise merely lose forward secrecy and the data would still be safe as long as the server private keys are not compromised.
The practical reason is probably that using DHE with TLS is already many times slower than (plain) RSA. This would only make it slower.
My big picture take-away is: It seems that the NSA (and possibly other state-level actors) can access encrypted traffic that uses 1024-bit Diffie-Hellman that use commonly-used prime numbers. This means HTTPS, SSH, IPsec, SMTPS, and protocols that rely on TLS are potentially vulnerable. Where’s there’s smoke, there’s fire and there’s a lot of smoke indicating the NSA can do this. They have the money, technology, infr…
How does it "seem this"? There's no evidence, no plausibility, no sense here whatsoever. Someone hypothetically conjectured a magic all-powerful computer that could magically crack a prime, and that would magically make us all vulnerable to the government who want to steal the data from my recipe startup and the church newsletters documents on my laptop.
And therefore, system admins are all recommending upgrading to 2048 keys?
I can't see the sense or logic here. It just seems hysterical conspiracy nonsense to me.
Earlier quoted context omitted.
It may be misleading but also in the sense that there's no recommendation to just drop VPN altogether. How about we just stop relying on terribly over-designed protocols such as VPN and IPSec? Complexity is the enemy of security.
We use OpenVPN at work to provide layer 2 access to a management network that uses a /24 out of the 10/8 range. How else do you think we should do this?
My big picture take-away is: It seems that the NSA (and possibly other state-level actors) can access encrypted traffic that uses 1024-bit Diffie-Hellman that use commonly-used prime numbers. This means HTTPS, SSH, IPsec, SMTPS, and protocols that rely on TLS are potentially vulnerable. Where’s there’s smoke, there’s fire and there’s a lot of smoke indicating the NSA can do this. They have the money, technology, infr…
"It seems that the NSA (and possibly other state-level actors) can access encrypted traffic that uses 1024-bit Diffie-Hellman that use commonly-used prime numbers." How does it "seem this"? There's no evidence, no plausibility, no sense here whatsoever. Someone hypothetically conjectured a magic all-powerful computer that could magically crack a prime, and that would magically make us all vulnerable to the government…
In order to defend against adversaries with undisclosed capabilities, you have to extrapolate known attack methods and hardware to produce estimates of what may be practical. Every paper that proposes keylength and parameter size recommendations does this. If we didn't extrapolate this way, there would have been no reason to stop using 56-bit symmetric ciphers until 1998 (!). The hardware necessary to crack such a cipher could have been dismissed as "magical" because nobody who had built it had published a paper about it.