2:25 p.m.
Ahoy, today I was reading about this "new" vulnerability on TLS (
http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html).
And was wondering if we should blacklist or document broken protocols.
Preventing people to deploy Keycloak in non secure environments.
Something like was already suggested for Poodle here:
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566...
Snippet:
SSLSocket sslSocket = sslSocketFactory.createSocket(...);
// Strip "SSLv3" from the current enabled protocols.
String[] protocols = sslSocket.getEnabledProtocols();
Set<String> set = new HashSet<>();
for (String s : protocols) {
if (s.equals("SSLv3") || s.equals("SSLv2Hello")) {
continue;
}
set.add(s);
}
sslSocket.setEnabledProtocols(set.toArray(new String[0]));
Should we document? Blacklist? Or leave it as is?
2:34 a.m.
On 01.03.2016 21:25, Bruno Oliveira wrote:
Ahoy, today I was reading about this "new" vulnerability on TLS
(http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html).
And was wondering if we should blacklist or document broken protocols.
Preventing people to deploy Keycloak in non secure environments.
...
Should we document? Blacklist? Or leave it as is?
I'd say "do nothing". Good system admins already have something in place
that would alert them in those cases, ranging from monitoring
vulnerabilities databases to scripting the score check via ssllabs.com.
The main problem that I see with adding some sort of support like this
directly into Keycloak is that you'd need a lot of effort to keep it up
to date. If a comprehensive check cannot be done, people would either
ignore it, or people will trust it because of the false sense of
security it gives.
- Juca.
2:45 a.m.
+1 To do nothing
SSL for KC itself is provided by WildFly, so this is WildFly/Undertow's
responsibility. For outgoing SSL connections (db, ldap, etc..) it's up to
the admin to configure those resources correctly.
On 2 March 2016 at 09:34, Juraci Paixão Kröhling <jpkroehling(a)redhat.com>
wrote:
On 01.03.2016 21:25, Bruno Oliveira wrote:
>
> Ahoy, today I was reading about this "new" vulnerability on TLS
> (
http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html
).
> And was wondering if we should blacklist or document broken protocols.
> Preventing people to deploy Keycloak in non secure environments.
>
...
>
> Should we document? Blacklist? Or leave it as is?
I'd say "do nothing". Good system admins already have something in place
that would alert them in those cases, ranging from monitoring
vulnerabilities databases to scripting the score check via ssllabs.com.
The main problem that I see with adding some sort of support like this
directly into Keycloak is that you'd need a lot of effort to keep it up
to date. If a comprehensive check cannot be done, people would either
ignore it, or people will trust it because of the false sense of
security it gives.
- Juca.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:18 a.m.
+1 Makes sense
On Wed, Mar 2, 2016, 5:46 AM Stian Thorgersen <sthorger(a)redhat.com> wrote:
+1 To do nothing
SSL for KC itself is provided by WildFly, so this is WildFly/Undertow's
responsibility. For outgoing SSL connections (db, ldap, etc..) it's up to
the admin to configure those resources correctly.
On 2 March 2016 at 09:34, Juraci Paixão Kröhling <jpkroehling(a)redhat.com>
wrote:
> On 01.03.2016 21:25, Bruno Oliveira wrote:
> >
> > Ahoy, today I was reading about this "new" vulnerability on TLS
> > (
> http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html
> ).
> > And was wondering if we should blacklist or document broken protocols.
> > Preventing people to deploy Keycloak in non secure environments.
> >
> ...
> >
> > Should we document? Blacklist? Or leave it as is?
>
> I'd say "do nothing". Good system admins already have something in
place
> that would alert them in those cases, ranging from monitoring
> vulnerabilities databases to scripting the score check via ssllabs.com.
>
> The main problem that I see with adding some sort of support like this
> directly into Keycloak is that you'd need a lot of effort to keep it up
> to date. If a comprehensive check cannot be done, people would either
> ignore it, or people will trust it because of the false sense of
> security it gives.
>
> - Juca.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2979
days inactive
2980
days old
3 comments
3 participants
participants (3)
-
Bruno Oliveira -
Juraci Paixão Kröhling -
Stian Thorgersen