Tag Info

Hot answers tagged

20

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


15

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


7

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


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


5

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

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


4

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


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

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


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

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


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


2

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


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


1

A lot of the people recommending RC4 to prevent BEAST have recanted because of the attacks on it; the correct and forward-looking solution is updating your software to the TLS 1.1 spec. Strategically, your options depend on your abilities. If you are allowed to dictate the user agents connecting to your service, or willing to accept that your user agent ...


1

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


1

Unless you need to be FIPS compliant I wouldn't disable rc4 md5. You can simply prefer it as a last resort. You can configure your webservers in such a way that they will only resort to rc4md5 if the client does not support any other ciphers you offer. This way you needn't worry about supporting legacy clients. To my knowledge older phones sometimes only ...



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