IETF Logo Mail Archive

[httpapi] Re: HTTP->HTTPS redirects bad for API traffic?

Roberto Polli <robipolli@gmail.com> Wed, 04 September 2024 17:54 UTC

Return-Path: <robipolli@gmail.com>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0FC1D620E for <httpapi@ietfa.amsl.com>; Wed, 4 Sep 2024 10:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XZeac_wuwwb for <httpapi@ietfa.amsl.com>; Wed, 4 Sep 2024 10:54:22 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ED9C14CE2C for <httpapi@ietf.org>; Wed, 4 Sep 2024 10:54:22 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5343617fdddso11891986e87.0 for <httpapi@ietf.org>; Wed, 04 Sep 2024 10:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725472460; x=1726077260; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3jWJCtvTSucNk4JYgekJWofxI8ax8U+NvG+HPk37SgQ=; b=gFHp1eMbS7Wawwpk+xdSPcskYB7LYQQ4O5nA7GoRvArJxzzxaZIwJ4GKRgIrwEZvBW TLjbhnp7mL+pfanXUwaa6IU0C+xBSKmbMMtIlzIjAt5HL0KjfpzqubV0hr3sK/fNejwW 162v3+GM9lvMPR3riXXfcaAQehUXbU3STsKpq0DgRBGWov8fdrCWr2fCy+up17JFsNa/ TSFeb716U06nN7PEN8mcvtf3NvecCoX2VXvqFd2rRceTjr2rjD7FLCxF4jN987w/Ydxe YUKYJh7yAb4K4lpIOX95NCnUW0gPwEzQZqDjTr0m8Kdz0a3cdyh6t5oaIdr8BQyMaa7r DQtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725472460; x=1726077260; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3jWJCtvTSucNk4JYgekJWofxI8ax8U+NvG+HPk37SgQ=; b=gef76d0zMs+p34YQ5P1CgNjmSywXEdVp0xNtxj2eMSBIoycemnDeN+Mfyi6jciD/XP Xeb0BTXWoHSSp19CCE2Lnw7+0XWhb3hrMuRoFvjUX67+IXu5uwc5ojUNaOMrJrp1h+I6 vEaY0kpgfPKNgD1F4hlTMqREDYgajku+Wq9LxbdCeM4rzSlPIcQLFX1q4gYRdruq3tm7 zu7uBplhyrVEsTg0BldzmPORbkP+znbNmJBZc7zBbyVqCsztHY1f6thg150LbIP7uoxV bFpY0U2eJEygLRLhTHk/bFFK8Neg4aWbkjHjhhlB/jnS6OxNDxMD+58x4s4VoeeFBi9P eExw==
X-Forwarded-Encrypted: i=1; AJvYcCVvr8GP8KH0fkJAjnkF5T2tp5f7NBQ9Wfr72RMrHdz07aPs7CSsX8Al5GVlYxTAa34h1OghnkGx@ietf.org
X-Gm-Message-State: AOJu0YznwLORYDqnOFhkKtizkRp9MpLvo6O4aA2iZsWipgBWRKYLSj+J UtsjS7yjuUpoBCUAjSKNYPIpl5p9xl6qtG5ObHNQ1uV/ifJZI8X+hJTREQ4eZI158z99dqZzZ2A ssdrxrIXEmVnK3zwW/prjZVnH3rw=
X-Google-Smtp-Source: AGHT+IGleyHYUwxsit68oIxLSKf5KavwaByJ5i2+SlwBuVgVD1SmrAie5V629iCkw9SYQXrUuX8XpC2hKrig+N5QhaM=
X-Received: by 2002:a05:6512:3b14:b0:52e:9cc7:4462 with SMTP id 2adb3069b0e04-53546b1dea6mr16919574e87.11.1725472458780; Wed, 04 Sep 2024 10:54:18 -0700 (PDT)
MIME-Version: 1.0
References: <B325F560-C7F0-441B-B384-13A52E9D8543@akamai.com> <495df81d-4097-4375-a646-069a2716969a@evequefou.be> <3ac83542-d811-433f-826e-9e2ee180a4a9@app.fastmail.com> <C45C22F6-3C91-4C90-BEBD-634AFC64E72A@akamai.com> <PH0PR22MB31023277F94291AE3662A669DA952@PH0PR22MB3102.namprd22.prod.outlook.com>
In-Reply-To: <PH0PR22MB31023277F94291AE3662A669DA952@PH0PR22MB3102.namprd22.prod.outlook.com>
From: Roberto Polli <robipolli@gmail.com>
Date: Wed, 04 Sep 2024 19:54:07 +0200
Message-ID: <CAP9qbHXW9kmNBAJQcp+MW56uxkVrqeEu5c=9pbHJM0ApYOJF0g@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: MWTNXZIWZW6IYB2TV66O2KEWNUPTCJGJ
X-Message-ID-Hash: MWTNXZIWZW6IYB2TV66O2KEWNUPTCJGJ
X-MailFrom: robipolli@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Salz, Rich" <rsalz@akamai.com>, Lucas Pardue <lucas@lucaspardue.com>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "httpapi@ietf.org" <httpapi@ietf.org>, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [httpapi] Re: HTTP->HTTPS redirects bad for API traffic?
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/st0M77KdNWAKvOMaJ5__9-W05Jw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Owner: <mailto:httpapi-owner@ietf.org>
List-Post: <mailto:httpapi@ietf.org>
List-Subscribe: <mailto:httpapi-join@ietf.org>
List-Unsubscribe: <mailto:httpapi-leave@ietf.org>

On Wed, 28 Aug 2024 at 21:07, Mike Bishop <mbishop@evequefou.be> wrote:
>
> As promised, a first pass of our draft is posted as https://www.ietf.org/archive/id/draft-rsalz-httpapi-privacy-00.html. The GitHub repo is at https://github.com/richsalz/draft-rsalz-httpapi-privacy.

+1


> Rather than simply “don’t redirect,” the draft has evolved into a set of recommendations for servers which are expecting credentialed requests. Not all of them will be feasible for every server, and that’s okay – it aims to discuss some strategies that can be used to reduce the risk of credential disclosure.

IIRC this topic was discussed elsewhere too (maybe oauth?) and in
general applies to every case where some sort of server authentication
is desired or required.

Have a nice day,
R.

v2.27.6 | Report a Bug | By Email | System Status