Re: Semantics of HTTPS

On 2012/09/13 19:23, Willy Tarreau wrote:
> On Thu, Sep 13, 2012 at 09:30:31AM +0100, Stephen Farrell wrote:
>>
>> Hi Willy,
>>
>> On 09/13/2012 06:47 AM, Willy Tarreau wrote:
>>> Hi Mark,
>>>
>>> On Thu, Sep 13, 2012 at 03:06:24PM +1000, Mark Nottingham wrote:
>>>> I haven't seen any more discussion of this.
>>>>
>>>> Being that both the TLS WG Chair and at least one security AD have both
>>>> unambiguously said that it should be considered an e2e protocol (please
>>>> correct if I'm wrong), we return to the original question --
>>>>
>>>> Should we state that the HTTPS URI scheme implies end-to-end security (i.e.,
>>>> between the user-agent and the origin server)?
>>>
>>> I have thought a bit about the arguments made in favor of this and my
>>> opinion has evolved on the subject. I think that we should probably keep
>>> the https scheme as "end-to-end" so that the user is sure about this,
>>> but in this case we'd need another scheme for the https from proxy to
>>
>> Do you mean another URI scheme?
>
> Yes, which would be just for the browser, not for web sites.

I'm not exactly sure I understand this. If the browser shows it in the 
address bar, then users will copy it, and use it on other occasions. 
Also, web developers will copy it and use it. Of course, most of that 
would be accidental, not on purpose.

On the other hand, I can't see much use in using it on purpose. Surely, 
no web site in their right mind would want to use it, because it 
essentially says "we are secure, but don't really think we need to be". 
Intranet applications wouldn't need to use it either, because for their 
own stuff, companies have easier ways to verify that there are no 
viruses,... around.

So all in all, an URI scheme doesn't seem to fit here. To me, it seems 
more like a case for a separate indication in the browser (a lock with a 
different color or a half-broken lock or some such, better ideas welcome).

Regards,   Martin.

Received on Thursday, 13 September 2012 10:40:16 UTC