I feel that you're significantly understating the potential of what sophisticated network-level attackers can do here. It's annoying... I fundamentally disagree that there's "little point" to this.
First of all, most folks are only signing the Release file. The majority aren't doing debsign/debsigs or dpkg-sig. Okay, some packages ship with some md5sums. Not all. I'm not too worried about tampering or integrity of .deb contents.
How do I know I can trust the Debian archive signing key is in safe hands? For that matter, what about the many third-party repositories and keys that are trusted by my system? Not long ago, Ubuntu was trusting a 1024-bit DSA key. All I need to do is steal or brute-force one of these, and combine it with techniques available to state-level or network adversaries (think of NSA's QUANTUM-insert). Maybe some DNS poisoning or hijacking. Now when you ask for a package you need, I'm giving you my malicious repository instead.
Hostname validation is an important property. Let's say I have a large-scale network where I control the main DNS server, and I can modify records that come from more authoritative sources. I point deb.debian.org and security.debian.org to some other boxes and now no one is getting package updates. Now I have everyone in a more vulnerable state, from which I can figure out more ways to compromise them.
What about the individual package maintainers, can I trust them? Nevermind a distribution like Debian which probably has formal security review. What's to stop one unscrupulous person from being paid to insert a temporary backdoor? Well, that's not so much related to TLS.
> HTTPS does not provide meaningful privacy for obtaining packages.
False.
As mentioned by other commenters, fingerprinting and profiling of the machine — which versions of which packages are installed in the environment — is a real risk which has been demonstrated in practice by researchers. As you mention, the transfer sizes are a mild indicator; not a strong one. But the bar is orders of magnitude higher to identify what's running on a server with apt-transport-https.
Deep packet inspection and Narus is a thing. You're assuming HTTPS is not valuable because the average end user isn't at risk — advanced attackers aren't in their threat model. But when you have machines that both need to be kept highly secure and run a highly specific set of packages, it's absolutely necessary. Imagine I'm an intelligence agency and I'm in that advantaged position where I can see every HTTP GET in plaintext before it hits the official repository, from every client globally. I'm looking for a needle in a haystack: a set or series of packages installed in a certain order. It's trivial now to find my target and learn its IP address.
You're the current project leader... is this page the official stance of Debian?
"If one of the curl project members with git push rights would get her account hacked and her SSH key password brute-forced, a very skilled hacker could possibly sneak in something, short-term. Although my hopes are that as we review and comment each others’ code to a very high degree, that would be really hard."
Nip this entire discussion in the bud; just use a deterministic build process for any binaries you release. Like Gitian: https://gitian.org
Remote candidates, preferably NYC or east coast preferred. We offer a competitive non-profit salary.
We are looking for a full-time technologist to organize and lead digital security trainings for journalists. The Digital Security Trainer will be responsible for designing and implementing a curriculum around digital security that covers a variety of topics, including: threat modeling, email encryption, chat encryption, mobile security, and others. The trainer will travel around the country (and sometimes internationally) to hold seminars and hands-on training sessions inside newsrooms and journalism schools with the goal of teaching journalists to better protect themselves and their sources.
The trainer will also help update and maintain FPF’s ‘Encryption Works’ guide, which is a thirty page how-to white paper about some of the most common digital security practices. In addition, the trainer will become familiar with SecureDrop, the open-source whistleblower submission system FPF maintains, and potentially help with installations and trainings inside newsrooms.
I agree. I wanted to see the EFF's amicus brief, and for the Court to decide on the issue so that we could have good case law with hyperlinks as protected speech.
The indictment establishes a pattern of speech but doesn't establish actual unlawful offenses. No, I don't think he was threatening violence. The FreeBB people have written a bit about this. http://tumblr.freebarrettbrown.org/post/77390763109/debunkin...
No but they are also subject to a motion to dismiss by his defense. http://freebarrettbrown.org/files/BB_motiontodismiss1.pdf The allegations there are actually not as significant as the linking. If he were convicted of threats and that was the only charge, he'd be out by now.
He didn't dox an FBI agent or his family (indeed, he's charged for his speech and there's a motion to dismiss that indictment on First Amendment grounds too); he was under duress and coming off meds, and outraged at the legal threats against his mother. The allegations are "conspiracy to dox" rather than any successful act. Literally they said that someone did a Google search with the goal of making "restricted personal information" public.
He flipped out and lost his cool over constant government-sanctioned harassment. He's not perfect by any means—admitted substance abuse problems and a big naïve/foolish/arrogant streak—but still deserves sympathy.
I don't think he would have known there was a law on the books making it illegal to dox feds. Doxing abusive cops on the other hand is legal and happens all the time between Anonymous/Occupy and even journalists do it sometimes.
In order to convict on threats there needs to be a "true threat" of physical harm, a non-conditional statement made to a specific person. All he said was "if they come" he wouldn't be able to tell FBI from Zetas so he'd exercise self-defense. And he explicitly clarified when he said he was going to ruin the guy's life, he meant to expose him, not as a physical threat.
One can disseminate a link without knowing whats in it. Brown is on the record in many places as being opposed to spreading credit cards. He was against that kind of stuff.
Sadly, the headline is unfortunate because "Barrett Brown faces 100 years for link" was not supposed to be the story here. The story is that his legal team filed a motion arguing that hyperlinks are protected speech under the First Amendment, etc. lol
I would just like to note that the DOJ prosecutors in their press release for the indictment, have indeed touted the maximums, as well as mandatory two-year sentences on each of the aggravated identity theft counts.
"Upon conviction, however, the trafficking count carries a maximum penalty of 15 years in prison and the access device fraud count carries a maximum penalty of 10 years in prison. Each of the aggravated identity theft counts, upon conviction, carries a mandatory two-year sentence in addition to any sentence imposed on the trafficking count."
In this case it is accurate to say he faces up to 45 years for linking, because the statutes that are charged mandate consecutive sentencing. Concurrent sentences are allowed at the court's discretion "only with another term of imprisonment that is imposed by the court at the same time on that person for an additional violation" of the same statute.
He's not the type to plead guilty. I think he's taking this to trial on the principle that he believes he didn't do anything criminal. Also, the defense has a very good case, and the government's appears to be full of holes.
It's a maximum potential sentence of all the charges combined, I think most smart people realize that. As another person noted the media does this to show the charges as excessive.
To respond to your point, the statutes in question here DO in fact mandate consecutive sentencing. Look it up next time.
18 USC § 1028A, etc.
"no term of imprisonment imposed on a person under this section shall run concurrently with any other term of imprisonment imposed on the person under any other provision of law..."
That's not the lawyers argument, it's actually the Guardian writer's failed paraphrase of a point they were trying to make. The government is relying on copyright law which traditionally distinguishes "in-line" linking from "embedded" linking. Since this is neither, their reliance on that is flawed... the writer of this article just didn't fully grok it. I recommend you skim the motion.
A link can't contain credit card numbers or CVVs on its own. It's just a pointer to where the data resides. It's entirely possible that Brown didn't know what he was disseminating. One has to download and open the file to find out. The government is expecting us to know what's in a link before we share it, which is an unreasonable burden. And they're equating transmitting the link with possessing the underlying information. Moreover they haven't shown any illicit transactions resulting from it being shared.
How can reporters verify sources or security researchers examine data dumps without fear of being prosecuted now?
This is a chilling attack on digital rights and needs to be stopped. I hope the judge listens. Stratfor was sued because they failed to sufficiently protect their systems and rightfully so. The actual hacker Jeremy Hammond got less time than this guy faces.
First of all, most folks are only signing the Release file. The majority aren't doing debsign/debsigs or dpkg-sig. Okay, some packages ship with some md5sums. Not all. I'm not too worried about tampering or integrity of .deb contents.
How do I know I can trust the Debian archive signing key is in safe hands? For that matter, what about the many third-party repositories and keys that are trusted by my system? Not long ago, Ubuntu was trusting a 1024-bit DSA key. All I need to do is steal or brute-force one of these, and combine it with techniques available to state-level or network adversaries (think of NSA's QUANTUM-insert). Maybe some DNS poisoning or hijacking. Now when you ask for a package you need, I'm giving you my malicious repository instead.
Hostname validation is an important property. Let's say I have a large-scale network where I control the main DNS server, and I can modify records that come from more authoritative sources. I point deb.debian.org and security.debian.org to some other boxes and now no one is getting package updates. Now I have everyone in a more vulnerable state, from which I can figure out more ways to compromise them.
What about the individual package maintainers, can I trust them? Nevermind a distribution like Debian which probably has formal security review. What's to stop one unscrupulous person from being paid to insert a temporary backdoor? Well, that's not so much related to TLS.
> HTTPS does not provide meaningful privacy for obtaining packages.
False.
As mentioned by other commenters, fingerprinting and profiling of the machine — which versions of which packages are installed in the environment — is a real risk which has been demonstrated in practice by researchers. As you mention, the transfer sizes are a mild indicator; not a strong one. But the bar is orders of magnitude higher to identify what's running on a server with apt-transport-https.
Deep packet inspection and Narus is a thing. You're assuming HTTPS is not valuable because the average end user isn't at risk — advanced attackers aren't in their threat model. But when you have machines that both need to be kept highly secure and run a highly specific set of packages, it's absolutely necessary. Imagine I'm an intelligence agency and I'm in that advantaged position where I can see every HTTP GET in plaintext before it hits the official repository, from every client globally. I'm looking for a needle in a haystack: a set or series of packages installed in a certain order. It's trivial now to find my target and learn its IP address.
You're the current project leader... is this page the official stance of Debian?