|Main Archive Page > Month Archives > full-disclosure-uk archives|
On Thu, Jan 7, 2010 at 3:17 AM, Timothy D. Morgan <firstname.lastname@example.org>wrote:
> Hi Dan,
> Thanks for taking the time to read it.
> > I haven't been wildly impressed by Digest as implemented in
> > browsers,
> Heh, no doubt. When you look into it, it's quite sad how incomplete
> and inconsistent many implementations are.
The problem is that browser developers have basically been locked out of the UI experience for some time, so there hasn't been much push to improve. Passwords in forms is the gold standard. Microsoft tried to address some of this with Cardspace...didn't work out all that well.
> > but it's a legitimate point that Digest has of at least *some* of the URI
> > embedded into it, so the TLS reneg attack can be somewhat mitigated by
> > leveraging that. Empirically though, this is going to be a big pain in
> > butt, not least of which is the dramatic change to the user experience.
> Yes, there are some serious limitations to the user interface with
> Digest auth. I have some ideas for that, which may be cooked up in a
> future paper. Stay tuned.
Happy to review when it's available.
> The level of mitigation right now against TLS renegotiation attacks
> may be contestable. In fact I'd love to hear of any exploits which
> workaround digest auth restrictions. Mostly though, I just wanted
> to throw it out there as food for thought and to give people a
> possible option if their hair was still on fire after hearing of this
> latest bug.
> What's neat about your stuff is that the GET request becomes somewhat
inviolate. What sucks is that the attacker can still play games shifting to unauthenticated content, making a Range-Request, changing the Host to something else behind the same load balancer, etc.
Ultimately, we need to fix TLS, and that's so amazingly hard.
I've seen people try to do similar challenge-response protocols in
> much benefit that provides. Hashing request bodies might be useful
> against TLS renegotiation, but I'm not sure how verification of
> responses would work. I guess with lots of AJAX and a lack of
> checking on the first response. Seems like a lot of work though.
> Well, there hasn't been a benefit before, because the right answer was
always "just use TLS". Now TLS has its issues.
You're absolutely correct that it's an impossible pain in the butt. WS-* kinda does it though already.