Will there be any security concern if there is no mode of operation specified in the ciphersuite name?
For instance, there is no mode of operation in TLS_ECDHE_RSA_WITH_AES_256_SHA.
2
$\begingroup$
$\endgroup$
2
$\begingroup$
$\endgroup$
It is a security issue in the sense that it likely shows that somebody doesn't know what he is doing.
TLS_ECDHE_RSA_WITH_AES_256_SHA is not an officially supported cipher suite name (internet search results too quickly degenerate for that). It probably is present in misconfigured OpenSSL servers. I presume it will default to CBC for the actual security. It is extremely unlikely to use ECB mode as that has never been a supported mode, and it would need to somehow ignore the IV if it was to be used.
Just make it the only possible cipher suite on a test server, then connect to it with a client. You'll probably find out that it is actually the CBC ciphersuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with ID {0xC0, 0x14}. The ID is what is actually communicated during the handshake; the name of the ciphersuite is just what you find in the configuration parameters of the server.
It is not possible to just make up a name for a ciphersuite: it needs to resolve to an ID to be communicated within the handshake. In developers language: the ciphersuite name is an enumeration. Unfortunately OpenSSL has the nasty habit of using their own names and patterns for allowing / disallowing enumeration values.
I'd prefer a TLS 1.2 specific GCM ciphersuite and SHA-256 or SHA-512 over that particular ciphersuite.
answered Oct 24 '18 at 12:05
-
$\begingroup$ It could also not be recognized at all, and simply skipped by the server, of course. That's very secure, but not very useful for clients that want to use the CBC ciphersuite. I thank David in advance for his comments :P $\endgroup$ – Maarten Bodewes♦ Oct 24 '18 at 12:21
0
$\begingroup$
$\endgroup$
You send a ClientHello message with the list of modes you support everytime you connect to a server. Server replies with a ServerHello containing which mode of operation will be used in the whole protocol. This an important step in the TLS Handhsake.
Then you won't have problems if you don't support TLS_ECDHE_RSA_WITH_AES_256_SHA, the server will just select another mode that you support.
-
$\begingroup$ Thanks everyone for providing useful information. I’m actually looking for suitable cipher suite to use for TLS 1.0, without compromising much of the security posture. This is to support legacy system that only support TLS 1.0. $\endgroup$ – Mark Yam Oct 24 '18 at 16:38
-
$\begingroup$ Your legacy system will be vulnerable against multiple attacks that have been found in the mean time. So you are fooling yourself if you think you'll add (much) security. Use a TLS tunnel or even VPN instead. $\endgroup$ – Maarten Bodewes♦ Oct 24 '18 at 17:52
-
$\begingroup$ Completely agree with you, Maarten. But the fact is we have a small percentage of users who are less privilege to own a system that supports TLS 1.2. Hence we need to enable TLS 1.0 to facilitate their needs. My plan is to set a timeline to fully implement TLS 1.2 only while looking for alternative solution for the less privilege users. $\endgroup$ – Mark Yam Oct 25 '18 at 2:34
-
$\begingroup$ In the end it is their problem I suppose, as long as you keep honest and not promise them any security over the amount you're actually offering. They probably should stay away from WiFi hotspots... $\endgroup$ – Maarten Bodewes♦ Oct 25 '18 at 15:08
0
$\begingroup$
$\endgroup$
There should be some mode of operation, at least when due to messages which are longer than the block size. The simple mode of operation is ECB mode of operation which is always considered insecure since same messages always map to the same ciphertext under the same key.
See the famous penguin in the Wikipedia to deduce that ECB in dangerous.
A formal reason, ECB is not CPA secure, whereas CBC and CTR, but be careful with GCM
Stick to standards and search for the following mode of operations CBC, CCM and GCM in TLS
0
$\begingroup$
$\endgroup$
There's no mode of operation in the ciphersuite's textual name, but that doesn't mean the ciphersuite itself didn't use any. I believe the default is CBC for the TLSv1.0-era ciphersuites.
(...I mean, if the ciphersuite really didn't use any sensible AES mode of operation, wouldn't it have been long purged just like single-DES ciphersuites or e.g. everything SSLv2/v3-related have been?)
