2

Some attacks (e.g. BEAST, CRIME) are only effective against HTTPS.
Are there any cipher suites which are only "good" when in use over HTTPS?

Is there any "good" HTTPS cipher suites (i.e. ChaCha20-Poly1305, AES-GCM, ..) which is not "good" for other protocols like IMAP, SMTP, SSH, etc.?

4
  • Each protocol will generally have their own set of cipher suites specified. They're not interchangeable between protocols.
    – RoraΖ
    May 19, 2015 at 11:18
  • Sure? AES-GCM is available for IMAP, SMTP, HTTPS, SSH, .. May 19, 2015 at 11:47
  • AES-GCM is an symmetric algorithm (AES) and cipher mode(GCM). A cipher suite is a combination of that, public key, and integrity algorithms. For example: TLS_RSA_WITH_AES_128_GCM_SHA256. This is specific to TLS
    – RoraΖ
    May 19, 2015 at 11:59
  • I think you're asking if any particular cipher algorithm and cipher mode is better depending on the protocol. You might want to edit your question.
    – RoraΖ
    May 19, 2015 at 12:00

2 Answers 2

1

Some attacks (e.g. BEAST, CRIME) are only effective against HTTPS.

Not really. The underlying problems of ciphers or of use of compression are not specific to HTTPS, only some features of HTTP made it possible to exploit these problems because you were able to add chosen plain text to the encryption etc. You might find exploits for other protocols which are based on the same ideas.

Is there any "good" HTTPS cipher suites (i.e. ChaCha20-Poly1305, AES-GCM, ..) which is not "good" for other protocols like IMAP, SMTP, SSH, etc.?

Based on what I wrote above the question would not be if their are any good ciphers for HTTPS which are bad for other protocols. Instead you might ask if their are any ciphers with known problems, where these problems can not be exploited by HTTPS but can be exploited with other protocols. Since typical attack methods like chosen plain text are probably easier to do with HTTPS than with other protocols I would say, that ciphers safe for HTTPS are probably safe for other protocols too, at least for the common protocols you've mentioned.

But you might also ask if you could construct a protocol in a way, that even the protection offered by good ciphers can be evaded. I'm pretty sure that you can do it and there might be protocols or applications out there which do this. But this is not the problem of the cipher or of TLS, but of the usage. Check out Timing Analysis of Keystrokes and Timing Attacks on SSH or I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis for examples what kind of analysis could be done even if the ciphers itself are fine. And you could definitely design protocols in a way which accidentally make these kind of side-channel analysis even easier (but also which make it harder).

1

It has been argued that an emailing client, using the POP3 protocol over SSL, will reconnect on a regular basis and send the authentication password at a predictable place within the flow, close to the beginning. Thus, if a RC4-based cipher suite is used, a passive attacker may simply observe and wait, so that the known small biases of RC4 gradually reveal the password. In that sense, POP3-over-SSL (with basic password-based authentication) would be especially vulnerable to the choice of a RC4-based cipher suite, more so than HTTPS due to the specificities of the protocol (with HTTPS, even in situations where clients reconnect repeatedly to a given server, the "interesting secrets" such as HTTP cookies are further down the HTTP header, where RC4 biases are not so large).

As @Steffen explains, known issues with some cipher suites and protocol versions in SSL/TLS are not specific to HTTPS; but HTTPS means Web, and Web means Web browser, and Web browser means Javascript, and Javascript means "potentially hostile code on the client side", opening the very rich area of adaptive chosen plaintext attacks. On protocols where clients do not routinely execute code provided by the attacker himself, vulnerability exploitation is harder.

(Note that SSH is not based on SSL, and the concept of "cipher suite" does not immediately apply to it.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .