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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 6 Jan 2010 18:17:23 -0800
From: "Timothy D\. Morgan" <tmorgan@...curity.com>
To: Dan Kaminsky <dan@...para.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: HTTP Digest Integrity: Another look,
 in light of recent attacks

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.

> 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.

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.

> Ultimately, far and away the most common forms of auth are cookie based,
> with hidden variables being a close second.  In both of these the password
> is accessible to the DOM.  So the raw material is there to add an integrity
> layer to at least sensitive HTTPS transactions (everything is worthless for
> HTTP).  But an advantage of your approach is that it applies generically to
> all browser/site communication, including Javascript containers like <script
> src> and <link rel=stylesheet>.  There's no way to register a hook that gets
> triggered whenever a site hits a particular URI within a domain, to add the
> validator, in JS.  It just happens in Digest.

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.

Regards,
tim

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