Hot answers tagged

49

I think explaining the weakness in RC4 to a non-technical audience would be very similar to explaining the role of randomness in crypto to a similar audience. Let's say I want my army to attack at dawn, so I encrypt the message "attack at dawn," generate a ciphertext c_0, and send it to my army, who then attacks my enemy at dawn. Great. Next week, I want ...


34

First things first: don't panic. Don't do anything rash, and take time to think. The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte ...


26

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and ...


17

After several hours trying to figure out how to do that in Google Chrome I've found it! You must add the following command line parameters in the shortcut: --cipher-suite-blacklist=0x0005,0x0004 The tricky part is that Google has not translated cipher strings so you must input each cipher in hex based on RFC 2246: 0x0004 = TLS_RSA_WITH_RC4_128_MD5 ...


14

A payment processor who accepts RC4 is simply satisfying PCI requirements. PCI does not disallow RC4. It does, however, consider the presence of BEAST to be a failure. And if they're going to mitigate BEAST and still remain widely compatible, they need RC4 - "The only reliable way to defend against BEAST is to prioritise RC4 cipher suites". The ...


14

Of course you should worry. If the credit card payment processor is not able to fix well known and obvious security problems (A few days ago RC4 got explicitly prohibited for use with TLS by the IETF) which are even visible world-wide from outside, how will be the status of their internal security? Note, that it might be not that bad to offer RC4 for ...


12

Yes. The protocol itself is no longer secure, as cracking the initial MS-CHAPv2 authentication can be reduced to the difficulty of cracking a single DES 56-bit key, which with current computers can be brute-forced in a very short time. The attacker can do a MITM to capture the handshake (and any PPTP traffic after that), do an offline crack of the handshake ...


12

Basically what I ask is: Should we get SSL Certificates for our websites still? Yes, absolutely. TLS is simply a newer version of SSL, and they both use the same certificates. An aside on the names - SSL was a Netscape protocol. When it got mainstreamed as an RFC, they made some minor tweaks and renamed it TLS so that it wouldn't be confused with a "...


10

In a "DHE" cipher suite, the server generates on-the-fly a new Diffie-Hellman key pair, signs the public key with its RSA or DSA or ECDSA private key, and sends that to the client. The DH key is "ephemeral", meaning that the server never stores it on its disk; it keeps it in RAM for the duration of the SSL handshake, then forgets it altogether. Being never ...


10

BEAST is a client-side attack, so all you can do on the server side is to avoid letting unaware clients put themselves in a BEAST-vulnerable position. However, modern clients (Web browsers) are not vulnerable to BEAST anyway: Clients use record splitting (usually 1/n-1) as a countermeasure. BEAST requires the hostile in-browser code (in Java or Javascript) ...


8

As @D.W. points out, this would work -- to protect the cookie. The path itself comes before the headers, and may also be at risk, if it contains sensitive data at a predictable place (this is not a common case nowadays, but URL rewriting for session management used to be popular). A variant would look like this: GET / HTTP/1.1 X-Header-Padding1: <X ...


8

TL;DR You need to use the following parameter to block all RC4 ciphers (as of Chrome 31 in Ubuntu 12.04 with NSS 3.15) --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007 In Google Chrome on Ubuntu you have to edit the file /usr/share/applications/google-chrome.desktop and add the parameter to each line that starts with Exec=/usr/bin/google-chrome-...


8

As Matthew Green puts it, the attack "is just on the edge of feasibility". It conceptually applies to any protocol that uses RC4, although some are more vulnerable than others. The weakness of RC4 is a bias in the first bytes of output. From the key, RC4 generates a long stream of pseudorandom bytes, and encryption is just a byte-per-byte XOR of the data to ...


7

Google Chrome Version 28.0.1500.95 chrome.exe --cipher-suite-blacklist=0xc007,0xc011,0x0066,0xc00c,0xc002,0x0005,0x0004 0xc007 = ECDHE-ECDSA-RC4128-SHA 0xc011 = ECDHE-RSA-RC4128-SHA 0x0066 = DHE_DSS_WITH_RC4_128_SHA 0xc00c = ECDH_RSA_WITH_RC4_128_SHA 0xc002 = RSA-RC4128-SHA 0x0005 = RSA-RC4128-SHA 0x0004 = RSA-RC4128-MD5 Source list of cipher names ...


7

