Security/Features/TLS Telemetry

Please use "Edit with form" above to edit this page.

Status

TLS Telemetry
Stage	Landed
Status	Complete
Release target	Firefox 26
Health	OK
Status note	`

{{#set:Feature name=TLS Telemetry

|Feature stage=Landed |Feature status=Complete |Feature version=Firefox 26 |Feature health=OK |Feature status note=` }}

Team

Product manager	Brian Smith
Directly Responsible Individual	David Chan
Lead engineer	Brian Smith
Security lead	David Chan
Privacy lead	Sid Stamm
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	Brandon Sterne

{{#set:Feature product manager=Brian Smith

|Feature feature manager=David Chan |Feature lead engineer=Brian Smith |Feature security lead=David Chan |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Brandon Sterne }}

Open issues/risks

NSS currently doesn't expose information exchanged during the initial client-server handshake. See bugs bug 704675 and bug 704584

We have decided to collect a smaller subset of the data in the initial feature. The study will be updated when more data is exposed through NSS.

Stage 1: Definition

1. Feature overview

The goal of this telemetry study is to collect SSL/TLS errors that Firefox users encounter during browsing. The data can be used to decide whether Firefox should support legacy / less secure protocols such as weak keys or SSLv2 .

2. Users & use cases

The target users are Firefox users.

Use Cases

• Collect ratio of SSL/TLS OK vs FAIL connections
  • This should be represented in the number of errors + version datapoints collected below
  • This is a sanity check to make sure we aren't missing some workflow No longer explicitly collecting this histogram
• Collect cipher suites exchanged during handshake and negotiated cipher
  • Ciphersuites in PSM are ordered in decreasing preference. The SSL/TLS specification says that the client should send their supported ciphersuites in this order. The server then choose the most preferred ciphersuite that it also supports.
  • Collecting this data allows us to make decisions whether to remove certain weaker ciphers from our supported list.
• Collect SSL/TLS version
  • This is the version of SSL/TLS that ends up being negotiated. This doesn't correspond directly to whether the client has the preference for "Use SSL 3.0" or "Use TLS 1.0" enabled.
  • The resulting version may be different due to what the server supports.
• Collect certificate key strength (bits)
  • This is the server RSA public key modulus. A larger modulus is preferred
  • It would be desirable to disable weak certificates. bug 360126
• Collect SSL/TLS certificate related errors
  • We ignore NSS protocol errors We are now collecting all returned errors
  • We will collect the exact error that NSS returns to PSM if it is a certificate error.
  • For some of these errors, we will collect additional information.
  • This will allow us to determine what type of error our users are encountering most frequently in the wild.
  • Some errors such as self-signed CA may be more worrisome than others such as invalid certificate time.
• Collect count of TLS intolerant websites
  • Some websites do not implement the SSL protocol correctly and there is special handling for those cases.
  • In those cases, Firefox tries to reconnect but downgrading from TLS 1.0 to SSL 3.0
  • It may be possible to remove this downgrading if the number of TLS intolerant sites is small enough.

3. Dependencies

N/A

4. Requirements

1. Collect type of SSL/TLS error
2. Collect information about strength of negotiated channel

Non-goals

The study is not designed to assert anything about the underlying security of the SSL/TLS protocol.

Stage 2: Design

5. Functional specification

All SSL/TLS certificate related errors will be logged. Certain more specific errors such as domain mismatch, revoked certificate, untrusted issuer, etc will be collected as well. We will also collect the number of OK vs FAIL secure connections. These histograms will used to address requirement 1 (SSL/TLS errors).

We will determine the strength of the negotiated channel by collecting: negotiated ciphersuite, SSL/TLS version, server public key bits, whether the server is TLS intolerant.

6. User experience design

The study uses the default Telemetry UI/UX. The only code changes are to add more probes. Histogram names / descriptions may need to be localized.

Stage 3: Planning

7. Implementation plan

• Determine best areas of code to insert Telemetry probes
• Add probes as needed

8. Reviews

Security review

Security team has decided that the feature does not require an in-depth review

Privacy review

Review is in progress. Please see review page

