On Sunday 01 August 2010 11:14:51 Ximin Luo wrote: > I agree with this view too. We just don't have enough developer time to worry > about this *and* progress with more productive features. Even Tor, which has > many times more resources than us, don't worry about swap/etc/whatever.
Tor is written in C. So is GPG. GPG locks pages in memory to ensure keys are not leaked to disk. As have C programs doing encryption since a very long time ago. THIS IS NOT POSSIBLE IN JAVA. This is a clear technical defficiency that should have a technical solution. The only way we can avoid such leaks is to recommend people either encrypt or turn off swap, or to offer to do it for them. Since on recent Windows versions we can do this, it would be a good idea to offer the possibility in the installer, or offer instructions on how to do it if/when the user chooses a higher security level in the first time wizard. Secondly, turning on swap encryption on recent windows is *very* easy. If it works. It's a single command. I propose that, *if* the user sets physical security above LOW, we have the system tray applet (which will connect via FCP to pick up notifications) pop up a dialog box offering to encrypt the swap file. It should check whether it is already encrypted first. > > The theoretical scope of freenet design is to have secure and anonymous > storage > and transfer. (Everything unknown to you) is encrypted so that you can have > plausible deniability if your machine gets seized and examined. There is no > difference between running a node, and never using it to actually obtain > stuff > for yourself - you're still providing "the freenet service" to others. We have a great many mechanisms that theoretically are out of scope but practically make a useful difference for users, especially for non-technical users, to avoid unnecessary risk and exposure. For example: - We tell browsers not to cache pages. (This should largely prevent sensitive freesites from ever hitting disk, ignoring swap issues) - We try to open an incognito mode browser if possible. (The user should clear his browser history or use a separate browser) - We filter HTML. (The user should set up a VM which only has access to Fproxy!) - We encrypt node.db4o, if the user wants a higher physical seclevel. (This is already implemented, the issue at the moment is that we need to upgrade the encryption before implementing auto-backups) > > However, once you access data in a readable form, you've decrypted it. This > is > just like accessing anything on any other service (looking at web pages, > reading email, etc). Your computer is going to cache it, leaving traces of > what > you've done. This is another well established technical problem with a set of well established technical solutions. Sensitive sites set no-cache headers, so does Freenet. Apart from the swap hole, this is largely a solved problem, at least in principle. > > In this scenario, it's up to the individual what level of security they want. > It can only be up to the individual - only they know what they've accessed, > and > can get in trouble for. Security that you don't need is just a waste of time > and resources. Which is why we ask them. Right now, and will continue to do so. > Also, if we spend this much time on an issue out of our scope > we're effectively DDoSing our own development time. It's hardly a DDoS. > > So yes we should just drop "physical security". To do it properly we'll have > to > fuck with parts of people's machines we really shouldn't be fucking with; and > if they are that paranoid (I am) they should just encrypt their entire disks, > which will cover non-freenet stuff too. I strongly disagree. We do not have to do any low-level anything. We can make Freenet relatively secure out of the box without a huge effort, and without unreasonable layer violations. This significantly improves the security:usability combination for new users (security and usability are inseparable). All the work on physical security - encryption of node.db4o in particular - resulted directly from my discussions with the Nedanet people. In such places as Iran, by far the most likely attack is seizing people's computers and looking at what they have been downloading. (Freenet isn't actually suitable for Iran in general due to poor broadband but that's a discussion for another day...). Obviously the most critical issue was the The Register attack i.e. caching stuff in the datastore that really shouldn't be cached in the datastore. I fixed this by not caching locally requested content in the datastore, but this resulted in more requests for such content going to the network, which could conceivably be a risk on the network level; so I created the client-cache. The client-cache only caches stuff requested locally, and there is no mechanism to ensure that stuff you no longer request is instantly removed from the client-cache. This is also true of the downloads database: Space is reused but as far as I know, even if there are no bugs causing left-over URL's etc (which there have been on many occasions), so in both cases there is a good chance that incriminating data could be recovered. Hence the physical security settings were introduced, along with master.keys and encryption of node.db4o and the client cache. > > Obviously, we should try to make it clear (like Tor[1]) what Freenet DOES and > DOES NOT do. "the freenet service" only tries to provide an > anonymous/DDoS-resistant insert/request service, it doesn't try to protect > you > after you actually *get* that data. > > X > > [1] http://www.torproject.org/download.html.en#Warning If Tor doesn't use locked pages I'd be very surprised. Even if it doesn't, GPG does. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100802/e95266a4/attachment.pgp>
