Mixing
Could this list of ciphersuites be improved on?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
During my self-teaching about trying to find mobile application vulnerabilities, I found a list of cipher suites that are/were considered insecure:
md5 sha1 sha-1 md4 rc4 des tripledes 3des
If I grepped for these terms in some decompiled Java code and got hits, would it be safe to say, there is a problem?
java ciphers
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
asked Aug 22 at 20:13
DenverDave
62
add a comment |Â
up vote
1
down vote
favorite
During my self-teaching about trying to find mobile application vulnerabilities, I found a list of cipher suites that are/were considered insecure:
md5 sha1 sha-1 md4 rc4 des tripledes 3des
If I grepped for these terms in some decompiled Java code and got hits, would it be safe to say, there is a problem?
java ciphers
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
asked Aug 22 at 20:13
DenverDave
62
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
During my self-teaching about trying to find mobile application vulnerabilities, I found a list of cipher suites that are/were considered insecure:
md5 sha1 sha-1 md4 rc4 des tripledes 3des
If I grepped for these terms in some decompiled Java code and got hits, would it be safe to say, there is a problem?
java ciphers
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
asked Aug 22 at 20:13
DenverDave
62
During my self-teaching about trying to find mobile application vulnerabilities, I found a list of cipher suites that are/were considered insecure:
md5 sha1 sha-1 md4 rc4 des tripledes 3des
If I grepped for these terms in some decompiled Java code and got hits, would it be safe to say, there is a problem?
java ciphers
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
asked Aug 22 at 20:13
DenverDave
62
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
edited Aug 22 at 20:25
schroeder♦
63.7k24137171
63.7k24137171
asked Aug 22 at 20:13
DenverDave
62
asked Aug 22 at 20:13
DenverDave
62
asked Aug 22 at 20:13
DenverDave
62
62
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48
add a comment |Â
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
6
down vote
A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
add a comment |Â
up vote
6
down vote
A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
add a comment |Â
up vote
6
down vote
up vote
6
down vote
A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
answered Aug 22 at 20:21
Steffen Ullrich
104k10172242
104k10172242
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
add a comment |Â
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
1
1
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Hello Steffen, So if I read you right, I should then do a code crawl to get the context in which I am seeing results from my grep?
– DenverDave
Aug 22 at 22:15
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
Yes. An automated scan alone (even a simple one just using grep) is never proof of a vulnerability. You always need to follow up with context to ensure it's a true positive.
– Angelo Schilling
Aug 22 at 22:57
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
But that said, if these ciphers are being used for HTTPS communication between a client and server, then it's definitely worth fixing.
– Angelo Schilling
Aug 22 at 23:00
1
1
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
@AngeloSchilling: Claiming that these algorithms are unsuitable for HTTPS in general is not specific enough and essentially wrong. SHA-1 is still often used as HMAC in TLS ciphers (and therefore HTTPS). And there is nothing wrong with this. Even MD5 would be sufficient for this purpose. And the combination of MD5 and SHA-1 is used to construct the PRF in TLS 1.1 and this is not a problem either. If instead MD5 would be used as signature algorithm inside a certificate then it is definitely critical and also SHA-1 is deprecated for this kind of use.
– Steffen Ullrich
Aug 23 at 4:32
add a comment |Â
Â
draft saved
draft discarded
Â
draft saved
draft discarded
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f192126%2fcould-this-list-of-ciphersuites-be-improved-on%23new-answer', 'question_page');
);
Post as a guest
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
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
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
Those aren't ciphersuites, and half of them aren't even ciphers, and crypto algorithm names are usually given in uppercase not lowercase (although often especially in JCA case doesn't matter). Java code that uses the algorithm commonly called triple-DES actually names it DESEDE (in either case: often DESede and sometimes desede etc) for historical reasons, except when in a SSL/TLS ciphersuite name. And although there have been a few actual algorithm vulnerabilities (like RC4 in WEP) most vulnerabilites are in the applications and protocols, not the crypto itself.
– dave_thompson_085
Aug 23 at 6:48