> On Apr 16, 2018, at 5:56 AM, Tobias Gondrom <tobias.gond...@gondrom.org>
> wrote:
>
> Are there any informational (or standard) RFCs for TLS that speak about this
> risk and best practices to address it?
> (e.g. using additional whitelist checks of parameters inside the client
> certificate for access control checks already during phase of establishing
> the TLS connection)
A major obstacle to making access control decisions during the TLS handshake is
that at that time the server often does not yet have enough information to
determine which specific resource the client will ask to access.
If the access control is very coarse, and the client is simply not allowed any
of the features of the application, then one might terminate the handshake
"early", but by the time server has processed the client certificate it has
done pretty much all the heavy lifting (signing its own key exchange messages,
...) so allowing the handshake to complete and dealing with access control at
the application layer is far more typical, and makes possible more meaningful
(to the client application) "Permission denied" error responses, which would be
far less likely to be understood if communicated via a handshake failure.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
