Why does SSL Labs now consider CBC suites weak?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.
The suites in question are:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.
tls cbc
edited May 13 at 12:14
TRiG
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
add a comment |
Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.
The suites in question are:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.
tls cbc
edited May 13 at 12:14
TRiG
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12
add a comment |
Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.
The suites in question are:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.
tls cbc
edited May 13 at 12:14
TRiG
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.
The suites in question are:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.
tls cbc
tls cbc
edited May 13 at 12:14
TRiG
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
edited May 13 at 12:14
TRiG
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
edited May 13 at 12:14
TRiG
466413
edited May 13 at 12:14
TRiG
466413
edited May 13 at 12:14
TRiG
466413
466413
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
asked May 13 at 6:46
Martin HorskyMartin Horsky
36828
36828
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12
add a comment |
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12
add a comment |
2 Answers
2
active
oldest
votes
While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.
answered May 13 at 6:52
forestforest
43.9k18145161
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
add a comment |
Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:
We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.
answered May 13 at 8:53
Chloride CullChloride Cull
40134
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f210072%2fwhy-does-ssl-labs-now-consider-cbc-suites-weak%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.
answered May 13 at 6:52
forestforest
43.9k18145161
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
add a comment |
While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.
answered May 13 at 6:52
forestforest
43.9k18145161
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
add a comment |
While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.
answered May 13 at 6:52
forestforest
43.9k18145161
While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.
answered May 13 at 6:52
forestforest
43.9k18145161
edited May 13 at 22:53
answered May 13 at 6:52
forestforest
43.9k18145161
answered May 13 at 6:52
forestforest
43.9k18145161
answered May 13 at 6:52
forestforest
43.9k18145161
43.9k18145161
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
add a comment |
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
– Martin Horsky
May 13 at 10:46
8
8
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
– Gert-Jan
May 13 at 11:38
add a comment |
Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:
We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.
answered May 13 at 8:53
Chloride CullChloride Cull
40134
add a comment |
Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:
We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.
answered May 13 at 8:53
Chloride CullChloride Cull
40134
add a comment |
Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:
We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.
answered May 13 at 8:53
Chloride CullChloride Cull
40134
Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:
We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.
answered May 13 at 8:53
Chloride CullChloride Cull
40134
answered May 13 at 8:53
Chloride CullChloride Cull
40134
answered May 13 at 8:53
Chloride CullChloride Cull
40134
answered May 13 at 8:53
Chloride CullChloride Cull
40134
40134
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f210072%2fwhy-does-ssl-labs-now-consider-cbc-suites-weak%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
– jww
May 13 at 17:14
@jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
– Lekensteyn
May 14 at 21:12