June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3451) disabling CBC mode ciphers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3451?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-3451. ------------------------------------ Fix Version/s: 10.1.0.Final Resolution: Out of Date OpenSSL style filters of cipher suites can be specified from WildFly 10. > disabling CBC mode ciphers > -------------------------- > > Key: WFLY-3451 > URL: https://issues.jboss.org/browse/WFLY-3451 > Project: WildFly > Issue Type: Sub-task > Components: Security > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Aleksandr Voloschuk > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 10.1.0.Final > > > encountered such a problem: > management of information security vulnerability found on a production environment, namely: > SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability port 8443/tcp over SSL > RC4-SHA ECDHE-RSA-DES-CBC3-SHA SSLv3 > they offer a solution: > This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If > upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability. Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability. > as TLS upgrade we can not, it remains disabling CBC mode ciphers > our platform is jboss-eap-6.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-573) Programatic authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-573: ------------------------------------ Summary: Programatic authentication Key: ELY-573 URL: https://issues.jboss.org/browse/ELY-573 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta7 This is critical as it risks changing defined APIs and SPIs but we need to cover programatic authentication. It is however possible this is handled within the app server integration and not within our framework but we have two predominant cases: - - Servlet calls authenticate which means our mechanisms need to be triggered to challenge the client. - Servlet calls login with a username and password. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6705) Namespaces / schema versions of module.xml are out of sync

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-6705?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda updated WFLY-6705: ------------------------------------ Priority: Minor (was: Major) > Namespaces / schema versions of module.xml are out of sync > ---------------------------------------------------------- > > Key: WFLY-6705 > URL: https://issues.jboss.org/browse/WFLY-6705 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Rostislav Svoboda > Assignee: Tomaz Cerar > Priority: Minor > > Namespaces / schema versions of module.xml are out of sync: > {code} > grep "urn:jboss:module" jboss-eap-7.0/modules/ -R | cut -d: -f 5 | cut -d\" -f1 | sort | uniq -c > 5 1.1 > 352 1.3 > 1 1.5 > {code} > 1.5 is used by: > ./modules/system/layers/base/javax/transaction/api/main/module.xml > 1.1 is used by: > ./modules/system/layers/base/org/jboss/as/domain-http-error-context/eap/module.xml > ./modules/system/layers/base/org/jboss/as/product/eap/module.xml > ./modules/system/layers/base/org/hibernate/search/backend-jgroups/main/module.xml > ./modules/system/layers/base/org/hibernate/search/serialization-avro/main/module.xml > ./modules/system/layers/base/org/hibernate/search/backend-jms/main/module.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-572) Update the GSSAPI SASL mechanism to use the ServerCredentialCallback(GSSCredentialCredential.class)

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-572: ------------------------------------ Summary: Update the GSSAPI SASL mechanism to use the ServerCredentialCallback(GSSCredentialCredential.class) Key: ELY-572 URL: https://issues.jboss.org/browse/ELY-572 Project: WildFly Elytron Issue Type: Bug Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta7 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1101) Enhance the security realm plug-in mechanism for client-cert / external verification.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1101?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1101. -------------------------------------- Fix Version/s: 3.0.0.Alpha2 Assignee: Darran Lofthouse Resolution: Out of Date Moving to WildFly Elytron which already contains a comprehensive security realm API/SPI and will also support custom implementations. > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFCORE-1101 > URL: https://issues.jboss.org/browse/WFCORE-1101 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Realm_Management > Fix For: 3.0.0.Alpha2 > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1102) Increase Test Coverage of Domain Management Security Options

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1102?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1102. -------------------------------------- Fix Version/s: 3.0.0.Alpha2 Assignee: Darran Lofthouse Resolution: Out of Date The existing realms are deprecated as we are moving to Elytron so no need to spend time increasing test coverage now. > Increase Test Coverage of Domain Management Security Options > ------------------------------------------------------------ > > Key: WFCORE-1102 > URL: https://issues.jboss.org/browse/WFCORE-1102 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: testsuite > Fix For: 3.0.0.Alpha2 > > > Presently there is plenty of testing relating to the default security options but now we need coverage of the non default options especially SSL. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1103) Security realms does not validate JAAS references to security domains

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1103?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1103. -------------------------------------- Fix Version/s: 3.0.0.Alpha2 Resolution: Rejected Rejecting for a couple of issues. Firstly security realms are deprecated and being replaced with WildFly Elytron. Within Elytron where we do make use of JAAS security domains this will be through capability references which means dependencies will be checked during model validation. Secondly the realm dependencies as well as depending on domains in the security subsystem they can also depend on JAAS configurations in a jaas.conf file for processes such as in a HostController to dependency detection is not a simple task. Even in a domain hosted app server the cross resolution of dependencies is very complex. > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFCORE-1103 > URL: https://issues.jboss.org/browse/WFCORE-1103 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > Fix For: 3.0.0.Alpha2 > > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1313?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1313: ------------------------------------- Priority: Minor (was: Major) > User with slash or backslash char in LDAP name cannot log in through security-realm > ----------------------------------------------------------------------------------- > > Key: WFCORE-1313 > URL: https://issues.jboss.org/browse/WFCORE-1313 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Lin Gao > Priority: Minor > Attachments: users.ldif > > > According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc. > I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there. > I can see this in Wireshark > *Slash/Char* > {code} > LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2 > {code} > You can see there quotation marks around *uid=Slash/Char*. > *Back\Slash* > {code} > LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6 > {code} > You can see there three backslash chars. > In my opinion problem can be somewhere around this > {code} > javax.naming.NameImpl.stringifyComp(String comp) > {code} > [1] https://tools.ietf.org/html/rfc2253#section-3 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1116) Review initial user creation process.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1116?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1116. -------------------------------------- Resolution: Rejected Rejecting as we will be reviewing the default out of the box configuration with Elytron which in turn will lead us to review tooling around this. > Review initial user creation process. > ------------------------------------- > > Key: WFCORE-1116 > URL: https://issues.jboss.org/browse/WFCORE-1116 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha2 > > > We started off with a very simple add user utility where the purpose was just to get the first management user added so users could remotely administer the server, this tool has grown and grown so now it covers management users and application users. we also have additional questions in relation to groups that are not obvious to users what they need to add. > This task is to look into providing something that in it's simplest form just focusses on the first management user. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Alpha2 > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha2 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016