+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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev