Tag Info

Hot answers tagged

50

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 ...


30

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 ...


18

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

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 ...


9

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 ...


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 ...


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

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 ...


7

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) ...


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 ...


6

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 ...


6

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 ...


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 ...


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

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

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, ...


3

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 ...


3

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 ...


3

There are known biases in RC4 output, especially in the first bytes of the stream. In the "Gmail scenario", the client (Web browser) regularly connects to the server to poll for new incoming messages. Each connection implies encrypting the request data with a fresh RC4 stream; and all the requests will contain the same secret value at the same place in the ...


3

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 ...


3

BEAST vulnerability has been worked out client-side, so it's no longer an issue with modern browsers. RC4 is a weaker cipher than others since it's been shown to have a slight bias, but if used carefully and appropriately, there are no successful attacks against it. You can't get any safer than safe; if your encryption can't be broken, then it doesn't ...


3

If I understand this issue tracking thread, support for disabling some cipher suites in SSL/TLS has been at least partially implemented, but there is no corresponding user interface. It seems to be feasible through command-line arguments (I have not tried). Also, the exact method may change depending on the operating system, since Chrome tends to reuse the ...


3

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 ...


3

The overall cipher suite determines compatibility, not the presence or absence of one cipher. You'll need to test different configurations to find out. If you're already doing SSL Lab's server test, then that's your best resource for determining the impact of the change. When you say you're setting up some new certificates and load balancers that ...


3

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, ...


2

You (or they, the ones who propose the change) do not give a reason for switching to RC4, do you? RC4 is a stream cipher, which is vulnerable in some particular cases: RC4 has weaknesses that argue against its use in new systems. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys ...


2

There is only one way to make a site as secure as possible: take it completely offline. Everything else is a compromise: what browsers and clients do you want to allow to your site. Even GitHub is still not as secure as possible. They allow TLS 1.0 and TLS 1.1 while there is a newer TLS 1.2. Disabling TLS 1.0 and TLS 1.1 would however deny users with ...


2

I think you're asking the wrong question. To me, "How much will my users be inconvenienced?", is far less important than "How sensitive is the information on this server?", or "How much would I care if it got hacked?". Hardening a system usually leads to some inconvenience. The level of inconvenience you're willing to endure (and inflict on your users) ...



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