Tag Info

Hot answers tagged

21

The attack requires cooperation between an outer component (which can intercept traffic) and an inner component which runs on the attacked machine and is able to inject arbitrary data (chosen by the attacker) within the SSL tunnel, along with the piece of data which is to be decrypted. The general view among most people in the crypto and security communities ...


18

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

The main reason why there is little movement is that the "breaks" are not practical enough to show up on radar. BEAST does not work anymore. Firstly, it requires a way for client code in the browser (hostile Java or hostile Javascript) to emit cross-domain requests with a high level of control at the bit level; the two known ways to do that (a draft ...


17

In IIS 7 (and 7.5), there are two things to do: Navigate to: Start > 'gpedit.msc' > Computer Configuration > Admin Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order (in right pane, double click to open). There, copy and paste the following (entries are separated by a single comma, make sure there's no line wrapping): ...


14

I am not sure what you mean by not supported. Currently the following browsers support TLS 1.1 and 1.2: Chrome - v30 supports TLS 1.2. Previous to this only up to TLS 1.1 was supported Firefox - v27 enables TLS 1.1 and 1.2 by default Internet Explorer - v11 supports TLS 1.2 from Feb 2013 Opera - v17 has added support for TLS 1.2. Versions 10-12 supported ...


12

One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map ...


11

Theory of the BEAST Attack SSL uses various combinations of public and symmetric key algorithms. (OpenSSL's list) When the symmetric algorithm is a block algorithm (as opposed to stream), cipher block chaining is used -- the previous block is part of the input to the new block. The problems we're seeing right now are implementation-based, and they've been ...


10

GCM is recommended; it is even approved by NIST. However, AEAD ciphers are supported in TLS only since TLS 1.2; see section 6.2.3.3, which is new, when compared to TLS 1.1. The actual GCM-able cipher suites are defined in RFC 5288. Note that TLS 1.2 (and, for that matter, TLS 1.1 too) is immune to BEAST-like attacks when using CBC. Therefore you will have a ...


9

Background. To learn more about how to mitigate the BEAST attack, I recommend reading the following two blog posts: Rizzo/Duong BEAST Countermeasures and Mitigating the BEAST attack on TLS. You'll quickly learn that there are no really great solutions. What to scan for. Right now, the only known server-side mitigation is for the server to force use of RC4 ...


9

Edit (2012/09/23): Ask and ye shall receive. TestSSLServer is a simple command-line tool which I wrote this week-end; it obtains from a given SSL/TLS server the list of supported cipher suites, protocol versions and support of TLS-level Deflate. It then gives a summary of the encryption strength and the vulnerability to BEAST and CRIME attacks. It is written ...


9

I don't think anyone knows of any way to exploit BEAST, on any of those modern browsers, so as far as anyone knows, those browsers are probably pretty safe against BEAST-like attacks. On the other hand, the underlying weakness is still present, which leaves some room for concern about the possibility that someone might find a new way to exploit that ...


8

OpenSSL has a mitigation for BEAST which has been enabled by default since 0.9.6d, so as long as your OpenSSL version is this version or later and you haven't set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS there is no need to restrict ciphers or disable TLS 1.0.


7

I just posted an update to IIS Crypto which is a free tool that sets the schannel registry keys and puts RC4 at the top of the SSL cipher suite order with a single click. This mitigates the BEAST attack on Windows Server 2008 and 2012.


6

Until the security hole is closed both ends (web server and browser software) it will be hard to prevent. Unfortunately because the current exploit targets cookies you have minimal control over it client-side. The only exception is to change your encryption ciphers and block or reorder CBC ciphers to the least preferable so it has the least likelihood of ...


5

I have written a command-line tool called TestSSLServer which can be used for that job. The tool makes a lot of aborted handshakes with the server (it sends the ClientHello and receives the ServerHello; then it closes the connection). First, it establishes the list of cipher suites supported by the server, by sending a full list of many suites, then ...


5

this is based on some online searches alone, with no detailed anlaysis, but from what I gather, it's more of a client-side vulnerability than a server one. Of course the vulnerability is when the communication between client and server is attacked, but the fix should be primarily on the client. The primary reason, as I understand it, is because the client ...


5

Since the patch has been released some time ago, we can now have more information. The security bulletin is quite devoid of technical information, but some clues can be gathered from reading the KB article about known issues. The patch does, basically, two things: The patch activates TLS 1.1 support. This support was already included in Internet Explorer, ...


5

Move rc4-based cipher suites to the top of the list; the attack seems to be related to CBC, and rc4-sha is not vulnerable if that is the case. Update - we've released a white paper here detailing how to make the changes. Available here. To clarify, protocol version won't help you here due to practical considerations - servers cannot disable TLS1.0/SSL3 at ...


4

1) This is not exploited through XSS, but through a client visiting a malicious site. The targeted website does not need to exhibit any flaws at all. Details: http://vnhacker.blogspot.com/2011/09/beast.html 2) RC4 in WEP was vulnerable because of an implementation flaw. AES in TLS 1.0 / CBC mode... exactly the same kind of problem. They're still strong ...


4

Without knowing the internal workings on the patch I can only guess, but... Both IE and IIS support versions of TLS that are not vulnerable to BEAST, e.g. TLS 1.1 and 1.2, but these versions are not on by default. Also, it's dependent on the cipher suite used in the connection for 1.0. The patch could do a number of things like turn the versions on by ...


4

BEAST has been fixed on modern browsers. While people really should be moving to the newer TLS versions, there hasn't been a significant adoption of the newer protocols. There has been compatibility problems with servers that has not activated the newer protocols. See this link for more information. The article is almost a year old though, so there might ...


3

The cipher suite is (mostly) orthogonal to the certificate. The RC4-based cipher suites are: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Both require a certificate with a RSA key, and "suitable for encryption" (that is, a certificate which has not been marked as signature-only). There is high probability that your certificate is already fine for ...


3

How does one disable CBC 'mode' on IIS6? You disable all ciphers that have CBC in their name. http://support.microsoft.com/default.aspx?scid=kb;EN-US;245030 describes how; https://www.nartac.com/Products/IISCrypto/Default.aspx provides a tool to do it for you. Also, from that second website: Note - Windows Server 2003 does not support the ...


3

Previously, the attack was considered possible in principle but not a serious threat in practice. It was believed that the attack would require so much chosen plaintext that the attack was not a practical threat. In addition, in the web setting, there was no known way to get the victim's browser to encrypt the chosen plaintext with the necessary level of ...


3

You can't solve this without your browser vendor's assistance. Communicate with your browser vendor to indicate that you would like to see support for TLS 1.2. (There is probably a bug report already in their bug tracker; probably you can just vote for it, and monitor it, to see when a new version of the browser is available with support for TLS 1.2.) ...


3

The simplest way to mitigate BEAST is to do nothing at all. BEAST is a client attack. Servers can "protect" clients by enforcing the use of RC4-based cipher suites even if the client states that it prefers some CBC cipher suites. However, all recent Web browser versions include workarounds which make them immune to BEAST, namely the 1/n-1 split; and the ...


3

As of today (August 2013), known weaknesses of MD5 have no impact whatsoever on the security of SSL/TLS. Issues with MD5 may induce problems with X.509 certificates, but this is a CA business and is unrelated to your choice of cipher suites. In that respect, RC4 is actually weaker than MD5. RC4 induces measurable biases, which very rarely have any ...


3

It should be noted that BEAST requires some hostile code which runs on the victim's browser, code which is able to send arbitrary requests to the target Web site, with enough "control" on the sent bytes to pull off the CBC-related calculations. In particular, this cannot be "just text". The BEAST authors had to find some sort of channel which would evade the ...


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

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



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