Hot answers tagged

17

I read that this should be avoided because of CRIME/BREACH attack, is this correct? It depends. The CRIME attack is already mitigated in current browsers in that they don't use TLS compression and have special handling of contexts in HTTP/2.0. BREACH is only relevant in the context of HTTP level compression if the following two conditions both apply at the ...


11

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


5

BEAST is a vulnerability on the client, not on the server. A server is not, and never has been, "vulnerable to BEAST". There is some confusion about tools that "test SSL servers", that may report a "BEAST vulnerability" if the server fails to fix a vulnerable clients -- namely, if the client is vulnerable, and specifies in its ClientHello that it prefers to ...


4

Paypal supports TLS 1.0, 1.1, and 1.2. If your browser advertises that it would like to use TLS 1.2, then that is indeed the TLS version that Paypal will choose to connect with. If, however, your browser suggests to Paypal's servers that the highest TLS version it supports is 1.0, then Paypal will happily connect using that protocol version as well. I ...


4

CRIME and BEAST are chosen-ciphertext attacks. The attacker needs to send tens of thousands of requests in the connection of the user. This works well for a web browser. Theoretically, it is possible for IMAP by sending mails to the victim, however the target plaintext (IMAP password) needs to be in the same packet as the chosen ciphertext. This is usually ...


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


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

The Amazon Cloudfront documentation says that they only support the AES128-SHA1 and RC4-MD5 ciphers. Try enabling AES128-SHA1 - while not as good as AES256, it's better than RC4. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html


2

DES-CBC3-SHA is affected by BEAST, but it might still be a better choice than RC4-MD5, because BEAST is considered mostly fixed on the client side while it gets easier every day to crack RC4. See also https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat. The best is of course to move to TLS1.1 or higher, but not all clients can ...


2

I realize the post is from 2013, but I happened upon this post when researching a patch for the latest openSSL vulnerability announced 3 May 2016 (Info - https://www.openssl.org/news/secadv/20160503.txt). The recommended patch is TLS1.2+AES-GCM cipher suite. The latest browser on the latest OS should have support for AES-GCM at this point. If you'd still ...


2

SSL Labs no longer penalizes this In a blog post dated 2013-09-10 SSL Labs project lead Ivan Ristic said: Yesterday I changed the SSL Labs rating criteria to stop penalizing sites that do not implement server-side mitigations for the BEAST attack. That means that we now consider this attack sufficiently mitigated client-side, [...] Details/Timeline 2011-...


2

gzipping SSL-encrypted data eliminates the advantages of SSL to some extent. Yes, gzipping ALL content might opens your website up to the BREACH-vulnerability. But you can still add some resources for gzipping. For example public images could be gzipped or public documents in general. However you should carefully consider if you want to "sabotate" your own ...


2

Because the JavaScript will be running from a different origin - the Same Origin Policy will prevent example.org from grabbing the cookies from bank.example.com. Example.org does not even have to have been compromised. A Man-In-The-Middle attacker (let's call her Mallory) could have intercepted a connection from the victim (let's call him Bob) to the benign ...


1

Yes. Several years ago, Qualys covered mitigation techniques, and notably several methods that you might think would work (like "enabling the empty fragment technique server-side") are ineffective because the attack is client-side. However, TLS 1.1+ is much more common these days. Additionally, most clients added mitigation years ago (even Apple, who was ...


1

So, if the server's preferred cipher is RC4 and client provides a CBC cipher (Only one) will it select CBC or rejects the request? If the server supports the CBC cipher that the client provides, the CBC cipher will be used. Otherwise, the connection will fail. If it chooses CBC then ir-respective of the cipher ordering (nmap's output) then it is ...


1

In addition to Neil's answer if a cookie is marked as HttpOnly it will be inaccessible via javascript and therefore you cannot pass it on to the evil server.


1

The JavaScript is not injected on bank.com, it's run on compromised.com that you visit or are tricked into visiting. The JavaScript on compromised.com makes requests to bank.com on your behalf. The attacker must also be able to view your network traffic, such as at a Wi-Fi hotspot.


1

Yes Pi is appended to the body; (re)read the paragraph labelled Blockwise Privilege at the top of the page. Remember HTTP and thus HTTPS is a stream protocol; if you make a request to upload say 100 gigabytes uncompressed video you probably won't do it in a single step. To restate a little more finely: Step 1 Mallory's code causes something in Alice's ...


1

A few things: You might be interested in this link: - seems PCI compliance scanners get confused about these issues sometimes. Technically Beast applies to Browsers, but CBC is not what you want for your ciphers anyway. However, CBC mode is default for FIPS complient RDP anyway :( Yes, you definitely want TLS. Without some more specific information ...


1

disabling everything "RC4" with IIS Crypto allowed to pass PCI compliance test on Server 2008 / IIS 7.0


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

For what it's worth, John Hardin's answer was correct when written, but there has been some good news. In August 2014, AWS announced support for new AES cipher suites, including the nice ECDHE ones used in the question. That configuration should now work perfectly with CloudFront. The cipher suite documentation linked above includes the new list.


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