The use case is a fairly extreme one : the DNS attack. Suppose an attacker has taken control over the DNS resolver (locally or more globally), when the CAS server will redirect back the user to the application with a valid service ticket, in fact it will be redirected wrongly by the DNS to the attacker's web site (which can use the true service ticket on the true application). The only way to prevent that is to check the certificate of the web site using HTTPS.
The only implementation that substantially improves security is to require client SSL authentication at the CAS validation endpoints, which is a fairly big hurdle to impose on deployers. The benefit of this solution is that it's entirely outside of CAS application configuration. For example, in Tomcat you would simply configure an additional connector on another port (e.g. 9443) that requires client SSL authentication and then reconfigure the CAS client to point to the alt port.
Consider the alternative: validate the server certificate of the CAS client host on another connection (similar to proxy callback). Since the server is presumably secured by a cert signed by a major vendor like Thawte or Verisign, you'll be trusting a very large number of certificates (not desirable generally). Additionally, since the premise is suspect DNS, it should be dramatically easier to obtain a certificate for the target CAS client host from the certificate authority. In particular the attacker presumably can set MX records to intercept communication used to establish proof of ownership of the domain.
I would think DNSSEC goes a long way to mitigating unverifiable name resolver data that is the basis of this attack.
M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
