71448 - (sslcached) evict (and overwrite) secure cache entries when their SSL connection is broken

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[glenn.marshall]

It is possible to access secure cache entries after their SSL connection has
been broken using techniques as simple as using the back button on the browser. 
This can occur after the user has signed out, for example (assuming everything
is in cache) and, in the submitters view, is a security breach.  

Upon breaking the SSL connection, secure cache entries should be immediately
evicted, and their locations overwritten.  Eviction should also occur if the SSL
connection times out (but this is less serious).

Retained access to secure cache items is *** NOT *** what the user would
intuitively expect - when one switches from https to http, one expects all SSL
data to be cleared out of all caches.  This is becoming a concern at various
organizations - there are a number of customer alerts out there (perhaps a
formal security alert is coming).

Note that this eviction strategy allows the benefit of caching (improved 
performance) in a secure manner without resorting to extreme measures like
disabling all caching.

A quick check thru google showed the following customer alerts (this is not a
complete list):

http://www.bmoinvestorline.com/General_Info/BrowsersSecurity.html
http://www.saskcu.com/md_tour/gen_info_security.html
http://www.firstheritage.com/personal/24hour/secureinfo.html
http://about.telus.com/legal/security.html
http://www.tradewave.com/support/jtsin/client/help/crefernc.htm

Comment 1

[gordon]

Is there anybody from the security team we should cc on this, or can we deal with 
this issue purely from the http side?

Comment 2

[Keyser Sose]

Shall I go ahead and mark this bug NEW then? or is it a known issue?

Comment 3

[Darin Fisher]

I think we can implement this in HTTP, but we'd need a way to keep track of
all cache entries created by a particular SSL connection.  This seems like a
difficult problem to solve... we'd also need to avoid conflicts between two
SSL connections contending for the same cached content.  Perhaps each SSL
connection should get its own cache session???  ugh.

Comment 4

[glenn.marshall]

if each of the ssl sessions was constrained to access the cache thru a new
method that included a unique_to_ssl_session key, it might not be that hard.  i
hasten to add that i'm not familiar with the current implementation, however.

under this suggestion, the cache logic would be expanded to, for cache entries
with ssl_session_keys, require those keys before providing the cache entry in
question (sort of like ssl itself, conceptually).  if the session key was
different or not provided, the cache would consider this item to be not in the
cache.  as a special case, if a entry was found in the cache without a
ssl_session_key, it would be returned (one can, while under ssl, obtain items
like gifs that were obtained earlier, without ssl).

this avoids the complex situation Darin refers to where the same entry is
present in multiple, concurrent ssl sessions.  in this case, there would be one
entry from each session, which is sub-optimal but rare.  i would submit that
this can be lived with.

finally, upon completion of/breaking of a ssl session, the cache needs to have a
new clean_ssl method called.  this method would be supplied the ssl_session_key
and would scrub (overwrite with something) the ssl obtained items and then
remove them.

it would seem that, for security reasons, one should avoid writing ssl obtained
entries to the disk cache.  if people disagree, and want to do this, then upon
exit and startup (in case the browser shut down with extreme prejudice/rudeness
or was killed) the browser must remove all ssl cache items (do an automatic call
for each ssl session of the clean_ssl method). a flag could be set upon orderly
exit that a startup time check is not needed.

the cache would need a fast lookup method for ssl_session keys, also.  hopefully
the current presumably fast lookup is extensible to incorporate this.

Comment 5

[Darin Fisher]

glenn: good suggestion.  all i need to do is get access to the ssl session key.

javi, bryner, jgmyers: given a pointer to nsITransportSecurityInfo is it
possible to get access to a key that would be unique to that ssl session?

Comment 6

[gordon]

Darin, can you take this?  It looks like it's more up to HTTP than the cache.  
Send it back if you need more from the cache.

Comment 7

[Gagan]

->0.9.2

Comment 8

[Darin Fisher]

