|Release target||Firefox 26|
|Product manager||Brian Smith|
|Directly Responsible Individual||David Chan|
|Lead engineer||Brian Smith|
|Security lead||David Chan|
|Privacy lead||Sid Stamm|
|Product marketing lead||`|
|Additional members||Brandon Sterne|
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.
- 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 workflowNo 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 errorsWe 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.
- Collect type of SSL/TLS error
- Collect information about strength of negotiated channel
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
Security team has decided that the feature does not require an in-depth review
Review is in progress. Please see review page
Quality Assurance review
No specific testing is needed for this feature
No operations changes need to be performed for this review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||TLS Hardening|
Team status notes