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.
Do you want that outcome enough to get yourself charged for activities that would bring it about? After all, without a SCOTUS decision the fruit is still hanging on the vine for any of us to snatch.
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.
It's disingenuous to suggest that Brown had no actual intent to harm law enforcement agents while leaving out the fact that the indictment starts by establishing a pattern over multiple weeks of Brown making direct threats to them on Twitter, including threats of violence. The threats aren't (as I understand it) unlawful either, but the combination of threats and any actions in furtherance of them can be.
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...
I would find it very difficult to find any sympathy for the prosecutors and FBI agents in this case. They are bullies, and they have gotten far less blowback than they deserve for doing shitty unethical and likely illegal but for their immunity things like threatening prosecution of family members and intentionally inflicting financial ruin on a defendant's whole family.
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."
They don't add up the numbers to get 100 years, some reporter did that. They give the maximum penalties for each count, which gives an ides of the maximum he could get depending on which counts he's convicted of. They don't mean for you to add them all together, but to know that e.g. he could get 2 years if convicted only of the least serious offense, but up to 15 if convicted of the most serious.
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?