OK, i've thought some more about this issue, and i'm not sure how critical it
really is.  we currently only put SSL content in the memory cache.  it is there
so users can press back in their history to see what they've done.  i think
this is very important for going back to view shopping carts and the like again.
we don't want to disable this kind of feature.  what about offline browsing?
wouldn't users complain if they were unable to browse back to see their shopping
cart after going offline?

bottom-line: mozilla is designed for a single user.  if they wish to clear away
sensitive materials then they can either clear their memory cache or quit the
browser.

that being said, i think this is really more or less a feature enhancement
rather than a critical security problem -> FUTURE.

Comment 9

[gordon]

Also, simply closing the window should make the cached ssl content inaccessible.  
Session history for the other windows wouldn't have any reference to it.

Comment 10

[glenn.marshall]

I don't think this is 0.9.2 level issue (but getting close), and I expect its a
new feature that nobody else has, possibly motivating pushing it out a bit more.

I respectfully disagree with Darin regarding people WANTING to see old SSL data,
once the SSL session has been ended, however (prior to that is ok tho).  People
like to see old data, but not old sensitive data, after they've moved on.  

In fact, I submit that they rather dislike seeing old sensitive data (assuming
they think about it; probably most people don't).  Seeing this stuff makes
people think that their sensitive data is being treated in a casual manner.  The
intuitively expected behaviour is that sensitive data is cleaned up once you
leave the secure environment (SSL).  If it is kept around, it is done so with
safeguards (re-authentication).  I would suggest that re-authentication is too
much -  nuking (overwriting) is the right thing to do.

I have trouble imagining that people would want this disabled, but if there are
folks out there who really want to see old sensitive data, how about an option
to keep it around, BUT, default off?  (I know, complexity creep...).

Expecting people to clear their memory cache to wipe this, is, in my humble
opinion, user obnoxious, and users simply won't do this.  Closing the window is
better, but why make the poor user remember - let the browser do the work.

Finally, this has nothing to do with moz being single or multi user, but rather
to do with eliminating the possibility of snooping, re-assuring security types,
security sensitive organizations like banks etc. that sensitive data is treated
seriously.  Remember that banks are actually WARNING people about this, creating
the impression that the net isn't secure etc.  This is an opportunity for
Mozilla to show leadership and, with a bit of marketing, perhaps regain some
corporate clients/get on corporate recommended lists.

It is good to know that SSL data isn't cached to disk - this closes one hole.

Comment 11

[Darin Fisher]

i understand your point, but consider this:  you browse to a secure page.  after
it loads, the connections will (in a short amount of time) be closed.  should
we at that time clear the browser window?  probably not, right?  so, how is that
different from browsing to a previously viewed secure page via session history?
in fact, browsing via session history may cause new HTTPS connections to be 
created in order to fetch content that has since expired from the memory cache.

mozilla (like all popular browsers) does not strive to completely protect the
user from someone else acting as the same user on the same system.  there are 
many MANY issues that would need to be resolved before this kind of thing could
be feasible.  this feature of the internet does not in any way impact the
security of the internet.  afterall, the sensitive content is only held in the
memory of the users computer.  IMO they are just covering their butts by making
sure that their online customers are aware of the caching feature of most web
browsers... that in fact a web browser instance will remember sensitive content
until it is shutdown.

Comment 12

[glenn.marshall]

interesting comment on clearing the display, Darin.  you're onto something.

1.  regarding clear the window after the ssl connection expires:  not a bad
idea.  personally, i think this would serve as a worthwhile emphasis of how
seriously ssl is treated by the browser.  like, the connection is gone, the fact
that ssl is being used indicates the data is sensitive, so shouldn't the
display, along with the cache be wiped?  i say yes - i like it.  (probably not
the response you expected :-) ).

this would require some sort of infrequent ping.  the implementation would have
to checked to make sure that the ping itself didn't count as activity.  or maybe
the socket itself can say if its disconnected, i don't have the api beside me.

