This is very grave problem that especially affects Tor users.
> In a nutshell, the vulnerability allows a blind off-path attacker to infer if any two arbitrary hosts on the Internet are communicating using a TCP connection. Further, if the connection is present, such an off-path attacker can also infer the TCP sequence numbers in use, from both sides of the connection; this in turn allows the attacker to cause connection termination and perform data injection attacks. We illustrate how the attack can be leveraged to disrupt or degrade the privacy guarantees of an anonymity network such as Tor, and perform web connection hijacking. Through extensive experiments, we show that the attack is fast and reliable. On average, it takes about 40 to 60 seconds to finish and the success rate is 88% to 97%.
> We emphasize that the attack can be carried out by a purely off-path attacker without running malicious code on the communicating client or server. This can have serious implications on the security and privacy of the Internet at large.
The authors say this vulnerability was introduced in RFC 5961 [1], implemented
in Linux kernel 3.6 from late 2012. As well as being able to infer if there is
an active connection between two arbitrary IPs, a practical DoS attack on Tor
connections is demonstrated by injecting reset packets. The attack can also be
used to disrupt connections between relay nodes to force traffic through exit
nodes controlled by the attacker.
While apparently fixed in kernel 4.7, the vast majority of Tor nodes and Linux
endusers are likely to be using older vulnerable versions, as 4.7 was only
released July 24 of this year [2].
This is not about integrating Tor into Firefox, rather it is about incorporating switches into Firefox for the security/privacy improvements that have been made in Tor Browser.
You can think of Tor Browser as a better Firefox that just happens to include built-in support for the Tor network. Tor Browser is security-hardened and makes numerous changes to improve privacy, such as reducing fingerprinting opportunities and attempting to isolate browser state by URL bar domain. The Design and Implementation of the Tor Browser doc [1] is an excellent read on the approach taken.
Since it is trivial to configure Tor Browser to run on the "normal internet" (not on the Tor network), there may not be much reason to run Firefox instead of Tor Browser. There is one possible reason: not all security fixes may be backported to Firefox Extended Support Releases (ESR). According to the ESR FAQ [2], only "high-risk/high-impact security vulnerabilities" will be backported to ESRs. So clearly some security vulnerabilties that are not considered by Mozilla to be high-risk/high-impact may be left unfixed in ESRs. Additionally, it seems likely that not all bugs that are security vulnerabilities will be correctly identified as such. Many exploitable bugs that can lead to code execution are often published as only stability or denial of service bugs by project maintainers - so-called "Denial of Reality" vulnerabilities [3]. I think this is what Daniel Veditz is alluding to when he says "Mozilla leadership has already decided to help Tor move toward being able to build off a Release Firefox rather than an ESR--it's safer for our users."
So in that sense, it is great news that Mozilla is working to make it easier for Tor Browser to be based on top of Release Firefox instead of an ESR. Even if all Tor Browser patches make it in to Firefox, I imagine it will be a good deal of work to get out-of-the-box Firefox to behave like Tor Browser. And given that every six weeks, Firefox may have new features that present new attack surface, or enables new fingerprinting opportunities, it still seems like a safer bet to have Tor Browser devs vet each release, rather than constantly try to stay on top of what switches need to be flipped.
Personally I will continue to trust Tor Project to ship a browser that is configured for strong security and privacy out-of-the-box.
Reading the docs, this seems to be targeted towards personal data backups for individuals. References to photos, interactive usage, support for consumer cloud storage backends, etc.
Thus it surprises me that a tool for personal data backup on the cloud has a fair bit of community support (1651 stars on github) when the encryption features remain a vague notion after 4 years of development. Nor is there any recommended encryption workflow using an external tool.
Does our culture still find it acceptable that, in 2016, personal data, and almost certainly in many cases very sensitive private data, is being seen unencrypted by cloud providers?
I think that, while the norm is to not think twice about letting a private entity have practically unlimited access to your personal data, we as community need to focus on tools that keep an individual's data private by default.
> it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud.
I disagree. It's possible to make good use of public infrastructure without handling any important secrets on public machines. Under certain threat models, you have to assume public infrastructure is vulnerable to coercion of the providers and side-channel attacks from co-tenants. As we are beginning to see, providers have the tools and processes to comply with coercive demands (RAM/disk dumps) and co-tenants can feasibly succeed in obtaining secrets via side-channel attacks.
Under models like this, public infrastructure is still useful for storing and routing encrypted information, enabling NAT traversal, and distributing signed material which can be authenticated at the client.
Fantastic! While not as bulletproof as receiving the hash out-of-band for a critical resource, this is better than verifying against a hash received from the same origin as the resource, and far better than no hash verification at all. And because this is FOSS, we can be gain some protection against the compromise or MITM of a single, central hash-archive server when many of them are deployed by distinct entities on different public domains.
One request: there are lots of users who would be well-served by a way to compute hashes in-browser via the WebCryptoAPI [1]. Would you consider accepting this feature into hash-archive? For users who aren't able to install or have difficulty using a hash calculator locally, this would enable verification of downloaded files in a one-stop online workflow.
Etherpad (http://etherpad.org) is an OSS cloud document editor app.
It has a pretty reasonable set of formatting, revision, and
import/export options out of the box, and also a large set of plugins
(http://static.etherpad.org/plugins.html). Supported import formats are
plain, doc, docx, odt, rtf, and html.
There's a demo on the homepage that runs on Sandstorm.io, so you can
very easily self-host or use managed hosting via the Sandstorm framework (https://sandstorm.io).
EtherCalc (https://ethercalc.net/, not related to Etherpad) is an OSS
cloud spreadsheet app. Demo on homepage, also available on Sandstorm.
Sandstorm has several other office/productivity apps, and in my
opinion, is the clearest route to an effective OSS cloud office suite.
I am hopeful for LO Online, but tile-based rendering seems like a bad
choice. I have no doubt it will be packaged for Sandstorm at some
point, but Etherpad is looking much better as of now.
This looks great! From the screenshots, it looks like a nice, clean, thoughtful design. I would love to use it if I could run it myself. The app needs some pretty private data, and I would hate to lose it all in the middle of a job hunt if you decided to shutter it.
Would you consider making it OSS? I would happily donate toward that end. I can also offer to help package this app for the Sandstorm.io platform (OSS, https://sandstorm.io). Sandstorm enables one-click installs of server apps on self-hosted and managed servers, with great security and privacy out of the box. It will also serve as a marketing platform and channel for future donations for your app. Since Job Search Sanity is basically a private single-user cloud app, packaging it for Sandstorm should be very straightforward.
This was interesting at first glance - it's very approachable in it's
simplicity, and I can see it having an impact on the typical Google app user.
Something like this could be a useful resource for people who may not think
about the consequences of their dependence on proprietary cloud apps. I think
most people don't think about the fact that Google (or any other cloud app
provider) can and does shutdown their apps or significantly change the Terms of
Service, usually with very limited options to migrate their data elsewhere.
FOSS cloud apps aren't subject to arbitrary shutdowns or unwelcome changes to
the ToS. This is a huge, obvious advantage that most cloud app users don't
realize. I think supporters of FOSS cloud apps should have something concrete
to point to that shows the fragility of proprietary cloud apps.
However, I would not use this website as a reference for the following reasons:
- No citations! It reads as if it is pure opinion without any citations.
- It's hard to find evidence for some of the claims. Google+ shutting down? Is
that pure speculation?
- No place to discuss app status in the app. Comments or a wiki should be
offered.
- Closed source, no way to send pull requests for updates/corrections.
The page has a prominent link to the author's Patreon. This comes across as
litte more than link-bait to draw traffic to the Patreon page, and a hit-piece
on Google. The potential benefit to cloud app users gets lost.
Thanks for sharing your project. What other CLI password managers did you review, and in what ways did you want Steel to be different?
I noticed that, after being opened, the SQLite database appears to be stored on disk unencrypted, and must be manually re-encrypted with the "close" command. I think most password managers attempt to ensure that the unencrypted database is only ever in physical memory.
The interface uses pipable commands rather than an interactive shell. The reason given is so that it can integrate with other standard Unix tools. This means that the entry context must be supplied for every command, in this case by id. Another side-effect of the pipable command interface is that using the "replace" command to change the passphrase will echo the passphrase to the screen and leave that passphrase in the shell history.
The manual gives an example of piping to another utility:
> In a nutshell, the vulnerability allows a blind off-path attacker to infer if any two arbitrary hosts on the Internet are communicating using a TCP connection. Further, if the connection is present, such an off-path attacker can also infer the TCP sequence numbers in use, from both sides of the connection; this in turn allows the attacker to cause connection termination and perform data injection attacks. We illustrate how the attack can be leveraged to disrupt or degrade the privacy guarantees of an anonymity network such as Tor, and perform web connection hijacking. Through extensive experiments, we show that the attack is fast and reliable. On average, it takes about 40 to 60 seconds to finish and the success rate is 88% to 97%.
> We emphasize that the attack can be carried out by a purely off-path attacker without running malicious code on the communicating client or server. This can have serious implications on the security and privacy of the Internet at large.
The authors say this vulnerability was introduced in RFC 5961 [1], implemented in Linux kernel 3.6 from late 2012. As well as being able to infer if there is an active connection between two arbitrary IPs, a practical DoS attack on Tor connections is demonstrated by injecting reset packets. The attack can also be used to disrupt connections between relay nodes to force traffic through exit nodes controlled by the attacker.
While apparently fixed in kernel 4.7, the vast majority of Tor nodes and Linux endusers are likely to be using older vulnerable versions, as 4.7 was only released July 24 of this year [2].
[1] https://tools.ietf.org/html/rfc5961
[2] https://kernelnewbies.org/Linux_4.7