Ensuring all network services on a device use strong TLS cipher suitesIs there a way to mitigate BEAST...
Rent contract say that pets are not allowed. Possible repercussions if bringing the pet anyway?
How do proponents of Sola Scriptura address the ministry of those Apostles who authored no parts of Scripture?
Notepad++ cannot print
Does an atom recoil when photon radiate?
Handling Disruptive Student on the Autistic Spectrum
Sum ergo cogito?
Who was president of the USA?
How to know which loss function is suitable for image classification?
Do they have Supervillain(s)?
Obtaining the intermediate solutions in AMPL
Are modern clipless shoes and pedals that much better than toe clips and straps?
Non-visual Computers - thoughts?
How do I, an introvert, communicate to my friend and only colleague, an extrovert, that I want to spend my scheduled breaks without them?
Why do banks “park” their money at the European Central Bank?
Why did Khan ask Admiral James T. Kirk about Project Genesis?
How do we calculate energy of food?
Transposing from C to Cm?
If an earthquake can destroy buildings why it cant kill us according to physics?
What would make bones be of different colors?
How to find out the average duration of the peer-review process for a given journal?
Why isn't "I've" a proper response?
Why does Windows store Wi-Fi passwords in a reversable format?
Improving Performance of an XY Monte Carlo
Why are non-collision-resistant hash functions considered insecure for signing self-generated information
Ensuring all network services on a device use strong TLS cipher suites
Is there a way to mitigate BEAST without disabling AES completely?Any MITM tool for forcing weak SSL cipher suite?How can I verify that SSLv3 protocol is disabled?TLS Version specific cipher suitesThe First Few Milliseconds of an HTTPS Connection [TLS 1.2 / TLS_ECHDE_RSA_WITH_AES_128_GCM_SHA256]Is there a tool to test whether a server supports any cipher suite?Guidelines for TLS cipher suites?TLS Cipher Suites for MTATLS/SSL cipher suites
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
(This is hypothetical, but based on a real-life problem I've had)
Context:
I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.
I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.
Problem:
I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).
Assumptions:
- I know that OpenSSL is the only crypto library/program in use on the system.
Now some questions:
What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)
Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.
Is this even possible, or do I necessarily need to look at each service?
tls defense cipher-selection
asked yesterday
JosiahJosiah
1486 bronze badges
add a comment |
(This is hypothetical, but based on a real-life problem I've had)
Context:
I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.
I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.
Problem:
I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).
Assumptions:
- I know that OpenSSL is the only crypto library/program in use on the system.
Now some questions:
What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)
Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.
Is this even possible, or do I necessarily need to look at each service?
tls defense cipher-selection
asked yesterday
JosiahJosiah
1486 bronze badges
add a comment |
(This is hypothetical, but based on a real-life problem I've had)
Context:
I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.
I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.
Problem:
I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).
Assumptions:
- I know that OpenSSL is the only crypto library/program in use on the system.
Now some questions:
What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)
Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.
Is this even possible, or do I necessarily need to look at each service?
tls defense cipher-selection
asked yesterday
JosiahJosiah
1486 bronze badges
(This is hypothetical, but based on a real-life problem I've had)
Context:
I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.
I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.
Problem:
I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).
Assumptions:
- I know that OpenSSL is the only crypto library/program in use on the system.
Now some questions:
What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)
Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.
Is this even possible, or do I necessarily need to look at each service?
tls defense cipher-selection
tls defense cipher-selection
asked yesterday
JosiahJosiah
1486 bronze badges
asked yesterday
JosiahJosiah
1486 bronze badges
edited yesterday
Josiah
asked yesterday
JosiahJosiah
1486 bronze badges
asked yesterday
JosiahJosiah
1486 bronze badges
asked yesterday
JosiahJosiah
1486 bronze badges
1486 bronze badges
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
What options do I have for preventing network services from allowing weak TLS ciphers?
Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.
Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.
You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.
Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.
Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior ofSSL_readandSSL_writein some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.
– Steffen Ullrich
yesterday
add a comment |
It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.
For example
./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make
will build OpenSSL without weak protocols
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
add a comment |
Tunneling/proxying
One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.
I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
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%2f215827%2fensuring-all-network-services-on-a-device-use-strong-tls-cipher-suites%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
What options do I have for preventing network services from allowing weak TLS ciphers?
Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.
Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.
You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.
Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.
Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior ofSSL_readandSSL_writein some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.
– Steffen Ullrich
yesterday
add a comment |
What options do I have for preventing network services from allowing weak TLS ciphers?
Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.
Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.
You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.
Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.
Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior ofSSL_readandSSL_writein some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.
– Steffen Ullrich
yesterday
add a comment |
What options do I have for preventing network services from allowing weak TLS ciphers?
Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.
Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.
You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.
Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.
Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
What options do I have for preventing network services from allowing weak TLS ciphers?
Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.
Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.
You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.
Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.
Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
answered yesterday
Steffen UllrichSteffen Ullrich
128k17 gold badges228 silver badges295 bronze badges
128k17 gold badges228 silver badges295 bronze badges
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior ofSSL_readandSSL_writein some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.
– Steffen Ullrich
yesterday
add a comment |
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior ofSSL_readandSSL_writein some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.
– Steffen Ullrich
yesterday
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working?
– Josiah
yesterday
1
1
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior of
SSL_read and SSL_write in some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.– Steffen Ullrich
yesterday
@Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior of
SSL_read and SSL_write in some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets.– Steffen Ullrich
yesterday
add a comment |
It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.
For example
./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make
will build OpenSSL without weak protocols
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
add a comment |
It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.
For example
./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make
will build OpenSSL without weak protocols
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
add a comment |
It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.
For example
./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make
will build OpenSSL without weak protocols
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.
For example
./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make
will build OpenSSL without weak protocols
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
answered yesterday
JenessaJenessa
7793 silver badges12 bronze badges
7793 silver badges12 bronze badges
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
add a comment |
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all.
– dave_thompson_085
21 hours ago
add a comment |
Tunneling/proxying
One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.
I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
add a comment |
Tunneling/proxying
One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.
I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
add a comment |
Tunneling/proxying
One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.
I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
Tunneling/proxying
One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.
I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
answered 8 hours ago
PeterisPeteris
6,8221 gold badge19 silver badges29 bronze badges
6,8221 gold badge19 silver badges29 bronze badges
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%2f215827%2fensuring-all-network-services-on-a-device-use-strong-tls-cipher-suites%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
