emily37

If anyone is wondering what the actual change was:

It looks like the npm registry used to have a certificate signed by npm's own CA, and existing npm clients only trust that CA by default, not the normal list of verisign, digicert, etc. (Trusting versign et al would defeat the point of using their own CA.) The signing key for that CA is pretty darn important, and maybe there are entities other than npm, inc who might know it (i.e. nodejitsu).

So npm, inc rolled out a new cert that looks to be signed by digicert, but existing clients don't trust Digicert until you explicitly configure them to.

I was thrown off by the SELF_SIGNED_CERT_IN_CHAIN error; I expected some error about an untrusted root CA if the problem was that npm clients didn't trust digicert, but apparently SELF_SIGNED_CERT_IN_CHAIN is what OpenSSL returns when the root CA isn't loaded.

Core dev here -- I've been doing some work here and there on framework security and I'd love to talk about the security problems you're running into, if you wouldn't mind shooting me an email sometime.

So why should the deaths of those in Boston be more prolific to me than those that died in Texas?

I don't think prolific is the word you mean, but I'll assume you meant "meaningful" or "emotional." No one is telling you how much you should care about Boston versus Texas. The point is that for those of us who are personally affected by the Boston incident, we resent being told that we should care more about the Texas incident, because it is natural that we would be more upset about the incident that personally affected us.

You can't change the words he used to misrepresent his argument because you didn't appreciate his bluntness.

The change of wording wasn't relevant to my point, I was simply trying to summarize his view. Insert "let's make an effort not to get... as an excuse for tyranny" (his actual quote) for the paraphrased quote that I used, and the point still stands: the government's supposed tendency towards tyranny should cause us to resist tyranny, not to temper our emotional reactions to the deaths of community members.

This main point is ridiculous. Our response to deaths should scale exactly proportionately to the number? I shouldn't let the death of a friend upset me disproportionately more than the death of a stranger?

A reasonable statement would have been, "Let's not let these deaths be cited as an excuse for tyranny." But what he said was more along the lines of, "Let's not be very upset about these deaths, because then they will be used as an excuse for tyranny." Why should we let the government's supposed tendency towards tyranny influence our emotional reactions to the deaths of friends and colleagues? Instead, let's react however is natural to these deaths, and at the same time ensure that we don't stand for fear-mongering and security theater.

I think you're misinterpreting my comment. I found it odd that we were advised to stay indoors all day and then told that we no longer needed to stay indoors at the exact point at which danger seemed to be more likely. My comment wasn't saying anything about my opinion as to whether or not the stay-indoors request was reasonable.

But I think it's also worth noting that the stay-indoors request was a request, as far as I know. Every notification that I received was something along the lines of people being asked to stay indoors with the doors locked, and I know people who chose to go outdoors before the request was lifted. The city shut down because people chose to honor the request out of confidence in the judgement and good intentions of the police. I personally chose to stay indoors because I thought the suspect was probably wandering around on foot in the Watertown/Cambridge area and I thought the inconvenience of staying inside for a day outweighed the risk of running into him.

I really don't see what this has to do with the Boston bombing or people's reactions to the events of today. I took a different argument to the Holocaust extreme in another comment and it applies just as well here: why should we be "bent out of shape" today about plant safety when genocide kills millions times more people?

I heard/read that for homes with inhabitants present, the inhabitants were asked if they would like their homes searched.

I'm not sure if they searched empty homes, but if they did, then they probably believed it to be exigent circumstances.

I thought it was really odd that they told people they could go about their business after completing the Watertown search without finding him. It seemed to me at that point the probability of us being injured had just gone up. However, lifting the stay-indoors request turned out to be crucial, because a man spotted the blood on the boat only after going outside for the first time all day.

On the other hand, if they had simply expanded the search area block by block without lifting the stay-indoors request, then they probably would have found him quickly with less risk to Watertown residents. In any case, I agree that it's important for the governments involved to evaluate what could have been done better.

Not to mention inconsistent with his own reactions. I don't think rms spent all day today mourning the Holocaust or the fallen soldiers of the Civil War.

The feed is no longer working for me, maybe too much traffic? Does anyone know of a live transcript?

Maybe. Also based on a photo of the crime scene that was sent out, it looks the officer was shot right outside Stata, so the robber could have been running through campus.

It sounds like the suspect fled in an unknown direction.

Also might have been unrelated incidents... Scanner traffic just reported shooting in Stata, and I don't know why a 7-11 robber would go inside Stata.

"There was a shooting at 32 Vassar St... No suspect description... No direction of flight..." MIT officer was shot and weapon stolen, I think they said the weapon was recovered. Officer is at MGH. Witness in lobby of Stata saw man in cowboy hat.

(All that on the police scanner in the last minute or so)

Just heard on the police scanner that it was an armed robbery at the 7-11.

In a similar vein, Usenix Security 2012 had a session called "The Brain" with these two papers: https://www.usenix.org/conference/usenixsecurity12/neuroscie... https://www.usenix.org/conference/usenixsecurity12/feasibili...

