[jboss-jira] [JBoss JIRA] (WFLY-2653) HTTPS undertow listener select cipher-suites

[ https://issues.jboss.org/browse/WFLY-2653?page=com.atlassian.jira.plugin.... ] Aleksandar Kostadinov updated WFLY-2653: ---------------------------------------- Description: At the moment I don't see any way to restrict allowed cipher suites for the https listener. {CODE} [standalone@localhost:9990 /] /core-service=management/security-realm=HttpsRealm:read-resource(recursive=true, include-defaults=true) { "outcome" => "success", "result" => { "map-groups-to-roles" => true, "authentication" => undefined, "authorization" => undefined, "plug-in" => undefined, "server-identity" => {"ssl" => { "alias" => undefined, "key-password" => undefined, "keystore-password" => "changeit", "keystore-path" => "localhost.keystore", "keystore-relative-to" => "jboss.server.config.dir", "protocol" => "TLS" }} } } [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:read-resource(recursive=true, include-defaults=true) { "outcome" => "success", "result" => { <...> "https-listener" => {"https" => { "allow-encoded-slash" => false, "always-set-keep-alive" => true, "buffer-pipelined-data" => true, "buffer-pool" => "default", "decode-url" => true, "enabled" => true, "max-cookies" => 200, "max-header-size" => 51200, "max-headers" => 200, "max-parameters" => 1000, "max-post-size" => 10485760L, "security-realm" => "ApplicationRealm", "socket-binding" => "https", "url-charset" => "UTF-8", "verify-client" => "NOT_REQUESTED", "worker" => "default" }} } } {CODE} I have tested that default cipher suites used are pretty sane except RC4-SHA and RC4-MD5. Below is full list. But I think it is important for users to be able to support more or less ciphers depending on their environment and requirements. We also need good secure default settings IMO excluding the above mentioned two ciphers. See current recommendations here [1][2] {CODE} $ sslscan --no-failed localhost:8443 _ ___ ___| |___ ___ __ _ _ __ / __/ __| / __|/ __/ _` | '_ \ \__ \__ \ \__ \ (_| (_| | | | | |___/___/_|___/\___\__,_|_| |_| Version 1.8.2 http://www.titania.co.uk Copyright Ian Ventura-Whiting 2009 Testing SSL server localhost on port 8443 Supported Server Cipher(s): Accepted SSLv3 256 bits DHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits DHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 {CODE} [1] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Def... [2] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Def... was: At the moment I don't see any way to restrict allowed cipher suites for the https listener. {CODE} [standalone@localhost:9990 /] /core-service=management/security-realm=HttpsRealm:read-resource(recursive=true, include-defaults=true) { "outcome" => "success", "result" => { "map-groups-to-roles" => true, "authentication" => undefined, "authorization" => undefined, "plug-in" => undefined, "server-identity" => {"ssl" => { "alias" => undefined, "key-password" => undefined, "keystore-password" => "changeit", "keystore-path" => "localhost.keystore", "keystore-relative-to" => "jboss.server.config.dir", "protocol" => "TLS" }} } } [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:read-resource(recursive=true, include-defaults=true) { "outcome" => "success", "result" => { <...> "https-listener" => {"https" => { "allow-encoded-slash" => false, "always-set-keep-alive" => true, "buffer-pipelined-data" => true, "buffer-pool" => "default", "decode-url" => true, "enabled" => true, "max-cookies" => 200, "max-header-size" => 51200, "max-headers" => 200, "max-parameters" => 1000, "max-post-size" => 10485760L, "security-realm" => "ApplicationRealm", "socket-binding" => "https", "url-charset" => "UTF-8", "verify-client" => "NOT_REQUESTED", "worker" => "default" }} } } {CODE} I have tested that default cipher suites used are pretty sane except RC4-SHA and RC4-MD5. Below is full list. But I think it is important for users to be able to support more or less ciphers depending on their environment and requirements. We also need good secure default settings IMO excluding the above mentioned two ciphers. See current recommendations here [1][2] {CODE} $ sslscan --no-failed localhost:8443 _ ___ ___| |___ ___ __ _ _ __ / __/ __| / __|/ __/ _` | '_ \ \__ \__ \ \__ \ (_| (_| | | | | |___/___/_|___/\___\__,_|_| |_| Version 1.8.2 http://www.titania.co.uk Copyright Ian Ventura-Whiting 2009 Testing SSL server localhost on port 8443 Supported Server Cipher(s): Accepted SSLv3 256 bits DHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits DHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 {CODE} I added the links listing recommended crypto primitives. The minimum IMO is to have the `cipher-suite` attribute exposed like in jboss-web ssl configuration. It would be real nice if the attribute supports also filter by string. For example if user puts something like "ALL:!MD5:!DHA" that could filter out all MD5 and DH anonymous based suites. Would be something like `man ciphers`. The latter will allow for easily setting secure defaults that work across different JVMs because exact cipher names differ slightly across different JVMs. Otherwise we may need a separate list for each JVM. But that's perhaps more relevant for the product side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira