On Wed, Jun 13, 2012 at 2:53 PM, Alan DeKok
<aland@deployingradius.com> wrote:
august huber wrote:
> While performing some integration work with FreeRadius I have hit some
> barriers in providing meaningful errors to clients during failed SSL
> (eap_tls) transactions. I was perplexed to discover that all SSL
> contexts receive SSL_get_quiet_shutdown(ctx,1) called before shutdown.
> I'm curious about the logic behind this decision; specifically is it
> targeted to decrease attacker awareness of failure modes or a function
> of poor client integration causing some platform to barf when it
> receives a TLS Alert message? If neither, does anyone know how this
> change made it there?
If I recall, it's because there's no real point in sending anything to
the client. The EAP session has already failed. Sending more
information as to *why* it failed isn't useful.
Having the SSL session hang around waiting to send more data isn't
useful either.
I have to disagree here, it is useful for the client to understand that their transaction failed due to an expired cert versus a revoked cert versus having sent a cert that does not verify up to a known CA chain (as some platforms are especially bad at self selecting credentials when more than one is present)
For a complete list of alerts that are supported see RFC2246 Section 7.2
OpenSSL is already populating this for us during the verify, FreeRadius is explicitly removing it from the response.
This will not cause the connections to remain open, but instead will send an Alert with the cause during the shutdown.
> Adding a conflg flag seems relatively straightforward for this case to
> preserve the silent functionality when desired, but wanted to query the
> list to see if anyone has a strong opinion before I do.
I'm not really sure it's a good idea.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html