Add a pref to disable SSL Session cache (Disable sending session IDs and sending session tickets)

RESOLVED FIXED in mozilla35

Status

()

RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: mikeperry, Assigned: arthur)

Tracking

(Blocks: 1 bug)

unspecified
mozilla35
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tor])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

5 years ago
There is a pref to disable TLS session tickets (security.enable_tls_session_tickets), but there is no corresponding pref for SSL3 Session IDs.

In Tor Browser, we simply patched NSS directly to hardcode them to off, as we do not want to enable the additional tracking facilitated by these identifiers.

This patch is against FF24ESR.
Assignee: nobody → nobody
Component: General → Libraries
Product: Firefox → NSS
Mike: are you working with anyone in Mozilla to help shepherd these TOR patches through? If not, you'll have much better success by getting bugs files in the right components and requesting explicit review/feedback/needinfo from an appropriate peer.
(In reply to Mike Perry from comment #0)
> There is a pref to disable TLS session tickets
> (security.enable_tls_session_tickets),

That pref was removed. See bug 917049.
Assignee: nobody → nobody
Component: Libraries → Security: PSM
OS: Windows 7 → All
Product: NSS → Core
Hardware: x86 → All
See Also: → bug 917049
Summary: Add a pref to disable SSL Session IDs → Add a pref to disable SSL Session cache (Disable sending session IDs and sending session tickets)
Whiteboard: [tor]
(Assignee)

Comment 3

5 years ago
I'm posting a patch that provides a pref for disabling both SSL session IDs and session tickets. I hope it matches what was envisioned in the comment at https://bugzilla.mozilla.org/show_bug.cgi?id=917049#c10
Attachment #8485269 - Flags: review+
(Assignee)

Updated

5 years ago
Attachment #8485269 - Flags: review+ → review?(dkeeler)
Comment on attachment 8485269 [details] [diff] [review]
Add a pref to disable trackable SSL session identifiers

Review of attachment 8485269 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable. I'd like to see the final version, so r- for now.

::: netwerk/base/public/security-prefs.js
@@ +17,5 @@
>  pref("security.ssl.enable_npn", true);
>  pref("security.ssl.enable_alpn", true);
> +// If set to true, disables sending SSL3 Session IDs and TLS Session Tickets,
> +// to prevent session tracking:
> +pref("security.ssl.disable_session_identifiers", false);

Let's not put this here - that way, it's a hidden pref that nobody will enable by accident and slow down their TLS connections.

::: security/manager/ssl/src/nsNSSComponent.cpp
@@ +701,4 @@
>  static const bool FALSE_START_ENABLED_DEFAULT = true;
>  static const bool NPN_ENABLED_DEFAULT = true;
>  static const bool ALPN_ENABLED_DEFAULT = false;
> +static const bool DISABLE_SESSION_IDENTIFIERS_DEFAULT = false;

Since this is only used once, we don't need to have a separate variable for it - just pass false to Preferences::GetBool

@@ +703,5 @@
>  static const bool ALPN_ENABLED_DEFAULT = false;
> +static const bool DISABLE_SESSION_IDENTIFIERS_DEFAULT = false;
> +
> +static void
> +UpdateSessionIdentifiersDefaults()

How about something like "ConfigureTLSSessionIdentifiers"?
Attachment #8485269 - Flags: review?(dkeeler) → review-
mcmanus, are there other TLS features that are enabled by default that would allow tracking users? (The aim of this bug is to add an option that would prevent that sort of thing.)
Flags: needinfo?(mcmanus)
(Assignee)

Comment 6

5 years ago
Thanks for the review. Here's a corrected version of the patch. I agree it would also be good to disable any other trackable aspects of SSL/TLS with this pref, if possible.
Attachment #8485269 - Attachment is obsolete: true
Attachment #8486065 - Flags: review?(dkeeler)
(In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> mcmanus, are there other TLS features that are enabled by default that would
> allow tracking users? (The aim of this bug is to add an option that would
> prevent that sort of thing.)

sure - at various levels of granularity. None as extreme as session tickets. Anything that keeps state, right?

some that come to mind:
* the version intolerance cache
* our false start behavior involves "have I seen this algorithm before"
* the hsts database
Flags: needinfo?(mcmanus)
(In reply to Patrick McManus [:mcmanus] from comment #7)
> (In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> > mcmanus, are there other TLS features that are enabled by default that would
> > allow tracking users? (The aim of this bug is to add an option that would
> > prevent that sort of thing.)
> 
> sure - at various levels of granularity. None as extreme as session tickets.
> Anything that keeps state, right?
> 
> some that come to mind:
> * the version intolerance cache
> * our false start behavior involves "have I seen this algorithm before"
> * the hsts database

Thanks. Those all require multiple hosts, right? (because they're basically one or two bits per host, if I understand correctly). We might need to develop some sort of quota per domain tree, but that should be in a future bug.
Comment on attachment 8486065 [details] [diff] [review]
Add a pref to disable trackable SSL session identifiers, v. 2

Review of attachment 8486065 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #8486065 - Flags: review?(dkeeler) → review+
> 
> Thanks. Those all require multiple hosts, right? (because they're basically
> one or two bits per host, if I understand correctly). We might need to
> develop some sort of quota per domain tree, but that should be in a future
> bug.

They are only a bit or two each.. opinions differ on whether or not that's impt or tractable :)

Comment 11

5 years ago
(In reply to Patrick McManus [:mcmanus] from comment #10)
> > 
> > Thanks. Those all require multiple hosts, right? (because they're basically
> > one or two bits per host, if I understand correctly). We might need to
> > develop some sort of quota per domain tree, but that should be in a future
> > bug.
> 
> They are only a bit or two each..

Really? What about https://web.archive.org/web/20121031023419/http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-HSTS-Persistence-and-Privacy.html?
Assignee: nobody → arthuredelstein
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: checkin-needed
Hi, could you provide link (just to make sure everything works), thanks!
Keywords: checkin-needed

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/85fdc596e257
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35

Comment 16

4 years ago
Which Firefox version is this change going to be in? Target Milestone says "mozilla35", but I don't see the "security.ssl.disable_session_identifiers" parameter on Firefox 37.0.1 on Linux Mint (Ubuntu based). Or is it not present by default and needs to be added manually?

Thanks in advance.
(Assignee)

Comment 17

4 years ago
(In reply to Joe Smith from comment #16)
> Which Firefox version is this change going to be in? Target Milestone says
> "mozilla35", but I don't see the "security.ssl.disable_session_identifiers"
> parameter on Firefox 37.0.1 on Linux Mint (Ubuntu based). Or is it not
> present by default and needs to be added manually?
> 
> Thanks in advance.

It's not present by default and you need to add it manually (see comment #4).
Blocks: 1260929
You need to log in before you can comment on or make changes to this bug.