Closed
Bug 1351806
Opened 8 years ago
Closed 8 years ago
STS hostname data structures are rather large
Categories
(Core :: Security: PSM, enhancement)
Core
Security: PSM
Tracking
()
RESOLVED
DUPLICATE
of bug 1382001
| Tracking | Status | |
|---|---|---|
| firefox55 | --- | affected |
People
(Reporter: froydnj, Unassigned)
Details
The data structures for STS hostname lookup take up ~340K, regardless of platform. AFAICT, these structures are permitted to grow without bound, given that we take automatic updates to the STS list.
They are the largest single (static) data structure that exist inside libxul.
Do we have any plans for capping the size of this list, or filtering it in any way? Skimming through the list seems to indicate that it's a lot of personal domains...is the list really buying us that much in terms of added security?
Flags: needinfo?(dkeeler)
Comment 1•8 years ago
|
||
This is a bit tricky. The list addresses a shortcoming in HSTS in that when we connect to a site for the first time, we don't know if we should only use a secure connection (in the future, it would be nice if this were the default, but we're a long way off from that). I don't think we want to be in the position of deciding which sites are important enough to be on this list.
I'm certainly open to exploring how to make the list take up less space. Also, I believe we're moving towards shipping this kind of security information over kinto. When that infrastructure is in place, we may be able to trim the compiled-in list to browser-critical hosts (e.g. updates, the kinto server, any host we connect to on startup) and then download the full list over kinto. Mark, am I correct in that's the plan?
Flags: needinfo?(dkeeler) → needinfo?(mgoodwin)
Comment 2•8 years ago
|
||
(In reply to David Keeler [:keeler] (use needinfo?) from comment #1)
> I'm certainly open to exploring how to make the list take up less space.
> Also, I believe we're moving towards shipping this kind of security
> information over kinto. When that infrastructure is in place, we may be able
> to trim the compiled-in list to browser-critical hosts (e.g. updates, the
> kinto server, any host we connect to on startup) and then download the full
> list over kinto. Mark, am I correct in that's the plan?
Not currently, but the plan could change if that's the right thing to do. Currently, the plan is to ship updates to the list via Kinto (so we'd have the full 340K shipped initially, with deltas via kinto) - but I'd be open to the other approach if this is the right thing to do.
Flags: needinfo?(mgoodwin)
Comment 3•8 years ago
|
||
I'm optimistic bug 1382001 will address this, but we can reopen if it's not sufficient.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•