the time to wipe the display value should be user configurable.  this way, users
who want the old way could set it to a 0 meaning never erase the screen, but the
default, i would submit, should be set to something.

*** HOWEVER ***, while this would be nice, this could be deferred:  the bulk of
the exposure is in the history, not the current page.

2. regarding going back with the back button and creating a new https session: 
no problem.  the data simply comes back, but this is based on an explicit action
by the user (and a server that agrees that this is the right thing to do; more
to the point, the server hasn't logged you off).  yes, some extra data needs to
be fetched, since the screen is blank and the cache doesn't have the ssl data
(it was wiped), but that's ok.

3.  i don't understand what other issues there are here:  it seems to me like a
simple enough situation - the users logs in with a not-written-down password,
the site is properly written (doesn't store the password in an easy to get to
place, and doesn't store it in a cookie, most particularily), the user enters
secure mode and secure communications happens.  when the secure communications
stops (either by a explicit user logout or a timeout), the data and its display
artifacts are erased.

people looking over your shoulder are clearly out of scope, as are people
sniffing the wire, sniffing the keyboard, keyboard cameras etc.

i submit that there is a general perception that the internet is kind of a wild
and wolly place for security, and, for some sites it is.  i'm simply talking
about tightening up one of the key tools (the browser) to eliminate a hole that
some organizations who are serious about security (banks) are raising alerts
about.  i submit this will, in a small way, improve the reality and perception
of internet security.  and, hopefully, score a few points for mozilla for
leadership.

i hate to be so direct, but, in my humble opinion, keeping sensitive data around
in caches, browser history, is a security hole/bug.  not a gross one, but a
reasonably sized one, big enough for organizations to post security warnings,
but not so big that CERT etc. has posted an advisory.  and expecting the user to
take action to work around it/organizations to warn about it isn't a good
approach - why not make it go away and raise the bar?

course, this is just my view. :-)

Comment 13

[Darin Fisher]

http connections over SSL do not necessarily persist.  you make the assumption
that the user is logged in for some period of time.  that is true from the
server's perspective, but it has nothing to do with the lifetime of SSL
connections, which can be very brief.

anyways, you make several interesting points for possible enhancements to the
browser.  adding RFE to summary.

Comment 14

[glenn.marshall]

absolutely correct, i was speaking too casually/mixing terminology.

more precisely, i should have said https session, with session defined by a set
of https web page accesses.  as long as the user goes from one https page to
another, this counts as a session, and the cache, browser history etc. would be
preserved.  when a http page is accessed, the https session is considered ended,
and the cleanup logic kicks in. 

and, you are right:  if the user does a wack of https stuff, and stays on a
https page and goes for lunch, what should be done?  if you can't determine the
state of the server from the browser readily, all that can be done is to timeout
after some user specifiable interval (default not never) and wipe the display
(and the cache, browser history).  this should not require any user interaction,
however.

the big issue here, however, is a user doing everything right, including go from
a https page to a http page (such as happens if you follow the typical site's
instructions and click logout), and still have the secure data accessible.   
this, in my view, should be eliminated, and is the serious part (and is what the
banks are warning about).

covering the case where the user leaves the final ssl page up is a sub-issue,
and worth nailing, in my humble opinion.  if its hard and has a bunch of stuff
not related to the main issue, i would suggest making this two bugs, with this
part later, lower priority.  

as you mention Darin, this isn't really nailed until both of these things are
covered.

Comment 15

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Here we have a 3 year old SSL/security issue, and no-one from the PSM or NSS
teams is CCed.

Comment 17

[Daniel Veditz [:dveditz]]

*** Bug 265228 has been marked as a duplicate of this bug. ***

Comment 18

[Darin Fisher]

-> default owner

Comment 19

[Patrick McManus [:mcmanus]]

web has decided that https caches are persistent if the response so dictates