Security/Features/TLS Telemetry

Status

Team

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

`

Feature details

Team status notes