Problem with nonces and HTTP GET

[Breno de Medeiros]

On Fri, Jan 22, 2010 at 10:40, Peter Watkins <peterw at tux.org> wrote:
> On Fri, Jan 22, 2010 at 10:06:48AM -0800, Andrew Arnott wrote:
>> Ideally we could use POST, but avoid the browser warning that information is
>> crossing the SSL world into the non-SSL world.  This might be arguable
>> anyway since sending information can be done with GET or POST, so why warn
>> for POST and not for GET?
>
> I think you answered that in your first email -- GET is supposed to be "safe".
>
>> If we can get browsers to not warn for POST we're
>> gold.
>
> That's a huge if. And one that I wouldn't want. It would make life a little
> bit easier for OpenID users, but at what cost?

That's an interesting question. As you mentioned below, it's not clear
if there is a cost in practice anymore.

Worse, it's an example of a self-defeating practice. The warning means
that developers will avoid using POST in situations where POST would
be more appropriate than GET (after all, authn is a state-changing
operation). It's a case of the medicine being worse than the disease.

>
> I thought maybe the server could somehow indicate to the browser that
> the POST was OK, not to warn. But I think the main purpose of the https-vs-http
> warnings is to let the end user see when the servers are downgrading
> the channel security, so the end user can decide whether to allow it.
> RFC 2616, section 9.1.1:
>
>  Naturally, it is not possible to ensure that the server does not
>  generate side-effects as a result of performing a GET request; in fact,
>  some dynamic resources consider that a feature. The important
>  distinction here is that the user did not request the side-effects,
>  so therefore cannot be held accountable for them.
>
> If users are not held accountable for the side effects of GET requests,
> there's little reason to warn them about simple GET redirects.
>
> Of course a lot of the old RFCs on HTTP seem quaint when one considers
> current client-side technology, for instance how client-side scripting
> can turn a simple HTML <A> hyperlink into a trigger for a POST request.
>
> -Peter
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)