Re: connectEnd and SSL handshake

On Wed, Dec 1, 2010 at 1:50 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> 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?


   It's unfortunate. But in case of plain HTTP, connectionStart/End will be
close to the RTT between the user and the server.
That should work fine for most of the servers.




>
>
>  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).


    Thanks. Done in the latest draft.

cheers,
Zhiheng


>
>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>