Localization review

`

Accessibility

`

Quality Assurance review

No specific testing is needed for this feature

Operations review

No operations changes need to be performed for this review

Stage 4: Development

9. Implementation

Implementation bug

• bug 707275

• Data collected is noted on the privacy review page

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=NSS currently doesn't expose information exchanged during the initial client-server handshake. See bugs bug 704675 and bug 704584

We have decided to collect a smaller subset of the data in the initial feature. The study will be updated when more data is exposed through NSS. |Feature overview=The goal of this telemetry study is to collect SSL/TLS errors that Firefox users encounter during browsing. The data can be used to decide whether Firefox should support legacy / less secure protocols such as weak keys or SSLv2 . |Feature users and use cases=The target users are Firefox users.

Use Cases

• Collect ratio of SSL/TLS OK vs FAIL connections
  • This should be represented in the number of errors + version datapoints collected below
  • This is a sanity check to make sure we aren't missing some workflow No longer explicitly collecting this histogram
• Collect cipher suites exchanged during handshake and negotiated cipher
  • Ciphersuites in PSM are ordered in decreasing preference. The SSL/TLS specification says that the client should send their supported ciphersuites in this order. The server then choose the most preferred ciphersuite that it also supports.
  • Collecting this data allows us to make decisions whether to remove certain weaker ciphers from our supported list.
• Collect SSL/TLS version
  • This is the version of SSL/TLS that ends up being negotiated. This doesn't correspond directly to whether the client has the preference for "Use SSL 3.0" or "Use TLS 1.0" enabled.
  • The resulting version may be different due to what the server supports.
• Collect certificate key strength (bits)
  • This is the server RSA public key modulus. A larger modulus is preferred
  • It would be desirable to disable weak certificates. bug 360126
• Collect SSL/TLS certificate related errors
  • We ignore NSS protocol errors We are now collecting all returned errors
  • We will collect the exact error that NSS returns to PSM if it is a certificate error.
  • For some of these errors, we will collect additional information.
  • This will allow us to determine what type of error our users are encountering most frequently in the wild.
  • Some errors such as self-signed CA may be more worrisome than others such as invalid certificate time.
• Collect count of TLS intolerant websites
  • Some websites do not implement the SSL protocol correctly and there is special handling for those cases.
  • In those cases, Firefox tries to reconnect but downgrading from TLS 1.0 to SSL 3.0
  • It may be possible to remove this downgrading if the number of TLS intolerant sites is small enough.

|Feature dependencies=N/A |Feature requirements=# Collect type of SSL/TLS error

1. Collect information about strength of negotiated channel

|Feature non-goals=The study is not designed to assert anything about the underlying security of the SSL/TLS protocol. |Feature functional spec=All SSL/TLS certificate related errors will be logged. Certain more specific errors such as domain mismatch, revoked certificate, untrusted issuer, etc will be collected as well. We will also collect the number of OK vs FAIL secure connections. These histograms will used to address requirement 1 (SSL/TLS errors).

We will determine the strength of the negotiated channel by collecting: negotiated ciphersuite, SSL/TLS version, server public key bits, whether the server is TLS intolerant. |Feature ux design=The study uses the default Telemetry UI/UX. The only code changes are to add more probes. Histogram names / descriptions may need to be localized. |Feature implementation plan=* Determine best areas of code to insert Telemetry probes

• Add probes as needed

|Feature security review=Security team has decided that the feature does not require an in-depth review |Feature privacy review=Review is in progress. Please see review page |Feature localization review=` |Feature accessibility review=` |Feature qa review=No specific testing is needed for this feature |Feature operations review=No operations changes need to be performed for this review |Feature implementation notes=Implementation bug

• bug 707275

• Data collected is noted on the privacy review page

|Feature landing criteria=` }}

Feature details

Priority	P2
Rank	999
Theme / Goal	TLS Hardening
Roadmap	Security
Secondary roadmap	`
Feature list	Platform
Project	`
Engineering team	Security

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=TLS Hardening |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=Security }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	sec-review-unnecessary	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-unnecessary |Feature security health=OK |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}