Re: [OAUTH-WG] Request sent to http: instead of https:`

Luke Shepard <lshepard@facebook.com> Thu, 14 October 2010 02:54 UTC

Return-Path: <lshepard@facebook.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912D13A68A9 for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 19:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.22
X-Spam-Level:
X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZhLnzlLbP5h for <oauth@core3.amsl.com>; Wed, 13 Oct 2010 19:54:09 -0700 (PDT)
Received: from mx-out.facebook.com (outmail006.snc1.tfbnw.net [69.63.178.165]) by core3.amsl.com (Postfix) with ESMTP id E7F403A685B for <oauth@ietf.org>; Wed, 13 Oct 2010 19:54:08 -0700 (PDT)
Received: from [10.18.255.126] ([10.18.255.126:20491] helo=mail.thefacebook.com) by mta003.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 76/B9-26397-E1176BC4; Wed, 13 Oct 2010 19:55:27 -0700
Received: from SC-MBX05.TheFacebook.com ([169.254.4.4]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 13 Oct 2010 19:55:26 -0700
From: Luke Shepard <lshepard@facebook.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Thread-Topic: [OAUTH-WG] Request sent to http: instead of https:`
Thread-Index: AQHLawTgfxKHb6TwOkqWAIorOXsBIJM/82qAgAAEHYCAAAobgIAAHVSAgAAW2IA=
Date: Thu, 14 Oct 2010 02:55:25 +0000
Message-ID: <88E45490-742E-466F-B707-4D06680A2B4C@facebook.com>
References: <AANLkTikO0oqudUchUnpW0vSsXe0k6QKkJpxjFUU+b413@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FAAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimS-iMB3Bym968imAWicpSa6D_MSdJNW+NytD_Z@mail.gmail.com> <AANLkTimY3aOcb-SWRD6woj7Zfe4Zd3v_QWb+oE-Wx4v8@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FADC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4691FADC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <b96771cc-93f1-433e-975d-77036eb17d35>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Request sent to http: instead of https:`
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 02:54:10 -0000

In our architecture, revoking the specific token would mean revoking access to the app, which is something we don't want to do.

We just return an error message but do not invalidate the token. I think that this is fine. Since it doesn't work, it will only be encountered in development.

On Oct 13, 2010, at 6:33 PM, Eran Hammer-Lahav wrote:

> Write it, and I'll get it incorporated.
> 
> EHL
> 
>> -----Original Message-----
>> From: Breno [mailto:breno.demedeiros@gmail.com]
>> Sent: Wednesday, October 13, 2010 4:49 PM
>> To: Jeff Lindsay
>> Cc: Eran Hammer-Lahav; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:`
>> 
>> +1 for language in the spec describing how to handle this case
>> 
>> On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <progrium@twilio.com> wrote:
>>>> Hopefully you also invalidate the token (if bearer) since it was send
>>>> over an insecure channel.
>>> 
>>> Excuse my naivety, but perhaps that's worth putting in the spec?
>>> 
>>>> 
>>>> EHL
>>>> 
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>>> Behalf Of Breno
>>>>> Sent: Wednesday, October 13, 2010 11:31 AM
>>>>> To: oauth@ietf.org
>>>>> Subject: [OAUTH-WG] Request sent to http: instead of https:`
>>>>> 
>>>>> Suppose server A documents that their endpoint X is at
>>>>> https://server.example.com/x; there's no service at the
>>>>> corresponding http location for security reasons.
>>>>> 
>>>>> Client developer fatfingers URL as http://server.example.com/x
>>>>> 
>>>>> What is the correct response? I understand that this is out of
>>>>> scope for the spec, but maybe there's agreement on some guidance?
>>>>> 
>>>>> One thing one shouldn't do is serve a 302 here; it would allow
>>>>> defective clients to remain unpatched.
>>>>> 
>>>>> My preference is to simply return a bare 403 or 404 here -- after
>>>>> all the endpoint does not exist (404) or if one uses the convention
>>>>> that resources at http/https are usually identical, then http is a
>>>>> non-authorized method to access the resource (403).
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> --
>>>>> Breno de Medeiros
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Breno de Medeiros
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth