Man in the Middle attack

[Scott Battaglia]

The description that Shawn has given for CAS 2 also applies for CAS 3.  If
the clients wish to use HTTPS they need to ensure that the service url they
give to CAS is a secure url.  The clients may implement this service url
construction differently.  I know that the CAS clients check for
request.isSecure.

-Scott

CAS merely redirects you back to whatever URL you provide.
On 10/11/06, Shawn Bayern <bayern at boalthall.berkeley.edu> wrote:
>
> On Wed, 11 Oct 2006, Stephen A. Cochran wrote:
>
> > This would work if the redirect from the CAS server is not done over
> > SSL. I know by default CAS changes service URLs to SSL, but if there is
> > a port number in the hostname it seems to NOT do so (probably because it
> > can't know what port to go to).
>
> I don't know about the new CAS code, but as of version 2, CAS allowed
> redirects to insecure (non-https) services on the assumption they wanted
> best-efforts authentication.  But for the reasons you describe, CAS never
> guaranteed that such authentications were secure:  if the service does not
> use https, the user cannot assume the server is authentic, the server
> cannot assume the user is authentic, and the traffic may be intercepted
> arbitrarily.  This of course does not compromise the security of the
> central CAS server or other (https-protected) services that use CAS.
>
> Shawn
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20061011/8dbc4310/attachment.html