On 2015-02-06 20:22, Tom Boutell wrote: > Since the login server never redirects with a ticket to any site but > one of its whitelisted client websites, and always with https, and the > client website always uses https to call back to the login server, I > don't see a risk of man-in-the-middle attack there so far. But I could > be missing something.
The risk isn't with redirects, it's when the client web server contacts the central weblogin server to verify the service cookie (ticket, in CAS parlance, if I understand things correctly). CAS does this verification via HTTPS, so that the client web server knows (by verifying the certificate of the CAS login server when the HTTPS session is established) that it is talking to a legitimate CAS login server rather than to a man-in-the-middle or other imposter who might be lying about the validity of the CAS ticket. The same is true with cosign: when a client web server establishes a connection to a central weblogin server, the connection is protected with TLS, and the client web server verifies the certificate of the central weblogin server. In addition to the cosign client web server verifying the certificate of the central weblogin server, the cosign client web server also presents a certificate of its own which the central weblogin server verifies. This way, the central weblogin server knows that it is in fact talking to a legitimate whitelisted client web server, which provides stronger assurance of the client webserver's identity than just IP and DNS information. This stronger assurance is good especially when proxying credentials such as Kerberos tickets from the central weblogin server to the client web servers. This is exactly the same as the assurance provided by HTTPS client certificates, if/when used. Note that while CAS client website uses HTTPS to query the CAS login server, cosign client web servers query the central weblogin servers using a cosign-specific protocol sent over a TLS session. This permits the cosign client web servers to maintain persistent connections to each of the central weblogin servers to avoid the overhead of frequent TLS session establishment. Finally, while cosign is most frequently configured to use and trust the same certificates used by HTTPS, because cosign does not use HTTPS for its back-channel traffic, the option exists to use different certificates for the back-channel traffic than is used for web traffic. For example, cosign can use its own in-house certificate authority for either the central weblogin server back-channel certificates, for the cosign client web server back-channel certificates, or both. Cosign maintains its own list of trusted certificate authorities that is separate from the list of certificate authorities trusted by web browsers or web servers -- if cosign's trusted CA list is set to be only the in-house certificate authority, attackers who compromise commercial certificate authorities ( https://www.google.com/#q=certificate+authority+compromised ) will not be able to issue certificates to subvert cosign back-channel communications. (Note that the University of Michigan currently uses its own in-house CA for its central weblogin servers' back-channel certificate; client web server back-channel certificates can be either from the same CA or from a list of 3-4 specific trusted commercial CAs). -- Mark Montague m...@catseye.org ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
