New issue
Advanced search Search tips

Issue 898057 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: ----



Sign in to add a comment

TLS resumption state shared between Guest-mode invocations

Reported by horsebo...@irregular-security.org, Oct 23

Issue description

PRIVACY ISSUE
TLS resumption state is shared between non-concurrent and non-overlapping Guest-mode invocations within same normal-mode invocation. This is shown by a second Guest-mode attempting and succeeding TLS resumption from the previous Guest-mode invocation.

This leaks information by allowing anyone able to observe the plaintext TLS handshakes (ISP, network eavesdroppers, destination websites, etc) to correlate that the two sessions are from the same device and potentially the same user.

Closing and reopening Chrome completely clears TLS state.

Incognito-mode is not affected. Incognito-mode invocation do not attempt to resume previous invocation's TLS connections.

VERSION:
Chrome Version: 70.0.3538.67 + stable
Operating System: Ubuntu 18.04.1 LTS w/ all packages up to date
(used to generate reproduction step screenshots)

Chrome Version: 70.0.3538.67 + stable
Operating System: macOS 10.13.6 w/ all software up-to-date

Not tested on Windows (no installations available).

REPRODUCTION STEPS
-- Start Wireshark
-- Open Chrome to normal profile
-- Open Guest Window
-- Navigate to https://www.amazon.com
-- Observe full TLS Handshake
    -- Session ID A
    -- Attachment chrome-window-1__guest-window-1.png
-- Close Guest Window
-- Wait ~1 minute
-- Open Guest Window
-- Navigate to https://www.amazon.com
-- Observe resumed TLS Handshake
    -- Session ID B
    -- Attachment chrome-window-1__guest-window-2.png
-- Close Guest Window
-- Wait ~1 minute
-- Open Guest Window
-- Navigate to https://www.amazon.com
-- Observe resumed TLS Handshake
    -- Session ID B
    -- Attachment chrome-window-1__guest-window-3.png
-- Close Guest Window
-- Close Chrome
-- Wait ~1 minute
-- Open Chrome
-- Open Guest Window
-- Navigate to https://www.amazon.com
-- Observe full TLS Handshake
    -- Session ID C
    -- chrome-window-2__guest-window-1.png

All TLS Client/Server Hellos condensed in TLS-Hellos.png
 
chrome-window-1__guest-window-1__redacted.png
116 KB View Download
chrome-window-1__guest-window-2__redacted.png
72.7 KB View Download
chrome-window-1__guest-window-3__redacted.png
71.7 KB View Download
chrome-window-2__guest-window-1__redacted.png
113 KB View Download
TLS-Hellos__redacted.png
107 KB View Download
Cc: rhalavati@chromium.org
Components: Internals>Network>SSL
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
Thank you for the report. 

+rhalavati: This is another issue with Guest mode not terminating correctly. I think the overall problem is that the profile of Guest mode isn't destroyed completely when Guest mode is left. We should fix this.
Components: UI>Browser>Profiles
Adding profiles label as Internals>Network>SSL folks mostly work on the low-level TLS bits, while it sounds like the issue here is that some aspect of profile management has gone wrong.
[davidben]:  I don't think this is something that it makes sense for the Profiles team to look into.  All state used by the network service is stored in its own file, and its own memory state, modulo data passed in to it via Mojo APIs, and I don't think we have a Mojo API for this.
Oops...I missed that incognito doesn't have this issue.  Ok, that does make this a Profiles issue.  Sorry for the noise.
Cc: -rhalavati@chromium.org
Owner: rhalavati@chromium.org
Status: Assigned (was: Untriaged)

Sign in to add a comment