The first is only slightly related to this article; it uses implicit learning to train users to authenticate with secrets that they cannot recall consciously (and therefore can't be coerced into revealing).

The second is about recovering secret information from brain-computer interfaces, and though this seems very relevant to the proposal of authenticating via "passthoughts", neither of these papers seem to cite each other.

(The Berkeley paper is at http://www.kisc.meiji.ac.jp/~ethicj/USEC13/submissions/usec1...)

Yes, I would hope that the author wouldn't include "sausage party" in a letter to her real niece. :) So let me rephrase: I don't see the point in making broad statements about the presence of discrimination in our field, because these statements will drive away people who might have had perfectly satisfying careers in tech completely unhampered by discrimination. In my experience, constantly being made aware of the gender imbalance has been much more damaging than any actual gender discrimination. (Though of course I'm sure many other members of underrepresented groups have not been as lucky.)

Well said. If I had read something like this when I was eight years old, I probably would have almost immediately backtracked and started looking for something else to do with my life. The author could instead tell her niece that being a game developer sounds like fun, and then help her deal with any discrimination as it comes up, if it comes up at all. But to start off a person's career with the message that she is going to be discriminated against, that she is going to be at a disadvantage, that she should watch out for all those people trying to drag her down... that's just sabotage.

Related: Mozilla's sameDomain proposal https://bugzilla.mozilla.org/show_bug.cgi?id=795346

Some research browser architectures like Atlantis (http://research.microsoft.com/pubs/154698/Atlantis-SOSP.pdf) go the opposite extreme, where cookies are never sent unless their domain matches the initiating origin. In the case of Atlantis, the reason they have to go this route is somewhat messy: their microkernel architecture exposes a network interface to webpages, and the network interface has no way to differentiate between a request initiated by XHR or by an img/script/etc., so the network interface cannot send cookies with any cross-origin requests, or else it risks exposing private data via XHR.

I wonder if it would be useful to see something more flexible than the current standard, sameDomain, or disallowing all cross-origin cookies. When you set a cookie, maybe it would be nice to be able to specify which origins are authorized to send requests with that cookie.

It's a good question, discussed a bit in the PETS paper: https://crypto.stanford.edu/flashproxy/flashproxy.pdf (section 6). The short answer is that communicating a small amount of information outside of the censored region to a blocked facilitator is an easier problem than full connectivity.

The plan is to first nail down this low-level API, and then specify a high-level interface wrapping the low-level one that makes it much easier for most developers to get things right.

http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug...

They did, but it seems that those certificates had some extensions that made the code-signing attack difficult to carry out on some versions of Windows, so the collisions were used to generate certs without those extensions. (I read this at http://blog.cryptographyengineering.com/2012/06/flame-certif...)

Rivest's class is usually described as the "applied crypto" class (I haven't taken it, this is just what I've heard). The "systems security" class is 6.858: http://pdos.csail.mit.edu/6.858/2011/ And there's another class (6.875, taught by Goldwasser or Micali) that is much more pure crypto than Rivest's class. In any case, 6.858 is super fun and probably the most useful for someone looking for practical security knowledge.

This would be easy to implement via a secret sharing scheme, where shares of the secret are maybe stored in local storage until enough of them are collected in the browser to recover the encryption key. But I can't really think of a compelling use case either.

Sort of off-topic, but on the subject of using fragment identifiers to pass around secrets, Ben Adida used them to secure session cookies from eavesdroppers:

https://github.com/benadida/sessionlock

http://www2008.org/papers/pdf/p517-adida.pdf

He uses a token in the fragment identifier to authenticate every request; since the fragment identifier never gets sent to the server, a passive attacker never sees it -- it's a nice trick.

You obviously haven't worked in a real business.

Yes, I have.

You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.

Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.

Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.

In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).

It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.

The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.

Also, who said this is only going to be "browser based"?

Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.

All these acronyms for a browser-based service? Even if you trust this company to have good intentions, it seems that the weakest link by far is the possibility of an XSS, a malicious extension, or a CA compromise. And of course the whole thing depends in multiple ways (verifying your identity, logging in if you clear localStorage, etc.) on the security of your inbox. Their crypto and protocol might be fine, but they should be more forthcoming about the many pieces of software that you are trusting when you use their service. I skimmed their whitepaper but didn't see any mention of the ways that they or someone else could in fact see your data.

It seems that the only type of client cert we're likely to see in wide use on the web in the near future are origin-bound certificates (Google): http://www.browserauth.net/origin-bound-certificates

The proposal is to automatically generate a self-signed cert for each origin. This gets rid of many of the UI problems: it eliminates the need to choose which cert to send to each site (which also means the user can't be tracked across sites via OBCs, and thus the user doesn't need to grant permission before sending his cert).

On the other hand, it doesn't solve the problem of re-authenticating on different machines. It's not proposed as a primary authentication mechanism, but instead as a means of strengthening ordinary HTTP session cookies (http://www.browserauth.net/channel-bound-cookies).

I think Strict Transport Security does more or less exactly what you're asking for: http://tools.ietf.org/html/draft-ietf-websec-strict-transpor....

But besides that, as I understand it, this attack doesn't require an HTTP request to the victim site; it only requires an HTTP request to any site, followed by an HTTPS request to the victim site, so STS wouldn't be much help here unless all websites turn on SSL and adopt STS. (Though someone should correct me if I'm wrong.)

Also note: An attack taking 2^126.1 operations to break AES-128 is not 2^1.9 times faster than brute force; it's 2^0.9 times faster than brute force. A brute force search on a 128-bit key takes on average 2^127 operations.

I'm confused (though admittedly I haven't read the paper fully and don't have any background in cryptanalysis, so I guess it's not surprising that I'm confused). It looks like 2^126.1 is a worst-case complexity for this attack, so it makes sense to compare that complexity to the worst-case complexity of a brute force attack, doesn't it?