Re: connectEnd and SSL handshake

On Tue, 30 Nov 2010 23:21:35 +0100, Zhiheng Wang <zhihengw@google.com>  
wrote:

> On Tue, Nov 30, 2010 at 12:17 AM, Sigbjørn Vik <sigbjorn@opera.com>  
> wrote:
>
>    If we look at it case by case.
>   - SSL: it's good to be able to distinguish tcp-handshake and ssl auth.
>   - SOCKS: tcp-handshake happens only between the user and the SOCKS  
> server.
> I don't think developer is interested in knowing that and it might bring  
> up privacy-related questions as well.
> So having connectStart/End to include the end-2-end connection time from  
> the user's perspective makes more sense to me.

Good point, SOCKS/proxy authentication is different from Web server  
authentication. The first is none of the Web server's business, while the  
latter is.

>   - HTTP proxy: tcp handshakes only between the user and the proxy. But  
> the
> browser might not know about the proxy at all so I am not sure if we  
> could do any better.

Right, also a valid point. In terms of privacy, it will be trivial for Web  
sites to tell if the user use some proxy if the
connection setup time is too low to be believable. I don't immediately see  
that as a major concern, though it is information leakage, and makes e.g.  
fingerprinting easier. There are also a number of attacks which can only  
be carried out against proxies, for instance many HTTP injection attacks.  
As even the browser itself might not know about a proxy, there isn't much  
we can do about this, except hide the information, so I then no longer  
think we need to explicitly ensure that the socket setup time is available.

This pretty much also breaks my hope that the socket setup time can be  
used as a measure for the latency. Can we implement a different latency  
check? E.g. if the page explicitly asks for performance data, then the  
browser will send a HEAD request, and return the time it took to execute,  
excluding any setup time?

>> E.g. connectionStart->socketEnd->handshakeStart->connectionEnd, where
>> socketEnd is defined as follows:
>> When the socket is fully established, before any communication across  
>> the
>> socket is started (e.g. SSL handshake or SOCKS authentication). User  
>> agents
>> which do not have easy access to this information MAY return the value  
>> of
>> connectionEnd instead. Which value a user agent returns should be  
>> documented
>> in the flag socketSeparateFromHandshake.
>>
>
>      Mostly sounds good, except that, in SOCKS, socketEnd to include  
> SOCKS
> authentication? i.e., socketEnd == connectionEnd.

Yes, drop the socketEnd entirely (per above), just add a handshakeStart in  
the cases where required (and available).

-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Wednesday, 1 December 2010 09:50:57 UTC