Couldn't someone just reverse-engineer the code and get the source? Yes. That's exactly what happened in 1994: From the Wikipedia entry: RC4 was initially a trade secret, but in September 1994 a description of it was anonymously posted to the Cypherpunks mailing list. It was soon posted on the sci.crypt newsgroup, and from there to many sites on ...


6

RC4 has known biases, which have been measured with great accuracy. Exploiting these biases into an actual attack requires observation of many (millions) of successive connections where some specific secret data (say, a given password) always appears at the same place. Such a scenario can be forced in lab conditions but barely applies to practical, real-life ...


5

This would be safe against all attacks that I know of. From a security perspective, it is not quite equivalent to dropping the first 256 or 512 bytes. With your proposal, the attacker has some known plaintext (e.g., from the GET line and the X-Padding-Header), whereas if you drop the first 256 bytes, the attacker doesn't get known plaintext in those ...


5

Disabling RC4 completely would be great in an ideal world, but unfortunately we don't live in an ideal world. If you do disable it, certain mobile and embedded devices may not be able to communicate with you. Keep in mind that IE on Windows XP can only use RC4 because the underlying cryptographic API (CAPI) on the system doesn't have AES. As for the risk, ...


5

A TLS cipher consists of a part defining the authentication of the certificate (i.e. ECDSA, RSA...), a part defining the key exchange (ECDHE, DHE...) and a part about the kind of symmetric encryption and the associated HMAC, i.e. RC4+SHA1, AES128+SHA256 etc. From these parts only the authentication part depends on the type of certificate and everything ...


5

You should always use an AEAD mode if you can, especially over the network. Crypto++ seems to support GCM, which is a good AEAD mode that has seen use in TLS 1.2. (There are others that are just as good, but TLS's "star power" lends GCM a lot of credibility.) Importantly, AEAD modes authenticate "additional data." This is unencrypted data not included with ...


4

The biggest reason I can think of as to why they might want to use RC4 is because of compatibility with Jira (and or this custom auth backend that we cannot vet.) AES128 support was introduced along with Server 2008 and Vista, and AES256 with 2008 R2 and Win7. However, the KDC will automatically negotiate down to (for instance) RC4 when talking to, say, a ...


4

Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve). Aside from the fact that two ciphers, AES and RC4, are different internally (CBC block cipher, and stream cipher respectively), the observable differences are that AES-256 ...


4

If you connect to this site with your Web browser, it will show you what protocol versions and cipher suites are supported by that browser. Notably, Firefox does not seem to support (yet) TLS 1.1 and 1.2, so this prevents it from using any cipher suite ending in "_SHA256" because these are for TLS-1.2 only. If your server is accessible from the Internet, ...


4

In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe ...


4

Banks are usually not known to work in an agile way and quickly follow the latest developments. Like with lots of other large companies there is lots of paper work involved if somebody tries to change something, which costs efforts, man power, time and thus money. I don't think that a system administrator just can decide to change the ciphers. Instead it ...


4

I guess the most concise answer to this question is: They are insured. Currently industry standards don't require PFS and therefore insurances pay even if the bank had no PFS. There was a similar question on 30c3, about why the banks are using Windows XP as their operating system. Those standards can also be a reason why banks can't implement new methods ...


4

What you call the "XOR attack" is based upon the secret stream being reused; i.e. there is some secret stream S, data D that gets encrypted by XORing it with S, and some other data D' that gets encrypted by XORing it with the same secret stream S. In that case, if the attacker knows D he learns D'. However, when RC4 is used in SSL, the key is brand new for ...


4

RC4 is not considered as secure anymore, since there are several security vulnerabilities found in it. More about RC4 on Wikipedia ... Using the same password for all messages is also insecure, since if the password was discovered, all messages are compromised. Using pattern like 100, 101, 102 will not add much security to it, since attacker can guess what ...


4

From what I can understand, browser releases in 2016 will no longer support RC4 only connections, right? Yes. Chrome, Firefox, MS-Edge, MS-IE plan to deprecate who will be affected/what browsers will be affected? About 1000 servers in the Alexa top 500,000 are currently marked RC4 Only. You won't be able to access these over HTTPS with any modern ...


4

TLDR: in limited cases yes, but don't First, key-exchange and authentication aren't really independent in SSL/TLS. Although there are sometimes a few choices available, many combinations you could reasonably choose do not exist as ciphersuites. (Unlike for example SSH, where the pieces are negotiated separately and you can get any combination as long as ...



Only top voted, non community-wiki answers of a minimum length are eligible