Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Warns Customers Away From RC4 and SHA-1

Posted by Soulskill on from the avoiding-collisions dept.

Trailrunner7 writes "The RC4 and SHA-1 algorithms have taken a lot of hits in recent years, with new attacks popping up on a regular basis. Many security experts and cryptographers have been recommending that vendors begin phasing the two out, and Microsoft on Tuesday said it is now recommending to developers that they deprecate RC4 and stop using the SHA-1 hash algorithm. RC4 is among the older stream cipher suites in use today, and there have been a number of practical attacks against it, including plaintext-recovery attacks. The improvements in computing power have made many of these attacks more feasible for attackers, and so Microsoft is telling developers to drop RC4 from their applications. The company also said that as of January 2016 it will no longer will validate any code signing or root certificate that uses SHA-1."

54 of 92 comments (clear)

  1. Pay no attention to the man behind the Back Door.. by icebike · · Score: 5, Insightful

    Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that
    some crypto code is weak?

    --
    Sig Battery depleted. Reverting to safe mode.
  2. Re:Pay no attention to the man behind the Back Doo by AHuxley · · Score: 1

    Its not just the codes used, its the US branded: OS, file systems, "bugs" and files sent.

    --
    Domestic spying is now "Benign Information Gathering"
  3. If SHA-1 is a problem, what does that make MD4? by fluke11 · · Score: 3, Insightful

    Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry. The authors of MD4, RSA, had recommended for a long time switching to MD5 and now recommends using MD6, Other members of the security community also recommend using a stronger hash function, combining a salt string with the password and doing multiple rounds of the hash function. Microsoft has failed to do any of these recommendations.

    MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.

    It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.

    1. Re:If SHA-1 is a problem, what does that make MD4? by Anonymous Coward · · Score: 2, Informative

      Funnier (or sadder) still, NTLM v2 is unsalted rc4.

    2. Re:If SHA-1 is a problem, what does that make MD4? by WaffleMonster · · Score: 3, Interesting

      Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry.

      Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.

      MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.

      Still waiting for WP8 wireless to even warn the user before completely failing to validate TLS certificates. Bad enough when a vendor makes a mistake when designing a protocol... When implementing something they KNOW to be totally insecure by *design* .. now that represents a whole new realm of incompetence.

      It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.

      This is only because it is in Microsoft's best interests their signatures not be hacked as it would among other things doom the trusted platform. They don't seem to have the same level of concern about our passwords being compromised.

      Worth noting even with known attacks SHA-1 is still plenty secure for signatures... For all we know SHA-1 may never see a serious exploit but SHA-2 could be broken tomorrow. (Devil you know vs the one you don't) SHA-1 at least has had some exposure to the real world for a number of years.. SHA-2 currently very little.

      I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed. Virtually impossible to quickly resign global trust hierarchy even less feasible to resign code to react to a serious breach.

    3. Re:If SHA-1 is a problem, what does that make MD4? by ruir · · Score: 1

      Some protocols maybe be weak, but for instance, you are not supposed to use MS-CHAPv2 on the clear, it is usually encrypted inside a PEAP or TTLS tunnel, which is the standard configuration, for instance for the worldwide academic confederation, EDUROAM.

    4. Re:If SHA-1 is a problem, what does that make MD4? by Anonymous Coward · · Score: 1

      This is likely the main motivation on the Microsoft move. Customers have stopped upgrading the OS from clients and servers as MS has changed both of them to the new metro-ui. But this move may backfire them, as if a customer is threatened and pissed, he can nowadays move to competitors with the same amount of employee re-training as to new MS OS's.

    5. Re:If SHA-1 is a problem, what does that make MD4? by swillden · · Score: 1

      Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good.

      Passwords have a variety of problems but being subject to brute force attacks needn't be one of them. Their security (or lack thereof) relies on exploiting the asymmetry of effort required to verify vs crack, and reasonable passwords have on the order of 30 bits of entropy. That does require that the password be fairly good, but not "unrealistically good". The key is to calibrate the computation required to verify the password so that searching is infeasible. For example, if it takes 1/10th of a CPU-second to verify the password, then it will take ~3 CPU years to search the password space. If that's not enough for your application, slow the password-verification algorithm down so it takes a second, or whatever other value is appropriate.

      There are several key derivation functions (e.g. PBDKF2, bcrypt, scrypt) which allow the run-time cost of the algorithm to be adjusted as needed.

      The biggest problem with passwords is password reuse. You can't realistically expect people to manage tens, much less hundreds, of reasonably good passwords. Honestly, two or three is about the limit. And all it takes is for one system to do a bad job with password hashing and storage, and then lots of accounts on lots of systems are compromised/

      I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed.

      Either multiple algorithms, or a structure that allows new algorithms to be swapped in quickly, or both. One thing working in our favor is that there is usually plenty of warning before someone finds a practical collision generation algorithm. And even MD5 still doesn't have any second pre-image attacks. Arguably, MD5 is just fine for signatures even today, as long as the rest of the protocol is designed to limit the value of random collision pairs.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  4. Re:Pay no attention to the man behind the Back Doo by bob_super · · Score: 1

    Because the NSA doesn't like when someone else can get your files.
    It slows them down.

  5. *sigh* ok then... by Narcocide · · Score: 1

    ... what do we replace all our database password hash columns with now?

    1. Re:*sigh* ok then... by DavidD_CA · · Score: 2

      Asterisks.

      --
      -David
    2. Re:*sigh* ok then... by Anonymous Coward · · Score: 1

      Well, one possible solution would be to calculate a "double hash" where the first hashing is done with the old algorithm, and the hash produced by that is then hashed with the new algorithm. It should provide the same security as only using the new algorithm, but allows you to convert all the hashes from the old algorithm which you already have to the corresponding new hashes without the need to have the passwords.

      So for example if you used MD5 hashes before, and want the security of SHA-256, you use sha256(md5(password)) as hash. Since you already have md5(password) for each password on your system, you can easily replace it with the sha256 of that value.

      Note that this is specifically for passwords; for use in digital signatures the double hash would of course not be more secure than the weaker of the two algorithms.

    3. Re:*sigh* ok then... by Anonymous Coward · · Score: 1

      Curious: why doesn't the higher strength transfer to signatures as well?

    4. Re:*sigh* ok then... by Anonymous Coward · · Score: 1

      Because with digital signatures the attack is to generate a second text which causes the same hash value. Of course given the plain text, you certainly can generate its weak hash (so the fact that the weak hash is strong-hashed afterwards doesn't prevent you from getting the weak hash value), and if you manage to create a second, malicious text which creates the same weak hash value, then of course re-hashing that value with a strong hash doesn't help: Hashing the same value gives the same result.

      The situation is different for the passwords because you obviously don't have the original text for the hash (that is, the password; if you already had that, you'd not be interested in the hash anyway). Therefore you cannot get at the hash value of the weak hash, because all you have is the weak hash's strong hash, and that one you cannot reverse.

      Basically, to break the double-hashed password, you need to break both hash functions, therefore the combined hash is as secure as the stronger one. However to break the double-hashed signature, you need to break only one hash, therefore the security is the one of the weaker hash.

      Of course with the signature you could, instead of chaining the two hashes, calculate both hashes in parallel. To break that you'd again have to break both hash functions in order to break the signature (because if your replacement text only matches one of the hashes, the manipulation would still be detected using the other hash). Of course that would not be a good idea for the passwords, because then you'd be able to get a much shorter candidate list from breaking the weaker hash, which you'd then be able to test against the stronger hash to find the correct choice. Indeed, in case you've used the same password elsewhere, it would even be less secure than only the weak hash, because with the weak hash alone there would be no way to determine which of the strings leading to the same hash is the correct one.

  6. Re:Pay no attention to the man behind the Back Doo by LordLucless · · Score: 1

    Because although they gave it the NSA, they still don't want the Chinese government to compromise it?

    --
    Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
  7. Re:Pay no attention to the man behind the Back Doo by LongearedBat · · Score: 3, Insightful

    Because... the NSA pays MS for backdoors, whereas the Russians don't?

    Because... the NSA tries to stay under the radar, whereas other malware often doesn't? (ex. adware, bot-nets. Thus damaging the MS "experience".)

    Because... the NSA wants to know your secrets, whereas scammers want to use your secrets? (ex. Credit card payments. Further damaging the MS "experience".)

    Just a few thoughts.

  8. Re:The time has come the walrus said... by cheater512 · · Score: 3, Informative

    MD5 is broken, SHA1 has been weakened slightly but it isn't broken.

    The term broken is only used when it is trivial to crack and/or forge.

  9. Re:f^rost( pist by philip.paradis · · Score: 2

    There's trolling, and then there's trolling on drugs that only got invented last week. Damn dude, whatever that new stuff is, it's no good for you.

    --
    Write failed: Broken pipe
  10. Re:The time has come the walrus said... by 93+Escort+Wagon · · Score: 3, Funny

    No more RC4? No more SHA1? Next they'll be telling me to patch against WMF exploits.

    Thank God we can still depend on ActiveX!

    --
    #DeleteChrome
  11. Re:The time has come the walrus said... by WaffleMonster · · Score: 2

    MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.

    Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.

  12. Why the long window? by thatpythonguy · · Score: 2

    Plenty of time between now and January 2016 when MS will reject the use of SHA1. I understand that large corporations move slowly, but we have known about SHA1 shortcomings for a while now. I would like to read more about what products are affected, possible attacks in product contexts, and reasons for the long window until retirement! Even Windows 7 mainstream support will end in 2015!

  13. Re:Pay no attention to the man behind the Back Doo by thisisauniqueid · · Score: 1

    Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that some crypto code is weak?

    Because they now have a better back door that needs to become the default.

  14. Re:Pay no attention to the man behind the Back Doo by aaaaaaargh! · · Score: 1

    Why? Because the attacks on RC4 are becoming feasible for ordinary well-organized criminals, and there might be other agencies aside form the NSA who might try brute-forcing SHA1.

    The NSA is mainly a danger for business outside the US - and perhaps for Megaupload-like companies within the US for which some state prosecutor could imagine and construct some criminal copyright infringement case, although it seems that the NSA doesn't habitually help out the FBI.

  15. Re:The time has come the walrus said... by aaaaaaargh! · · Score: 1

    That's not the definition of "broken" that cryptographers use.

  16. SHA1? insecure? by Luke_22 · · Score: 3, Interesting

    I can understand RC4.

    I can understand MD5.

    But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...
    maybe a less if you have you own supercomputer, but even at $1M it sound a lot...

    So why warn away from SHA1 NOW? what are we going to use? md5? md4? remember that while keccak was chosen as the SHA3, they still have to release the complete details on how it must be implemented -- number of rounds and such -- so SHA3 *NOW* is not an option.

    I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.

    --
    "I was gratified to be able to answer promptly, and I did. I said I didn't know." -- Mark Twain
    1. Re:SHA1? insecure? by Shimbo · · Score: 4, Insightful

      So why warn away from SHA1 NOW?

      If developers are using it today, then you will be next year, and the year after, when attack are more feasible.

      what are we going to use?

      I'm not a cryptography expert but if SHA-1 is too weak, and SHA-3 not quite there yet, why not SHA-2?

    2. Re:SHA1? insecure? by Anonymous Coward · · Score: 4, Informative

      Specifically the 2nd SHA family are usually called SHA-224, SHA-256, SHA-384, and SHA-512

    3. Re:SHA1? insecure? by bill_mcgonigle · · Score: 1

      remember that while keccak was chosen as the SHA3

      and there's still a fight brewing over keccak rounds - NIST wants the rounds reduced to improve performance, at the same time we know that NSA has been weakening public crypto to hurt security. This may not be the case with keccak but the implications are strong enough and stock keccak good enough, that keccak, as submitted, should become SHA-3, not the reduced round version.

      If that doesn't happen, we may just ignore NIST and do a community standard based on published keccak. NIST should take heed to not become irrelevant.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    4. Re:SHA1? insecure? by swillden · · Score: 1

      I can understand RC4.

      I can understand MD5.

      But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud... maybe a less if you have you own supercomputer, but even at $1M it sound a lot...

      So why warn away from SHA1 NOW? what are we going to use? md5? md4?

      Because SHA1 has known weaknesses, even if they're not practically exploitable, and because attacks always get better. Would it shock you to hear tomorrow about a new attack on SHA1 that allows collisions to be generated for a few hundred dollars of computation? It wouldn't shock me. I don't expect it, but it would not be surprising.

      The alternative to SHA1 right now is SHA2. Or if you want you can use Keccak as published, but you may have to change it when the final standard is released. Depending on the context that may be reasonable.

      Microsoft is just repeating here what the security community has been saying for a few years now: SHA1 is okay, but new systems should be designed with SHA2, and old systems should be prepared to move if SHA1's weaknesses get much worse. As soon as SHA3 is standardized (or the community decides to pick an alternative as a standard, as bill_mcgonigle suggests), then new systems should use that.

      I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.

      Well, yes, there is that.

      I should also mention that RC4 is in much the same boat as SHA1. As long as you discard enough of the initial keystream bytes, it's fine for use today and for the foreseeable future. But the cracks in its shell mean that new systems should use something better. AES is the obvious, and perfectly adequate, solution. In counter mode if you need a stream cipher.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:SHA1? insecure? by pla · · Score: 1

      But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...

      Let's say Merck has a new drug in phase 3 clinical trials, it seems to cure cancer and the common cold. They plan to publish the results of the trials tomorrow, and everyone expects great success

      If you can crack RC4, you can MitM the private session between Lead Researcher Fred and the board. Whoah, this miracle drug works as advertised, except it causes permanent impotence.

      Time to short Merck, and go all-in on Pfizer, and a few million up front amounts to chump-change compared to what you'll make tomorrow when the news breaks.

    6. Re:SHA1? insecure? by pla · · Score: 1

      And even after preview, I still said RC4. Duh. SHA1. :I

  17. Re:Pay no attention to the man behind the Back Doo by El_Muerte_TDS · · Score: 1

    Why does the NSA want to know my secrets if they are not going to use it?

  18. Re:The time has come the walrus said... by Joce640k · · Score: 1

    MD5 is broken, SHA1 has been weakened slightly but it isn't broken.

    Same for RC4. The cypher is still OK, you just have to initialize it better (his has been known about for decades, the fact that Microsoft isn't doing it is the real news).

    --
    No sig today...
  19. Re:The time has come the walrus said... by fatphil · · Score: 4, Informative

    Just plain wrong.

    In the field of cryptography, the term "broken" is used whenever the work factor to crack is less than that of a brute force attack. Stevens' 2^61 collision attack against SHA1 means that SHA1 is broken.

    --
    Also FatPhil on SoylentNews, id 863
  20. Re:Pay no attention to the man behind the Back Doo by bill_mcgonigle · · Score: 1

    We have a real problem where the PCI scanning vendors are so freaked out about BEAST attacks (where client hardening is the correct solution) that the only cipher they'll accept (server side) that's FIPS compliant and BEAST resistant is RC4.

    What they should be doing instead is scoring people down for not doing ephemeral key exchange, scoring people down for not using TLS 1.2 and stop freaking out about CBC on the server side when getting rid of it is not even a thorough solution (fear of CBC is overblown, especially when compared to post-Snowden risks).

    If you look at your ciphers, even if you're negotiating ephemeral ECC with Google, you're then using RC4 as your stream cipher. RC4 isn't _so_ horrible that this is a major risk, but it's a theoretical one and it might fall eventually. Ephemeral key exchange is there to prevent against future attacks on captured streams, so RC4 may not be the best pairing for that.

    So, perhaps Microsoft is doing a good thing here and putting its weight behind some pressure to move past RC4.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  21. Re: The time has come the walrus said... by cryptizard · · Score: 1

    If that was true then pretty much every widely-used crypto system (AES, RSA, El Gamal, etc) would be "broken".

  22. Re:Pay no attention to the man behind the Back Doo by SuricouRaven · · Score: 1

    They don't admit to helping the FBI. Look up 'parallel construction.'

  23. Re:The time has come the walrus said... by Anonymous Coward · · Score: 1

    you just have to initialize it better

    Specifically, you "just" need to discard the first n bits of the keystream, and n seems to get larger every year. Do excuse me if that doesn't inspire confidence.

    Look, if you absolutely need to support some legacy application that only speaks RC4, that's one thing, but there's no reason beyond that to choose it over AES-256-GCM these days.

  24. SHA-2 by DrYak · · Score: 1

    SHA-2, more specifically its SHA256 ^2 variant, is not only used to secure messages in HMAC, but also in bitcoin for validating blocks (adding pages into the common distributed ledger), and thus also in bitcoin mining.

    Given the current massive craze in bitcoin, there's been massive development around SAH256.
    If SHA256 was cracked, somebody would be laughing on the way to the bank, after having mined most of the coin.
    That didn't happen (current bitcoin production is still spread among the most popular mining pools, there's no single individual significantly faster than everybody else)
    that's a good sign that SHA-2 won't be cracked in the near future despite how much resources the NSA, FSB and Co put at it.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  25. What about Git? by markkezner · · Score: 2

    Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?

    --
    Dangerous, sexy, turing complete: Femme Bots
    1. Re:What about Git? by tobiasly · · Score: 2

      Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?

      SHA1 as used in Git proves that a particular commit has the contents and the ancestors that the person with the repo says it does. It prevents two different people from saying, "this is what the source looked like at this point in time". So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)

      That said, replacing it with something else would essentially involve rebasing the entire repo, which would certainly be inconvenient but not insurmountable. They could probably even have a backwards-compatibility mode where it recognizes both SHA1 and some other algorithm and clients could gradually switch to the next one.

    2. Re:What about Git? by benjymouse · · Score: 2

      So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)

      You fall into the trap of trying to find reasons for how it is *not* a problem. But *every* single time a weakness is found it opens up to multiple different attacks. Just because you cannot imagine a possible attack using a vulnerability does not mean that such attack vectors do not exist.

      Case in point: During the total pwnage (rootkit installed and active for the better part of a month - possibly longer) of kernel.org and multiple other Linux Foundation sites back in 2010 (we still have not seen a post mortem on that, despite promises of openness), the SHA1 digests were quoted as the reason we should not worry of compromise. A weakness where an attacker could create something else with the same digest opens up the possibility for injecting malicious code into the repo.

      Assuming that SHA1 weaknesses do not affect something like Git which relies on digests in almost every operation strikes me as naive. Of course Git will have
      to move off SHA1 just like everyone else. No rush just now - but it would be stupid not to start planning for it.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    3. Re:What about Git? by tangent3 · · Score: 1

      I call BS on that "*every*"

    4. Re:What about Git? by KiloByte · · Score: 1

      Attacks against SHA1 are still purely theoretical: it would take several million dollars of hardware+electricity to produce a single collision. To subvert a git repository, you need to be able to have a commit of your own legitimately accepted, with no modifications (like Signed-off-by: by whoever took your patch, or modifications to the file you edit), and then, you need to pwn the server holding the public repository to replace that commit with the nefarious half of your collision.

      That's a MASSIVE undertaking. On the other hand, you can learn the ways of Underhanded C and try to sneak the code in some driver... Thus, I trust the kernel git repo.

      Even MD5 is perfectly secure against preimage attacks, barring any sudden breakthrough, for foreseable future.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    5. Re:What about Git? by lhunath · · Score: 1

      There's a difference between using SHA1 for verifying integrity and using SHA1 for cryptographic purposes.

      I don't think it's GIT's intent to cryptographically prove that nobody has injected a modified commit in your history while going through extreme effort to mask that single-commit modification.

      --
      ``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
  26. Re:Pay no attention to the man behind the Back Doo by devman · · Score: 1

    RC4 is NOT FIPS compliant. Never has been. RSA has never published a spec for RC4. The code just showed up one day on a mailing list from an anonymous source.

  27. Re: The time has come the walrus said... by F.Ultra · · Score: 1

    There is no faster than brute force attack for AES, unless you modify the algorithm to have less rounds but then it's no longer AES.

  28. Re:The time has come the walrus said... by swillden · · Score: 1

    MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.

    Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.

    This is true of anything. All statements about security are relevant only within a given set of threat models.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  29. Re:The time has come the walrus said... by LurkerXXX · · Score: 1

    Or that we shouldn't use WEP for our wireless encryption.

  30. Re: The time has come the walrus said... by Bengie · · Score: 1

    AES is considered broken, but safe to keep using.

  31. Re: The time has come the walrus said... by F.Ultra · · Score: 1

    Sorry, forgot about that one. While it's true that AES is broken, the attack in question is currently quite impractical since it requires a 2^88 data space

  32. Re:Pay no attention to the man behind the Back Doo by icebike · · Score: 1

    They no longer deny helping the FBI, DEA, ATF, and county sheriffs.

    --
    Sig Battery depleted. Reverting to safe mode.
  33. Re:Pay no attention to the man behind the Back Doo by Guppy06 · · Score: 1

    Because Microsoft doesn't deliberately open back doors for free.

  34. Re:Pay no attention to the man behind the Back Doo by manu0601 · · Score: 1

    [for BEAST] client hardening is the correct solution

    Indeed. TLSv1.1 is not vulnerable, and most browsers that are still limited to TLSv1.0 are able to use the 1/n-1 split workaround to BEAST (notable exception is Safari on MacOS up to X.8). The right approach would be to detect TLSv1.0 clients that do not use 1/n-1 split and deny them access before they exchange anything sensible.