W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Authentication over HTTP

From: Adrien W. de Croy <adrien@qbik.com>
Date: Mon, 15 Jul 2013 23:20:52 +0000
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>, "M Stefan" <mstefanro@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emd15876f8-ce60-4304-a159-266e2aa9711f@bodybag>

for browser-based reverse proxy or serving I agree that current HTTP 
auth is next to useless.

However for forward proxying it is still useful and necessary.  And 
given we don't have TLS to proxy, then HTTP is the only possible layer 
for this.


------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: "M Stefan" <mstefanro@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 15/07/2013 12:02:39 p.m.
Subject: Re: Authentication over HTTP
>In message <51E330F5.6050100@gmail.com>, M Stefan writes:
>>Nowadays, the only serious way of providing secure communications over
>>HTTP is using HTTPS. Many web hosts are reluctant to using it because
>>of the extra computational burden [...]
>I agree with you (if I understood your message right) that the
>current HTTP/1.1 authentication/password stuff is fundamentally
>useless and should not be carried into HTTP/2.0.
>I think HTTP/2.0 should make partial protection possible, (See my
>previous message :-) exactly so that the cost can be kept down.
>But I think that it would be a big mistake to involved HTTP/2.0 in
>the actual protection, to any extent further than to mark what needs
>protection and what does not.
>Authentication should happen either in the encrypting transport
>which moves HTTP/2.0 across (as in certificates and assymetric crypto)
>or in the application transported inside HTTP/2.0 (as in most web-site
>login dialogs), but HTTP/2.0 itself should not get involved: It
>is the wrong layer.
>Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG | TCP/IP since RFC 956
>FreeBSD committer | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by 
Received on Monday, 15 July 2013 23:21:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC