> I want to check the risk scenario for authorizing CAS services [via the Services Registry] > that are not behind SSL, i.e. http://example.com/casapp
> All the data that flows over the connection is liable to > interception, including potentially sensitive data returned by the CAS > server like proxy tickets and attribute release payload. I don't see how a service not using http:// exposes risk around proxy tickets without additional non-default bad-security-policy configuration of the CAS server or in proxy-ticket-accepting applications. CAS vends Proxy Granting Tickets via a callback to an https:// service exposed by the proxy-granting-ticket-requesting application. Interception of the Service Ticket is not sufficient to obtain a proxy granting ticket in the name of a service. Therefore, an http:// service URL, even though it exposes the service ticket to interception, does not expose a proxy granting ticket to interception. By default, CAS will support not-SSLed service URLs, but will not vend proxy granting tickets to non-SSLed proxyCallbackUrl endpoints. Proxy granting tickets are delivered only to https:// URLs since validation of that certificate is essential to the proxy granting ticket security model, to what proxy granting tickets mean. The code in the CAS server that enforces the HTTPS-ness of proxy callback URLs is the HttpBasedServiceCredentialsAuthenticationHandler <https://github.com/Jasig/cas/blob/v3.4.10/cas-server-core/src/main/java/org/jasig/cas/authentication/handler/support/HttpBasedServiceCredentialsAuthenticationHandler.java>. You can configure it (in the CAS server Spring wiring, i.e. in XML) not to require HTTPS; configuring it that way would be a very bad idea outside of a trivial demo environment. The https://-ness of proxy callback URLs is essential to the meaning of proxy granting tickets and the subsequent proxy tickets since it is by the validation of the SSL certificates for these callback URLs that proxying services are authenticated. Vending PGTs in this way and *not* directly in the service ticket validation response XML is by design, precisely so that mere possession of a service ticket is insufficient to obtain a PGT that allows proxying in the name of a service. Proxy tickets can be obtained only be presenting a valid PGT to the CAS server proxy ticket vending endpoint (/cas/proxy), which you'll expose as an https:// endpoint on your CAS server. The fact of the service not using https:// doesn't prevent CAS from using https://, so there's no exposure of the proxy ticket when it's vended in response to the PGT that by default the non-SSL-using application can't get anyway. :) If the not-https-using service then turns around and presents that PT to an also-not-https-using backing service, then the proxy ticket is vulnerable to interception. But at that point it's a matter of that backing service failing to use https://. Non-SSLed CAS-using service URLs are a bad idea, no doubt, but they don't entail a risk of obtaining proxy tickets authenticating that service. If you were relying upon the Services Registry "allowed to proxy" configuration, then allowing a non-https-using service to proxy does expose a risk of the adversarial interceptor of a service ticket for that service to use it to obtain a proxy granting ticket for a URL controlled by the adversary. That is, intercepting a service ticket doesn't allow me to get a PGT in the name of any URL other than that of a URL for which I control the https certificate private key, but it might allow me to get CAS to issue a PGT to that URL I control if the service for which that ST was intended is "allowed to proxy". However, scrutinizing the proxy chain on the part of acceptors of proxy tickets is essential to the CAS proxy ticket security model. That's why it's easy for services to reject all proxy tickets (by validating against the /serviceValidate endpoint rather than the /proxyValidate endpoint) and why the proxy chain is included in the /proxyValidate validation response. An adversary's being able to obtain a proxy granting ticket *authenticating his own service* shouldn't be any security problem because no proxy-ticket-accepting service should be accepting proxy authentication from the Adversary-rightly-identified. When a proxy-ticket-accepting application examines the proxy chain and sees that it's not what was expected, it should reject the attempt to authenticate to it via the ST. CAS is a speaker of truth. It doesn't tell a service what to do about that truth. Such a proxy ticket would truly authenticate the adversary's web application -- that doesn't mean that anyone should service requests from the adversary's web application. (Philosophically similar to, when an application validates the service ticket, CAS will tell it who the user is -- that doesn't mean the application then necessarily ought to service that user's request. Upon finding out who the user is, the application might decide it has nothing to offer that particular user. ) It is the case that an adversary intercepting a service ticket and then validating it against the attribute-release-supporting SAML endpoint in CAS is sufficient to lay hands on whatever user attributes would be released to the legitimate application for which the ST was intended. Andrew On 09/29/2011 01:01 PM, Marvin Addison wrote: >> I want to check the risk scenario for authorizing CAS services that are not >> behind SSL, e.g. http://example.com/casapp >> Is the scenario that someone might intercept the ticket from the redirect to >> the users browser? > I believe that's the most common concern, yes, but certainly not the > only one. All the data that flows over the connection is liable to > interception, including potentially sensitive data returned by the CAS > server like proxy tickets and attribute release payload. With tools > like FireSheep interception of data like this over wifi networks is > trivially easy, so disclosure of this kind of data should be of > considerable concern. My standard rhetorical question for these > cases: > > Why bother with authentication if the subsequent data is trivially > difficult to steal? > > M > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
