full-disclosure - Re: HTTP Digest Integrity: Another look, in light of recent attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 7 Jan 2010 12:15:10 +0100
From: Dan Kaminsky <dan@...para.com>
To: "Timothy D. Morgan" <tmorgan@...curity.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: HTTP Digest Integrity: Another look,
	in light 	of recent attacks

On Thu, Jan 7, 2010 at 3:17 AM, Timothy D. Morgan <tmorgan@...curity.com>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
> the
> > 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
> JavaScript, but I've never taken the time to think carefully about how
> 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.


>
> Regards,
> tim
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/