Open Bug 1523275 Opened 4 years ago Updated 6 months ago

ResourceTiming duration should be non-0 for failed DNS, TCP, SSL

Categories

(Core :: Performance, defect, P2)

64 Branch
defect

Tracking

()

Performance -

People

(Reporter: nic, Assigned: bdekoz)

References

Details

(Keywords: csectype-disclosure, sec-low)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Load a resource that is aborted due to a network error such as DNS, TCP or SSL failure.

Fetch the resource from ResourceTiming.

Example: https://nicj.net/dev/resourcetiming/error-resources.html

Actual results:

For DNS lookup failures, TCP connection failures, SSL handshake failures, etc, I would expect the startTime and respondEnd to reflect the start and end of the attempted connection, and be different from each other.

Similarly, I would expect duration to be non-0 (reflect how long it took for DNS, TCP, SSL, etc to fail).

Instead, we see that startTime == responseEnd and duration == 0.

Expected results:

On getting, the responseEnd attribute MUST return as follows:
The time immediately after the user agent receives the last byte of the response or immediately before the transport connection is closed, whichever comes first. The resource here can be received either from relevant application caches, local resources, or from the server.
The time immediately before the user agent aborts the fetch due to a network error.

https://www.w3.org/TR/resource-timing-2/#dom-performanceresourcetiming-responseend

Component: Untriaged → Networking
Product: Firefox → Core

Valentin, can you confirm this?

Flags: needinfo?(valentin.gosu)

The priority flag is not set for this bug.
:selenamarie, could you have a look please?

Flags: needinfo?(sdeckelmann)
Assignee: nobody → valentin.gosu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(sdeckelmann)
Priority: -- → P3
Whiteboard: [necko-triaged]

There is a security issue this bug creates. I will send to security@mozilla.org.

Security implication:
Documents can decipher the existence of restricted addresses, e.g. on a local network.
Example of a leak: a foreign site can try to fetch something from "intranet-host.my-company.org" - the fetch would of course fail, but if it has a duration greater than zero it would mean that that host is accessible to the user so they're probably in my-company intranet.

I opened a restricted security bug but was consulted to keep this open instead so added this comment.

Duplicate of this bug: 1741079

I've looked into this a little and it seems that the timings are already there, so it's just a matter of checking the channel status in PerformanceTimingData::SetPropertiesFromHttpChannel and dealing with it accordingly.
I haven't kept up with the resource timing spec lately, and it seems the new WPT are based on spec changes that haven't landed yet.
I'm happy to assist with necko-side changes if needed.

Assignee: valentin.gosu → nobody
Severity: normal → --
Component: Networking → Performance
Priority: P3 → --
Whiteboard: [necko-triaged]

I haven't kept up with the resource timing spec lately, and it seems the new WPT are based on spec changes that haven't landed yet.
I'm happy to assist with necko-side changes if needed.

The relevant FETCH spec changes have landed a while ago, and they are more of a clarification of what was specified in prose before in the Resource Timing spec.

Assignee: nobody → bdekoz
Severity: -- → S3
Priority: -- → P2
Whiteboard: [qf-]
Performance: --- → -
Whiteboard: [qf-]
You need to log in before you can comment on or make changes to this bug.