Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
I have a couple. One I use a lot, loaded with disinformation. Two are even less complete, but rarely used. I lost access to a fourth by accidentally trying to login over tor, and it insisted on ID to unlock it...so I just ignore that one now. On Fri, 1 Feb 2019 22:58:31 + "'awokd' via qubes-users" wrote: >unman wrote on 2/1/19 4:05 PM: >> On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote: >>> unman wrote on 1/27/19 5:21 PM: (As an aside I'm always baffled by people querying how they can use Facebook under Tor or Whonix. What are they thinking?) >>> >>> There are good reasons for it. See >>> https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To the >>> thread's topic, using Debian's onion repositories helps avoid MITM attacks. >>> Of course, can't protect against compromise of the repositories themselves, >>> but that's not a problem that can be solved at the communications layer. >> >> You missed my point because I wasn't clear enough. >> I know that Facebook is accessible over Tor. >> But why would anyone concerned with privacy ,(presumably why they are >> using Tor or Whonix), want to sup with the devil of Facebook? I don't >> think any spoon is long enough, not even one passing through 3 hops. >> > >Understood. I'm picturing a pseudonymous female blogger who wants to >organize in a country where they aren't allowed to use the internet. Not >sure how compatible that noble goal is with Facebook's real name policy. >A more trite example would be a normal Facebook user who doesn't >necessarily want them and all their 3rd party advertisers to know from >what location/IP address he's logging in. However, I've never had the >desire to create a Facebook account either! > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190201184123.3639af02%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
unman wrote on 2/1/19 4:05 PM: On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote: unman wrote on 1/27/19 5:21 PM: (As an aside I'm always baffled by people querying how they can use Facebook under Tor or Whonix. What are they thinking?) There are good reasons for it. See https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To the thread's topic, using Debian's onion repositories helps avoid MITM attacks. Of course, can't protect against compromise of the repositories themselves, but that's not a problem that can be solved at the communications layer. You missed my point because I wasn't clear enough. I know that Facebook is accessible over Tor. But why would anyone concerned with privacy ,(presumably why they are using Tor or Whonix), want to sup with the devil of Facebook? I don't think any spoon is long enough, not even one passing through 3 hops. Understood. I'm picturing a pseudonymous female blogger who wants to organize in a country where they aren't allowed to use the internet. Not sure how compatible that noble goal is with Facebook's real name policy. A more trite example would be a normal Facebook user who doesn't necessarily want them and all their 3rd party advertisers to know from what location/IP address he's logging in. However, I've never had the desire to create a Facebook account either! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/296d4c0d-9c3e-c26a-601d-fd16c8bde040%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote: > unman wrote on 1/27/19 5:21 PM: > > (As an aside I'm always baffled by people querying > > how they can use Facebook under Tor or Whonix. What are they thinking?) > > There are good reasons for it. See > https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To the > thread's topic, using Debian's onion repositories helps avoid MITM attacks. > Of course, can't protect against compromise of the repositories themselves, > but that's not a problem that can be solved at the communications layer. You missed my point because I wasn't clear enough. I know that Facebook is accessible over Tor. But why would anyone concerned with privacy ,(presumably why they are using Tor or Whonix), want to sup with the devil of Facebook? I don't think any spoon is long enough, not even one passing through 3 hops. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190201160520.sngsqzec3ykz47mh%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
unman wrote on 1/27/19 5:21 PM: (As an aside I'm always baffled by people querying how they can use Facebook under Tor or Whonix. What are they thinking?) There are good reasons for it. See https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To the thread's topic, using Debian's onion repositories helps avoid MITM attacks. Of course, can't protect against compromise of the repositories themselves, but that's not a problem that can be solved at the communications layer. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ecbeb8ce-af33-fb63-4dc3-c4793b8ad273%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Mon, Jan 28, 2019 at 01:30:29PM -0800, goldsm...@riseup.net wrote: > On 2019-01-28 19:46, billol...@gmail.com wrote: > > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote: > >> On 2019-01-27 19:15, billol...@gmail.com wrote: > >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: > To Billollib > > First, Its disappointing you didn't apologise for hijacking my thread. > > Second, you complain I misrepresented you in my summary. Perhaps you > forget writing the following: " I used to do > > > network security for a small scientific government network back in the > > > 1990s, and I constantly ran into the problem that there is an inverse > > > relationship between security and usability. The scientists on my > > > network were constantly finding ways of going around whatever security > > > measures I put in place precisely because they didn't want to deal > > > with the "hassle." > My summary of the above was: "It's the Users of software that subvert > OS's.". I think that's a fair summary of what you said about Users - > in this case scientists. > > Finally: Please, no further hijacking of other peoples posts > To state the obvious it's not your thread, and no one need apologise for commenting, or taking the discussion in a new direction. I doubt that Billollib "forgot writing" anything. I assume that he felt that you represented him, and you had missed the point of what he wrote. Let's try to be civil please. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190130002519.cyq5axyfci4mhad7%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-28 19:46, billol...@gmail.com wrote: > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote: >> On 2019-01-27 19:15, billol...@gmail.com wrote: >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: >> >>[snip] >> >> Qubes provides a framework for using software - it doesn't take away the >> >> onus on users to use that software properly, and to ensure they are aware >> >> of good practice. (As an aside I'm always baffled by people querying >> >> how they can use Facebook under Tor or Whonix. What are they thinking?) >> >> I regularly audit templates with tripwire, running from an >> >> offline openBSD qube, and do standards checks with debsums. I do good >> >> deal of my work offline in openBSD and then transfer encrypted in to >> >> other qubes for transmission. That seems like overkill, and isn't for >> >> everyone: it might be for you. >> >> >> >> unman >> > >> > I think this is the most important thing you wrote. I used to do >> > network security for a small scientific government network back in the >> > 1990s, and I constantly ran into the problem that there is an inverse >> > relationship between security and usability. The scientists on my >> > network were constantly finding ways of going around whatever security >> > measures I put in place precisely because they didn't want to deal >> > with the "hassle." >> > >> > But I'm no different, really. Not too many years ago, I routinely >> > disabled SELinux when I installed a new OS simply because I considered >> > it too much of a hassle to learn how to use it effectively. It made >> > it difficult for me to do stuff. Everybody yelled at me, but it just >> > wasn't worth the effort to me. Now, I've learned it a bit and it's not >> > such a hassle. >> > >> > There's this balance between the inconvenience/damage associated with >> > an intrusion versus the inconvenience associated with the security >> > configuration. For me on the computer I'm using as I write this, it >> > wouldn't be the end of the world if *everything* on my computer were >> > owned by someone else. It would be a hassle, but not fatal -- I have >> > insurance, etc. for the financial information I have here, and I don't >> > really care if someone sees the email conversations I have on this >> > machine. >> > >> > So, considering the financial stuff, for instance. There's a hassle >> > with someone getting my credit card information. It's happened >> > (though not because of a computer glitch). My card gets frozen, I >> > can't use it for a week or two, I have to make a bunch of phone calls, >> > etc. But I'm financially protected and eventually I'll be fine. The >> > problem is the hassle factor, not financial ruin. My biggest security >> > concern is someone using up all my bandwidth; I live in a rural area >> > and have metered service. Someone using up 5 gigs of bandwith is more >> > concerning to me than them owning 5 gigs of data from my machine. So, >> > I have to ask myself, which is more hassle -- dealing with the >> > intrusion, or dealing with the security hassle? >> > >> > It's my responsibility to determine where that balance is, and nobody >> > else's. And it's likely different for everybody. For instance, I >> > used to have a blog, but I'm a litigation consultant and I started >> > seeing my blog posts turning up in court. So I don't blog any more. I >> > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. >> > That's not a problem for me, but it would drive my wife crazy. I use >> > one laptop for some stuff, and I use a different laptop, differently >> > configured, for other stuff. >> > >> > And, the higher up the food chain you go with respect to people >> > interested in surveilling you, the less chance you have of keeping >> > them out. I'm out of the business now, but back in the day I >> > occasionally did some classified work. I remember some years ago, I >> > called a friend of mine who worked for the government. I called him >> > using the work phone of an acquaintance to ask him a technical >> > question. He picked up the phone and immediately said "Hey, Bill, how >> > you doing?" >> > >> > I was stunned. I asked him how the hell he knew it was me. He said >> > "Bill, I'm with the . We always know where you >> > are." >> > >> > I have another friend who spent his early career working for a >> > government contractor. His job was to break into people's houses at >> > night and install keyloggers on their computers. With a subpoena, of >> > course. All the security software in the world won't help you with >> > that. >> > >> > The key, for me, is to achieve the maximum security that I can achieve >> > and stay below my maximum hassle tolerance. Qubes is nice because it >> > adds a big uptick in transparent security with only a small uptick in >> > hassle -- at least for someone who is fairly conversant with sysadmin >> > stuff. So for me it's a big win. But it's not all
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote: > On 2019-01-27 19:15, billol...@gmail.com wrote: > > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: > >>[snip] > >> Qubes provides a framework for using software - it doesn't take away the > >> onus on users to use that software properly, and to ensure they are aware > >> of good practice. (As an aside I'm always baffled by people querying > >> how they can use Facebook under Tor or Whonix. What are they thinking?) > >> I regularly audit templates with tripwire, running from an > >> offline openBSD qube, and do standards checks with debsums. I do good > >> deal of my work offline in openBSD and then transfer encrypted in to > >> other qubes for transmission. That seems like overkill, and isn't for > >> everyone: it might be for you. > >> > >> unman > > > > I think this is the most important thing you wrote. I used to do > > network security for a small scientific government network back in the > > 1990s, and I constantly ran into the problem that there is an inverse > > relationship between security and usability. The scientists on my > > network were constantly finding ways of going around whatever security > > measures I put in place precisely because they didn't want to deal > > with the "hassle." > > > > But I'm no different, really. Not too many years ago, I routinely > > disabled SELinux when I installed a new OS simply because I considered > > it too much of a hassle to learn how to use it effectively. It made > > it difficult for me to do stuff. Everybody yelled at me, but it just > > wasn't worth the effort to me. Now, I've learned it a bit and it's not > > such a hassle. > > > > There's this balance between the inconvenience/damage associated with > > an intrusion versus the inconvenience associated with the security > > configuration. For me on the computer I'm using as I write this, it > > wouldn't be the end of the world if *everything* on my computer were > > owned by someone else. It would be a hassle, but not fatal -- I have > > insurance, etc. for the financial information I have here, and I don't > > really care if someone sees the email conversations I have on this > > machine. > > > > So, considering the financial stuff, for instance. There's a hassle > > with someone getting my credit card information. It's happened > > (though not because of a computer glitch). My card gets frozen, I > > can't use it for a week or two, I have to make a bunch of phone calls, > > etc. But I'm financially protected and eventually I'll be fine. The > > problem is the hassle factor, not financial ruin. My biggest security > > concern is someone using up all my bandwidth; I live in a rural area > > and have metered service. Someone using up 5 gigs of bandwith is more > > concerning to me than them owning 5 gigs of data from my machine. So, > > I have to ask myself, which is more hassle -- dealing with the > > intrusion, or dealing with the security hassle? > > > > It's my responsibility to determine where that balance is, and nobody > > else's. And it's likely different for everybody. For instance, I > > used to have a blog, but I'm a litigation consultant and I started > > seeing my blog posts turning up in court. So I don't blog any more. I > > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. > > That's not a problem for me, but it would drive my wife crazy. I use > > one laptop for some stuff, and I use a different laptop, differently > > configured, for other stuff. > > > > And, the higher up the food chain you go with respect to people > > interested in surveilling you, the less chance you have of keeping > > them out. I'm out of the business now, but back in the day I > > occasionally did some classified work. I remember some years ago, I > > called a friend of mine who worked for the government. I called him > > using the work phone of an acquaintance to ask him a technical > > question. He picked up the phone and immediately said "Hey, Bill, how > > you doing?" > > > > I was stunned. I asked him how the hell he knew it was me. He said > > "Bill, I'm with the . We always know where you > > are." > > > > I have another friend who spent his early career working for a > > government contractor. His job was to break into people's houses at > > night and install keyloggers on their computers. With a subpoena, of > > course. All the security software in the world won't help you with > > that. > > > > The key, for me, is to achieve the maximum security that I can achieve > > and stay below my maximum hassle tolerance. Qubes is nice because it > > adds a big uptick in transparent security with only a small uptick in > > hassle -- at least for someone who is fairly conversant with sysadmin > > stuff. So for me it's a big win. But it's not all there is. > > > > There's no such thing as perfect security. There's only finding the > > balance between one's perceived
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 19:15, billol...@gmail.com wrote: > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: >>[snip] >> Qubes provides a framework for using software - it doesn't take away the >> onus on users to use that software properly, and to ensure they are aware >> of good practice. (As an aside I'm always baffled by people querying >> how they can use Facebook under Tor or Whonix. What are they thinking?) >> I regularly audit templates with tripwire, running from an >> offline openBSD qube, and do standards checks with debsums. I do good >> deal of my work offline in openBSD and then transfer encrypted in to >> other qubes for transmission. That seems like overkill, and isn't for >> everyone: it might be for you. >> >> unman > > I think this is the most important thing you wrote. I used to do > network security for a small scientific government network back in the > 1990s, and I constantly ran into the problem that there is an inverse > relationship between security and usability. The scientists on my > network were constantly finding ways of going around whatever security > measures I put in place precisely because they didn't want to deal > with the "hassle." > > But I'm no different, really. Not too many years ago, I routinely > disabled SELinux when I installed a new OS simply because I considered > it too much of a hassle to learn how to use it effectively. It made > it difficult for me to do stuff. Everybody yelled at me, but it just > wasn't worth the effort to me. Now, I've learned it a bit and it's not > such a hassle. > > There's this balance between the inconvenience/damage associated with > an intrusion versus the inconvenience associated with the security > configuration. For me on the computer I'm using as I write this, it > wouldn't be the end of the world if *everything* on my computer were > owned by someone else. It would be a hassle, but not fatal -- I have > insurance, etc. for the financial information I have here, and I don't > really care if someone sees the email conversations I have on this > machine. > > So, considering the financial stuff, for instance. There's a hassle > with someone getting my credit card information. It's happened > (though not because of a computer glitch). My card gets frozen, I > can't use it for a week or two, I have to make a bunch of phone calls, > etc. But I'm financially protected and eventually I'll be fine. The > problem is the hassle factor, not financial ruin. My biggest security > concern is someone using up all my bandwidth; I live in a rural area > and have metered service. Someone using up 5 gigs of bandwith is more > concerning to me than them owning 5 gigs of data from my machine. So, > I have to ask myself, which is more hassle -- dealing with the > intrusion, or dealing with the security hassle? > > It's my responsibility to determine where that balance is, and nobody > else's. And it's likely different for everybody. For instance, I > used to have a blog, but I'm a litigation consultant and I started > seeing my blog posts turning up in court. So I don't blog any more. I > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. > That's not a problem for me, but it would drive my wife crazy. I use > one laptop for some stuff, and I use a different laptop, differently > configured, for other stuff. > > And, the higher up the food chain you go with respect to people > interested in surveilling you, the less chance you have of keeping > them out. I'm out of the business now, but back in the day I > occasionally did some classified work. I remember some years ago, I > called a friend of mine who worked for the government. I called him > using the work phone of an acquaintance to ask him a technical > question. He picked up the phone and immediately said "Hey, Bill, how > you doing?" > > I was stunned. I asked him how the hell he knew it was me. He said > "Bill, I'm with the . We always know where you > are." > > I have another friend who spent his early career working for a > government contractor. His job was to break into people's houses at > night and install keyloggers on their computers. With a subpoena, of > course. All the security software in the world won't help you with > that. > > The key, for me, is to achieve the maximum security that I can achieve > and stay below my maximum hassle tolerance. Qubes is nice because it > adds a big uptick in transparent security with only a small uptick in > hassle -- at least for someone who is fairly conversant with sysadmin > stuff. So for me it's a big win. But it's not all there is. > > There's no such thing as perfect security. There's only finding the > balance between one's perceived risk, one's actual vulnerability, and > one's tolerance for hassle. And any security configuration is > self-defeating if: > > 1) People take it for granted and think that it's all they have to > think about, and/or > 2) It's enough of a hassle that
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: >[snip] > Qubes provides a framework for using software - it doesn't take away the > onus on users to use that software properly, and to ensure they are aware > of good practice. (As an aside I'm always baffled by people querying > how they can use Facebook under Tor or Whonix. What are they thinking?) > I regularly audit templates with tripwire, running from an > offline openBSD qube, and do standards checks with debsums. I do good > deal of my work offline in openBSD and then transfer encrypted in to > other qubes for transmission. That seems like overkill, and isn't for > everyone: it might be for you. > > unman I think this is the most important thing you wrote. I used to do network security for a small scientific government network back in the 1990s, and I constantly ran into the problem that there is an inverse relationship between security and usability. The scientists on my network were constantly finding ways of going around whatever security measures I put in place precisely because they didn't want to deal with the "hassle." But I'm no different, really. Not too many years ago, I routinely disabled SELinux when I installed a new OS simply because I considered it too much of a hassle to learn how to use it effectively. It made it difficult for me to do stuff. Everybody yelled at me, but it just wasn't worth the effort to me. Now, I've learned it a bit and it's not such a hassle. There's this balance between the inconvenience/damage associated with an intrusion versus the inconvenience associated with the security configuration. For me on the computer I'm using as I write this, it wouldn't be the end of the world if *everything* on my computer were owned by someone else. It would be a hassle, but not fatal -- I have insurance, etc. for the financial information I have here, and I don't really care if someone sees the email conversations I have on this machine. So, considering the financial stuff, for instance. There's a hassle with someone getting my credit card information. It's happened (though not because of a computer glitch). My card gets frozen, I can't use it for a week or two, I have to make a bunch of phone calls, etc. But I'm financially protected and eventually I'll be fine. The problem is the hassle factor, not financial ruin. My biggest security concern is someone using up all my bandwidth; I live in a rural area and have metered service. Someone using up 5 gigs of bandwith is more concerning to me than them owning 5 gigs of data from my machine. So, I have to ask myself, which is more hassle -- dealing with the intrusion, or dealing with the security hassle? It's my responsibility to determine where that balance is, and nobody else's. And it's likely different for everybody. For instance, I used to have a blog, but I'm a litigation consultant and I started seeing my blog posts turning up in court. So I don't blog any more. I can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. That's not a problem for me, but it would drive my wife crazy. I use one laptop for some stuff, and I use a different laptop, differently configured, for other stuff. And, the higher up the food chain you go with respect to people interested in surveilling you, the less chance you have of keeping them out. I'm out of the business now, but back in the day I occasionally did some classified work. I remember some years ago, I called a friend of mine who worked for the government. I called him using the work phone of an acquaintance to ask him a technical question. He picked up the phone and immediately said "Hey, Bill, how you doing?" I was stunned. I asked him how the hell he knew it was me. He said "Bill, I'm with the . We always know where you are." I have another friend who spent his early career working for a government contractor. His job was to break into people's houses at night and install keyloggers on their computers. With a subpoena, of course. All the security software in the world won't help you with that. The key, for me, is to achieve the maximum security that I can achieve and stay below my maximum hassle tolerance. Qubes is nice because it adds a big uptick in transparent security with only a small uptick in hassle -- at least for someone who is fairly conversant with sysadmin stuff. So for me it's a big win. But it's not all there is. There's no such thing as perfect security. There's only finding the balance between one's perceived risk, one's actual vulnerability, and one's tolerance for hassle. And any security configuration is self-defeating if: 1) People take it for granted and think that it's all they have to think about, and/or 2) It's enough of a hassle that you start going around it to do your work. billo -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote: > On 2019-01-27 01:34, unman wrote: > > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: > >> > >> Am I right in thinking that the recently discovered apt vulnerability > >> (DSA 4371-1) in Debian based systems could and should have been > >> mitigated against many years ago by downloading and activating an apt > >> package; "apt-transport-https", which forces apt updates via https? The > >> researcher (Max Justicz) who discovered the vulnerability has stated it > >> couldn't have been exploited if https had been implemented. > >> > >> If "apt-transport-https" is the magic bullet, why in the past hasn't it > >> been implemented by default? And, why for the future, is it not being > >> implemented immediately by Qubes, Debian et al? > >> > >> During the past decade many people with good foresight had predicted the > >> apt vulnerabilty and urged administrators to install the > >> solution;"apt-transport-https". Regrettably, the vocal majority of > >> so-called experts said that's unnecessary because the packages are > >> signed. Was that incompetent advice? or was it a coordinated response > >> from agents of State Actors to hide a deliberate backdoor? I've no idea, > >> but given Snowdens revelations I would not rule anything out. > > > > No you're not right in thinking this. > > You seem to have missed the section where Max explicitly say that "a > > malicious mirror could still exploit a bug like this, even with https." > > So apt-transport-https is no magic bullet, particularly as a cursory > > glance suggests that it allows forcing SSL version to SSLv3, which is > > known to be insecure. > > > > Imagine that apt-transport-https *had* been adopted - have you actually > > looked at the list of vulnerabilities in libcurl, and the various > > breakages in the TLS CA system? I can imagine some one > > posting exactly like you: "Was the move to https incompetent advice? or > > was it a coordinated response from agents of State Actors to hide a > > deliberate backdoor? I've no idea, but given Snowdens revelations I > > would not rule anything out." > > > > I would rule some things out. And in this case it looks like a simple > > mistake. And if you read any of the arguments re http/https you'd see > > that there are reasonable arguments on both sides, and the "so called > > experts" took reasoned positions. > > > > It's always been open to you to install the package and switch to https > > transport in your Debian templates, of course. And Qubes had already > > started to use that by default too. > > Not to downplay the importance of the bug, but let's not lose > > our heads. > > Apologies. I've reposted this because the subscripts weren't clear in > the earlier post. Hopefully this will be clearer. > Thank you for your responses. > I appear to have prodded a hornets nest! I make no apology for that. > It’s good and allows everyone an opportunity to express their views. > Hopefully backed up by facts. > Here's some background as to where I'm coming from: > 1/ I use Debian based templates; including Whonix, exclusively (I do > have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, > monetised etc). So, all my apps (including service apps like > sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. > At this point for me its game over. I'm completely stuffed. Now when > Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the > vulnerability was publicly announced, saying its comparable to a firefox > exploit: I get angry and say what complete and utter PR horsesh*t. > > 2/ Nobody's going to blame Qubes for an vulnerability like this in > Debian etc. However, the least I'd expect from Qubes is a timely > warning. Personally, I got a warning from Whonix a good 12 hrs before > Qubes alerted us! > > 3/ Most people have made an assumption that the good guys i.e. Max > Justicz found the vulnerability first. Personally I never assume > anything and prefer to think "worst case scenario". In this case I have > had no privacy or security whatsoever for possibly years. Whilst Dom0's > been protected, I'm not - what use is that? > > Now turning to Unman's comments: > 1/ > no you're not right in thinking this. > you seem to have missed the section where max explicitly say that "a > malicious mirror could still exploit a bug like this, even with https." > so apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing ssl version to sslv3, which is > known to be insecure. > With respect Unman, you seem to have missed the section where Max > explicitly says "Supporting http is fine. I just think it’s worth making > https repositories the default the safer default and allowing users to > downgrade their security at a later time if they choose to do so". > > Furthermore, The Guardian Project have been promoting the use of
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote: > > 2/ > > Imagine that apt-transport-https *had* been adopted - have you actually > > looked at the list of vulnerabilities in libcurlnd the various > > breakages in the TLS CA system? that. plus, apt is running as root and apt-transport-https needs to parse untrusted input... > You appear to be saying that Debian have created a package; > apt-transport-https which is not fit for purpose? Have you notifified > them of this? and if so what was their response? one of the reasons Debian has not made apt-transport-https is that there is a trade-off between gaining some security properties by using https and loosing some (see above in this very mail)... what really would need to be done would be to rewrite/patch apt, to do all the certificate verification as less priviledged user. I *believe* modern apt suports this (at least I have an _apt user in my /etc/passwd on stretch systems, but not on jessie), but I'm not sure (read: i have no idea) whether apt-transport-https uses that too. -- tschüß, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190127125649.khw72kcuj4yrw7al%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 20190127 at 01:34 + unman wrote: > I would rule some things out. And in this case it looks like a simple > mistake. It could even be intention. Most of you do not think about the cost associated with TLS (and growing with key lengths). But there always were (and will be) discussions whether offering a certain service (especially free of charge) will be worth it considering the attached cost. We're lucky that technology stepped up a bit (I remember doing performance analysis when SSL was pushed into the market by Netscape and found out that it cost about an eightfold increase in CPU resources); you might want to read https://blog.cloudflare.com/how-expensive-is-crypto-anyway/ to get a more recent look at things. But with Quantum computers just around the corner there will be a new arms race current CPUs are not prepared for. And keep in mind that only protecting "important targets" is stupid; if you do not encrypt everything you are attaching target markers to your secrets. Crypto is added cost and designers will always try to find a balance between cost and security... Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6e557736131daa986892765e94eac2a6d25b9dec.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 01:34, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: >> >> Am I right in thinking that the recently discovered apt vulnerability >> (DSA 4371-1) in Debian based systems could and should have been >> mitigated against many years ago by downloading and activating an apt >> package; "apt-transport-https", which forces apt updates via https? The >> researcher (Max Justicz) who discovered the vulnerability has stated it >> couldn't have been exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past hasn't it >> been implemented by default? And, why for the future, is it not being >> implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had predicted the >> apt vulnerabilty and urged administrators to install the >> solution;"apt-transport-https". Regrettably, the vocal majority of >> so-called experts said that's unnecessary because the packages are >> signed. Was that incompetent advice? or was it a coordinated response >> from agents of State Actors to hide a deliberate backdoor? I've no idea, >> but given Snowdens revelations I would not rule anything out. > > No you're not right in thinking this. > You seem to have missed the section where Max explicitly say that "a > malicious mirror could still exploit a bug like this, even with https." > So apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which is > known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you actually > looked at the list of vulnerabilities in libcurl, and the various > breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent advice? or > was it a coordinated response from agents of State Actors to hide a > deliberate backdoor? I've no idea, but given Snowdens revelations I > would not rule anything out." > > I would rule some things out. And in this case it looks like a simple > mistake. And if you read any of the arguments re http/https you'd see > that there are reasonable arguments on both sides, and the "so called > experts" took reasoned positions. > > It's always been open to you to install the package and switch to https > transport in your Debian templates, of course. And Qubes had already > started to use that by default too. > Not to downplay the importance of the bug, but let's not lose > our heads. Apologies. I've reposted this because the subscripts weren't clear in the earlier post. Hopefully this will be clearer. Thank you for your responses. I appear to have prodded a hornets nest! I make no apology for that. It’s good and allows everyone an opportunity to express their views. Hopefully backed up by facts. Here's some background as to where I'm coming from: 1/ I use Debian based templates; including Whonix, exclusively (I do have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, monetised etc). So, all my apps (including service apps like sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. At this point for me its game over. I'm completely stuffed. Now when Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the vulnerability was publicly announced, saying its comparable to a firefox exploit: I get angry and say what complete and utter PR horsesh*t. 2/ Nobody's going to blame Qubes for an vulnerability like this in Debian etc. However, the least I'd expect from Qubes is a timely warning. Personally, I got a warning from Whonix a good 12 hrs before Qubes alerted us! 3/ Most people have made an assumption that the good guys i.e. Max Justicz found the vulnerability first. Personally I never assume anything and prefer to think "worst case scenario". In this case I have had no privacy or security whatsoever for possibly years. Whilst Dom0's been protected, I'm not - what use is that? Now turning to Unman's comments: 1/ no you're not right in thinking this. you seem to have missed the section where max explicitly say that "a malicious mirror could still exploit a bug like this, even with https." so apt-transport-https is no magic bullet, particularly as a cursory glance suggests that it allows forcing ssl version to sslv3, which is known to be insecure. With respect Unman, you seem to have missed the section where Max explicitly says "Supporting http is fine. I just think it’s worth making https repositories the default the safer default and allowing users to downgrade their security at a later time if they choose to do so". Furthermore, The Guardian Project have been promoting the use of https for apt package retrieval for many years. Here's their latest statement; "There is a new vulnerability in Debian’s apt that allows anything that can Man-in-the-Middle (MITM) your traffic to get root on your Debian/Ubuntu/etc boxes. Using
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 01:34, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: >> >> Am I right in thinking that the recently discovered apt vulnerability >> (DSA 4371-1) in Debian based systems could and should have been >> mitigated against many years ago by downloading and activating an apt >> package; "apt-transport-https", which forces apt updates via https? The >> researcher (Max Justicz) who discovered the vulnerability has stated it >> couldn't have been exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past hasn't it >> been implemented by default? And, why for the future, is it not being >> implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had predicted the >> apt vulnerabilty and urged administrators to install the >> solution;"apt-transport-https". Regrettably, the vocal majority of >> so-called experts said that's unnecessary because the packages are >> signed. Was that incompetent advice? or was it a coordinated response >> from agents of State Actors to hide a deliberate backdoor? I've no idea, >> but given Snowdens revelations I would not rule anything out. > > No you're not right in thinking this. > You seem to have missed the section where Max explicitly say that "a > malicious mirror could still exploit a bug like this, even with https." > So apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which is > known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you actually > looked at the list of vulnerabilities in libcurl, and the various > breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent advice? or > was it a coordinated response from agents of State Actors to hide a > deliberate backdoor? I've no idea, but given Snowdens revelations I > would not rule anything out." > > I would rule some things out. And in this case it looks like a simple > mistake. And if you read any of the arguments re http/https you'd see > that there are reasonable arguments on both sides, and the "so called > experts" took reasoned positions. > > It's always been open to you to install the package and switch to https > transport in your Debian templates, of course. And Qubes had already > started to use that by default too. > Not to downplay the importance of the bug, but let's not lose > our heads. Thank you for your responses. I appear to have prodded a hornets nest! I make no apology for that. It’s good and allows everyone an opportunity to express their views. Hopefully backed up by facts. Here's some background as to where I'm coming from: 1/ I use Debian based templates; including Whonix, exclusively (I do have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, monetised etc). So, all my apps (including service apps like sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. At this point for me its game over. I'm completely stuffed. Now when Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the vulnerability was publicly announced, saying its comparable to a firefox exploit: I get angry and say what complete and utter PR horsesh*t. 2/ Nobody's going to blame Qubes for an vulnerability like this in Debian etc. However, the least I'd expect from Qubes is a timely warning. Personally, I got a warning from Whonix a good 12 hrs before Qubes alerted us! 3/ Most people have made an assumption that the good guys i.e. Max Justicz found the vulnerability first. Personally I never assume anything and prefer to think "worst case scenario". In this case I have had no privacy or security whatsoever for possibly years. Whilst Dom0's been protected, I'm not - what use is that? Now turning to Unman's comments: 1/ no you're not right in thinking this. you seem to have missed the section where max explicitly say that "a malicious mirror could still exploit a bug like this, even with https." so apt-transport-https is no magic bullet, particularly as a cursory glance suggests that it allows forcing ssl version to sslv3, which is known to be insecure. With respect Unman, you seem to have missed the section where Max explicitly says "Supporting http is fine. I just think it’s worth making https repositories the default the safer default and allowing users to downgrade their security at a later time if they choose to do so". Furthermore, The Guardian Project have been promoting the use of https for apt package retrieval for many years. Here's their latest statement; "There is a new vulnerability in Debian’s apt that allows anything that can Man-in-the-Middle (MITM) your traffic to get root on your Debian/Ubuntu/etc boxes. Using encrypted connections for downloading updates, like HTTPS or Tor Onion Services, reduces this vulnerability to requiring root on
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 26/01/2019 7.34 PM, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net > wrote: >> >> Am I right in thinking that the recently discovered apt >> vulnerability (DSA 4371-1) in Debian based systems could and >> should have been mitigated against many years ago by downloading >> and activating an apt package; "apt-transport-https", which >> forces apt updates via https? The researcher (Max Justicz) who >> discovered the vulnerability has stated it couldn't have been >> exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past >> hasn't it been implemented by default? And, why for the future, >> is it not being implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had >> predicted the apt vulnerabilty and urged administrators to >> install the solution;"apt-transport-https". Regrettably, the >> vocal majority of so-called experts said that's unnecessary >> because the packages are signed. Was that incompetent advice? or >> was it a coordinated response from agents of State Actors to hide >> a deliberate backdoor? I've no idea, but given Snowdens >> revelations I would not rule anything out. > > No you're not right in thinking this. You seem to have missed the > section where Max explicitly say that "a malicious mirror could > still exploit a bug like this, even with https." So > apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which > is known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you > actually looked at the list of vulnerabilities in libcurl, and the > various breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent > advice? or was it a coordinated response from agents of State > Actors to hide a deliberate backdoor? I've no idea, but given > Snowdens revelations I would not rule anything out." > > I would rule some things out. And in this case it looks like a > simple mistake. And if you read any of the arguments re http/https > you'd see that there are reasonable arguments on both sides, and > the "so called experts" took reasoned positions. > > It's always been open to you to install the package and switch to > https transport in your Debian templates, of course. And Qubes had > already started to use that by default too. Not to downplay the > importance of the bug, but let's not lose our heads. > In addition, from a Qubes perspective, it's worth reiterating this part of the QSB: | Normally, we do not release Qubes Security Bulletins (QSBs) to address | vulnerabilities that only affect VMs internally without affecting the | rest of the Qubes system, i.e. vulnerabilities that do not undermine | the Qubes security model. | | For example, we do not release QSBs to address bugs in Firefox or | Linux kernel USB stacks, because Qubes OS was designed under the | primary assumption that in a typical desktop OS there will be | countless such bugs and that humankind will never be able to patch all | of them promptly (at least not as quickly as developers introduce new | bugs). This is, in fact, the very reason we designed Qubes OS as an | implementation of the security-by-compartmentalization approach. Whenever we're tempted to ask, "Why didn't Qubes secure X inside of a domU?" we should remember this. Not only is it unrealistic to expect the small Qubes team to fix vulnerabilities in software that many larger teams have failed to fix; it also misses the whole point of Qubes in the first place, which is to accept that such vulnerabilities are inevitable and protect ourselves from them by compartmentalizing them, limiting the damage they can do. [I can imagine a cynic responding, "Then why did you issue a QSB at all?" Even though there was no failure in the Qubes security model here (in fact, it did exactly what it was supposed to by limiting the damage this bug could do), we care far more about keeping users safe than about the "optics" of issuing a QSB. We would rather let some people misinterpret the situation and mistakenly think that this shows some flaw in Qubes if it means getting the word out so our users can secure their systems as quickly as possible.] - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxNHwUACgkQ203TvDlQ MDBzvhAAwRQ6ZjTY/dznI3o9fsR9ZSiv0gaCwZYRDqNwoUvXQqKlnqOLhV4Z8WuN 8F3Jcd812AcRIFmsmCXDiFQIW7SF59ywmtwRTukbpuVty+ZdxbIq5zo9WriZH93k 1P/91onvoCrtGI2CgTR8yb0PRF3xBhsKHwmFkKj4Kq1ablM2l1UYlN3VZ6GjxLlc TyXus26LChVm48jcoOB3PTMKpWw91LbTQPebl3OlwhpsilCWKSw0ge3MylLMFJLr q2MGmUxCtpJQTaoyMEAAReEEiV/UaytTJikDQcQ3YjiaCVqxodYqD5/dUfD5lFLp +o7a6wb//eHtwCMQG+RWWIlLaxNlPsUxT2BvujVmNeOn+e1z+jdktRxXK/Vknq8d
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: > > Am I right in thinking that the recently discovered apt vulnerability > (DSA 4371-1) in Debian based systems could and should have been > mitigated against many years ago by downloading and activating an apt > package; "apt-transport-https", which forces apt updates via https? The > researcher (Max Justicz) who discovered the vulnerability has stated it > couldn't have been exploited if https had been implemented. > > If "apt-transport-https" is the magic bullet, why in the past hasn't it > been implemented by default? And, why for the future, is it not being > implemented immediately by Qubes, Debian et al? > > During the past decade many people with good foresight had predicted the > apt vulnerabilty and urged administrators to install the > solution;"apt-transport-https". Regrettably, the vocal majority of > so-called experts said that's unnecessary because the packages are > signed. Was that incompetent advice? or was it a coordinated response > from agents of State Actors to hide a deliberate backdoor? I've no idea, > but given Snowdens revelations I would not rule anything out. No you're not right in thinking this. You seem to have missed the section where Max explicitly say that "a malicious mirror could still exploit a bug like this, even with https." So apt-transport-https is no magic bullet, particularly as a cursory glance suggests that it allows forcing SSL version to SSLv3, which is known to be insecure. Imagine that apt-transport-https *had* been adopted - have you actually looked at the list of vulnerabilities in libcurl, and the various breakages in the TLS CA system? I can imagine some one posting exactly like you: "Was the move to https incompetent advice? or was it a coordinated response from agents of State Actors to hide a deliberate backdoor? I've no idea, but given Snowdens revelations I would not rule anything out." I would rule some things out. And in this case it looks like a simple mistake. And if you read any of the arguments re http/https you'd see that there are reasonable arguments on both sides, and the "so called experts" took reasoned positions. It's always been open to you to install the package and switch to https transport in your Debian templates, of course. And Qubes had already started to use that by default too. Not to downplay the importance of the bug, but let's not lose our heads. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190127013421.7pdxo4adq4tmqefe%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
Le samedi 26 janvier 2019 à 04:39 -0800, goldsm...@riseup.net a écrit : > If "apt-transport-https" is the magic bullet, why in the past hasn't > it > been implemented by default? And, why for the future, is it not being > implemented immediately by Qubes, Debian et al? Furtermore, very few Debian repos support https. Here is the stanza to use https in Debian (adapt it for other flavors): deb https://deb.debian.org/debian/ unstable main contrib non-free deb-src https://deb.debian.org/debian/ unstable main contrib non-free -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4e0a5edcde58d2ce674a85bd67201f57f4dfc401.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Debian Template APT Vulnerability - A ticking bomb?
Am I right in thinking that the recently discovered apt vulnerability (DSA 4371-1) in Debian based systems could and should have been mitigated against many years ago by downloading and activating an apt package; "apt-transport-https", which forces apt updates via https? The researcher (Max Justicz) who discovered the vulnerability has stated it couldn't have been exploited if https had been implemented. If "apt-transport-https" is the magic bullet, why in the past hasn't it been implemented by default? And, why for the future, is it not being implemented immediately by Qubes, Debian et al? During the past decade many people with good foresight had predicted the apt vulnerabilty and urged administrators to install the solution;"apt-transport-https". Regrettably, the vocal majority of so-called experts said that's unnecessary because the packages are signed. Was that incompetent advice? or was it a coordinated response from agents of State Actors to hide a deliberate backdoor? I've no idea, but given Snowdens revelations I would not rule anything out. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9e814631ba39955e16a2ff28096b58e7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
