cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: HTTP Basic Authentication Is there hope?
Date Mon, 12 Feb 2007 16:48:09 GMT
 
Hi Fred, comments inline ...

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 12 February 2007 15:39
> To: cxf-dev@incubator.apache.org
> Subject: Re: HTTP Basic Authentication Is there hope?
> 
> 
> I tend to [snip] quoted text a lot, so please pardon me if 
> any of the responses appear out of context.

I'll snip liberally too here to focus on your questions ...
 
> >> We would like to examine certain aspects of the endpoint before we 
> >> start *exposing usernames and passwords to
> >> everybody* with a pretty flower.
> >> There is no apparent way to do this in CXF's use of HTTP.
> >
> > Well to an extent there is some control here - we can configure the 
> > SSLClientPolicy to require that the endpoint has a trusted cert.
> 
> Okay, now that's interesting.  What would we need to do to do this?

Just configure a truststore (via the SSLClientPolicy TrustStore element)
that includes only the CAs that the client trusts. Isn't that the basis
of all cert-based auth? 
 
> >> Even this java.net.Authenticator is woefully inadequate as
> >> there is now way too look up an SSL authentication on the
> >> HttpURLConnection.
> >
> > Do we really need to access the full details of the SSL 
> authentication
> > at this point? Would a check via Authenticator.getProtocol() that  
> > HTTPS
> > was indeed used, coupled with the client's knowledge of and 
> control  
> > over
> > its own local truststore, not be sufficient?
> 
> I think we might.  For example, it may not be enough that the  
> endpoint uses SSL.  What if, for example, you're using DH anonymous  
> cipher suites?  All you get there is data protection, which if you  
> think about it, is vulnerable to man-in-the-middle attacks (in which  
> case you don't really get data protection at all).

Sure DH_anon is vulnerable to MITM and for this (and other) reasons, we
provide a configured ciphersuite filter mechanism to allow CXF apps
include and exclude various ciphersuites based on regex-matching. See
for example the HTTPS demo config for an example of DH_anon exclusion:
cxf/trunk/distribution/src/main/release/samples/hello_world_https/server
.xml. So the config already provides the mechanism for any ciphers we
consider too weak to be excluded.
 
> There may also be cases in which, say, for some authenticated  
> endpoints, you are willing to disclose a password (it has a key  
> signed by Zeus), whereas others you don't.  So yeah, some details  
> into the security features of the target could definitely be of use.

Now I'm confused. When would you accept a endpoint's "strong auth" creds
(i.e. the signed cert provided in the TLS handshake) and possibly expose
your own cert (if the endpoint requests it during the TLS handshake),
but not be prepared to expose your own "weak auth" creds (i.e. Basic
auth username/passwd) to that endpoint? If the endpoint isn't worthy of
trust, why would it have a cert signed by a CA we trust. 

Or is it a question of degrees of trust? But if so, surely accepting the
endpoint's cert is the bigger leap of faith than handing out your Basic
auth username/passwd?

> I'm also not sure if the coupling with control over the local 
> trustdb  
> is enough.  How does the runtime know what the trust policies are in  
> effect?  

Well the trust policy in effect is encoded in the truststore, which is
in the client's domain and therefore under their control. So why
replicate this checking in the runtime?

> If it's something that is outside of the control of the  
> runtime, but rather at the discretion of the administrator  
> ("Configure your endpoints thusly"), I suppose that's an 
> approach one  
> could take, but there's very little you could say in terms of  
> assurance, at that point, and I think what we are after is wiring  
> some sort of hooks into the runtime in order to be able to make  
> assurance arguments about its behavior.

See, I don't think we really get any real extra assurance with such a
layer implemented in the runtime. Maybe a nice hook to integrate with
mgmt tools, but is it any more secure? 

Here's my logic: say we don't trust the client to set up their
truststore correctly, so we want to check in the runtime that the
endpoint has been authenticated to our satisfaction. But the "to our
satisfaction" test has to be driven by some sort of config, so that it
can be strengthened or weakened, presumably via config, depending on the
policies we want to assure. So now we're relying on this config also
being present and correct, as opposed to just the truststore itself
being set up correctly. It sorrta amounts to more of the same thing ...
something the client has to ensure it has set up, in order for bad stuff
not to happen. 

Except now they have two things to set up correctly, and maybe that
becomes too much bother so they're tempted to wildcard etc. So the
attempt to makes things more secure by adding another layer of checking
could actually be counter-productive.
 
> > Here's the crux of the issue, what's a "good security solution", and
> > what sort of underlying mechanism is required to supply 
> this goodness?
> > Is it reasonable to expect to able to build "hardened" security on a
> > foundation as shaky as Basic auth? There are other, less weak, HTTP
> > authorization mechanisms (Digest, NTLM etc.) that we could consider
> > instead.
> 
> Well, as Dan suggested, the same issue comes up with the WS-Security  
> username-password profile.  If you're going to send a username and  
> password, you are going to need to ensure that the endpoint you're  
> sending to is trustworthy.  You may want the same assurance with  
> other profiles.  (Won't go into the details, but SAML through SOAP  
> comes to mind).

The point I was making is that Basic auth seems to be weakest of them
all, as any ol' endpoint can issue a challenge, without establishing its
bona fides in any way. At least for example the Digest scheme requires
the endpoint to provide a nonce containing say a private-key known only
to the server. I'm sure Digest has its own vulnerabilities, but maybe
not as wide open to drive a coach-and-four thru', as seems to be the
case with the Basic auth scheme.
 
> Getting on to what I interpret the main point of the post, the  
> question seems to apply to the granularity of the effective policies  
> used at a client endpoint (or server, but I won't go there):
> 
>   1. When endpoint policies are specified via config (leaving aside  
> the question of programmatic configuration), the policies are  
> identified in a bean, and are based on a QName.
>   2. In the case of HTTP/BA, the effective policy may be to send a  
> username and password.
>   3. It seems possible for more than one client endpoint 
> (potentially  
> referencing 2 different endpoints) to be associated with, or  
> identified by, the same QName.
>   4. Therefore, it's possible for a client application to  
> inadvertently send its username and password to these 2 services,  
> irrespective of any authentication that has or has not occurred of  
> said targets.
> 
> I propose we stick to this issue (if I've characterized it  
> correctly), and come to agreement about whether it is or is not a  
> problem, and if it is, how we rectify it.

That pretty much sums it up. And my (admittedly layperson's, and perhaps
simplistic) notion was the following would give us all or most of what
we need:

1. Extend AuthorizationPolicy to allow multiple per-realm/targetURI
username/password pairs to be configured.
2. Allow (optional) programmatic retrieval of creds via callback into
the app.
3. Ensure the http client (either java.net.HttpUrlConnection or commons
HTTPClient) can handle the 401 properly and associate it with the
appropriate creds.
4. Advise users that Basic auth should only be used over HTTPS, unless
they don't care about creds being stolen or have reason to trust HTTP
(e.g. the VPN case).
5. Require that users take responsibility for configuring their trust
policies directly via their truststore.

Cheers,
Eoghan


Mime
View raw message