Re: [tor-talk] torproject package repository
With that logic, Debian still is too. dguth...@posteo.net: > With the exception that their servers are likely to still be rooted. > > James: >> Duncan: >> >>> >>> For future reference, Mint is based on Ubuntu. Find out the >>> corresponding version that Mint is basing on, and use the Tor Project's >>> Deb repository for that (this is almost certainly how it has been >>> configured). I don't know what Mint's policy is but I'd be very >>> surprised if this was default. Maybe you added it and forgot about it at >>> an earlier date. I suppose it's possible they have it listed under >>> additional repositories for the sake of convenience for Mint's users. >>> >>> A word of warning I'd urge you to take heed of: Mint have had some >>> severe security issues in the past, both in updating packages (by >>> default they hold essential security updates such as to the kernel back >>> for "stability") and issues on their server. In a nutshell, they have >>> been running a large software project like amateurs and their servers >>> were accordingly rooted. >>> They had their servers compromised twice within the last two years, by >>> means of outdated and ill-configured Wordpress plugins. Their forum >>> contents, including user details and passwords, were compromised and put >>> up for sale for a paltry sum on some dodgy website (if I remember the >>> reporting at the time, this happened more than once); and downloads were >>> replaced with malicious ISO images that included spyware. >>> There is no evidence they changed their security practices, so it's >>> reasonable to suggest that their servers are still compromised, or that >>> it is so trivial to do so that it will happen again. I would recommend >>> installing Debian or Ubuntu directly, as both these distributions have >>> good security practices. >>> But the only package that shows up in Mint's software manager is "torbrowser-launcher", maintained by Ubuntu Developers. I was curious if anyone used this torbrowser-launcher, or if Torproject devs would highly frown on it? Its description: "helps download & install torbrowser." Doesn't mention anything about it verifying TBB signature, which I always do. >> >>> Best, >>> Duncan >> http://www.infoworld.com/article/3182824/linux/is-linux-mint-a-secure-distribution.html >> >> >> https://nakedsecurity.sophos.com/2016/02/22/worlds-biggest-linux-distro-infected-with-malware/ >> >> >> https://superuser.com/questions/882957/how-to-make-sure-that-repositories-added-to-linux-mint-are-safe-and-secure >> >> >> https://www.linuxmint.com/rel_sarah_cinnamon_whatsnew.php >> >> Duncan, I think you're trashing a distro based on what happened in 17.3 >> from overseas. the smart thing is to checksum the download. There are a >> few articles above that talk about this. and there are two sets that >> verify the downloads now. So, in fairness, I believe Mint isn't any >> different than Ubuntu or Debian. Don't forget Debian was vulned a while >> back too. All of these come from the same place and some of these repos >> are interchangeable. I think your subjective ideas are simply out of >> date and wrong now. (P.S., there are more links to prove what I am >> saying here) -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torproject package repository
With the exception that their servers are likely to still be rooted. James: Duncan: For future reference, Mint is based on Ubuntu. Find out the corresponding version that Mint is basing on, and use the Tor Project's Deb repository for that (this is almost certainly how it has been configured). I don't know what Mint's policy is but I'd be very surprised if this was default. Maybe you added it and forgot about it at an earlier date. I suppose it's possible they have it listed under additional repositories for the sake of convenience for Mint's users. A word of warning I'd urge you to take heed of: Mint have had some severe security issues in the past, both in updating packages (by default they hold essential security updates such as to the kernel back for "stability") and issues on their server. In a nutshell, they have been running a large software project like amateurs and their servers were accordingly rooted. They had their servers compromised twice within the last two years, by means of outdated and ill-configured Wordpress plugins. Their forum contents, including user details and passwords, were compromised and put up for sale for a paltry sum on some dodgy website (if I remember the reporting at the time, this happened more than once); and downloads were replaced with malicious ISO images that included spyware. There is no evidence they changed their security practices, so it's reasonable to suggest that their servers are still compromised, or that it is so trivial to do so that it will happen again. I would recommend installing Debian or Ubuntu directly, as both these distributions have good security practices. But the only package that shows up in Mint's software manager is "torbrowser-launcher", maintained by Ubuntu Developers. I was curious if anyone used this torbrowser-launcher, or if Torproject devs would highly frown on it? Its description: "helps download & install torbrowser." Doesn't mention anything about it verifying TBB signature, which I always do. Best, Duncan http://www.infoworld.com/article/3182824/linux/is-linux-mint-a-secure-distribution.html https://nakedsecurity.sophos.com/2016/02/22/worlds-biggest-linux-distro-infected-with-malware/ https://superuser.com/questions/882957/how-to-make-sure-that-repositories-added-to-linux-mint-are-safe-and-secure https://www.linuxmint.com/rel_sarah_cinnamon_whatsnew.php Duncan, I think you're trashing a distro based on what happened in 17.3 from overseas. the smart thing is to checksum the download. There are a few articles above that talk about this. and there are two sets that verify the downloads now. So, in fairness, I believe Mint isn't any different than Ubuntu or Debian. Don't forget Debian was vulned a while back too. All of these come from the same place and some of these repos are interchangeable. I think your subjective ideas are simply out of date and wrong now. (P.S., there are more links to prove what I am saying here) -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torproject package repository
Duncan: > > For future reference, Mint is based on Ubuntu. Find out the > corresponding version that Mint is basing on, and use the Tor Project's > Deb repository for that (this is almost certainly how it has been > configured). I don't know what Mint's policy is but I'd be very > surprised if this was default. Maybe you added it and forgot about it at > an earlier date. I suppose it's possible they have it listed under > additional repositories for the sake of convenience for Mint's users. > > A word of warning I'd urge you to take heed of: Mint have had some > severe security issues in the past, both in updating packages (by > default they hold essential security updates such as to the kernel back > for "stability") and issues on their server. In a nutshell, they have > been running a large software project like amateurs and their servers > were accordingly rooted. > They had their servers compromised twice within the last two years, by > means of outdated and ill-configured Wordpress plugins. Their forum > contents, including user details and passwords, were compromised and put > up for sale for a paltry sum on some dodgy website (if I remember the > reporting at the time, this happened more than once); and downloads were > replaced with malicious ISO images that included spyware. > There is no evidence they changed their security practices, so it's > reasonable to suggest that their servers are still compromised, or that > it is so trivial to do so that it will happen again. I would recommend > installing Debian or Ubuntu directly, as both these distributions have > good security practices. > >> But the only package that shows up in Mint's software manager is >> "torbrowser-launcher", maintained by Ubuntu Developers >>. >> I was curious if anyone used this torbrowser-launcher, or if >> Torproject devs would highly frown on it? >> >> Its description: "helps download & install torbrowser." Doesn't >> mention anything about it verifying TBB signature, which I always do. >> > Best, > Duncan http://www.infoworld.com/article/3182824/linux/is-linux-mint-a-secure-distribution.html https://nakedsecurity.sophos.com/2016/02/22/worlds-biggest-linux-distro-infected-with-malware/ https://superuser.com/questions/882957/how-to-make-sure-that-repositories-added-to-linux-mint-are-safe-and-secure https://www.linuxmint.com/rel_sarah_cinnamon_whatsnew.php Duncan, I think you're trashing a distro based on what happened in 17.3 from overseas. the smart thing is to checksum the download. There are a few articles above that talk about this. and there are two sets that verify the downloads now. So, in fairness, I believe Mint isn't any different than Ubuntu or Debian. Don't forget Debian was vulned a while back too. All of these come from the same place and some of these repos are interchangeable. I think your subjective ideas are simply out of date and wrong now. (P.S., there are more links to prove what I am saying here) -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] torproject package repository
Hi Joe, Joe Btfsplk: Looking at https://www.torproject.org/docs/debian.html.en, it mentions the repository deb http://deb.torproject.org/torproject.org main. Where distribution is the code name of the distro. Is the only package from this repo Tor itself and not Tor Browser? If it does host Tor Browser, would the package also work for Mint 18.1 Serena? Tor Browser is not hosted in the Tor Project's deb repositories because there are concerns that people would not update their browser when a new version is released - Tor Browser basically has automatic updates already (in that it puts a scary warning when you start it up and it detects that it is out of date) so the concern is that people don't refresh their Debian repository as often as would be necessary to get crucial updates to Tor Browser. However, the Torproject repo is / was already entered under "additional repositories" in my software manager and the signing key. It must have been added by the distro, as I didn't know this torproject repo existed. For future reference, Mint is based on Ubuntu. Find out the corresponding version that Mint is basing on, and use the Tor Project's Deb repository for that (this is almost certainly how it has been configured). I don't know what Mint's policy is but I'd be very surprised if this was default. Maybe you added it and forgot about it at an earlier date. I suppose it's possible they have it listed under additional repositories for the sake of convenience for Mint's users. A word of warning I'd urge you to take heed of: Mint have had some severe security issues in the past, both in updating packages (by default they hold essential security updates such as to the kernel back for "stability") and issues on their server. In a nutshell, they have been running a large software project like amateurs and their servers were accordingly rooted. They had their servers compromised twice within the last two years, by means of outdated and ill-configured Wordpress plugins. Their forum contents, including user details and passwords, were compromised and put up for sale for a paltry sum on some dodgy website (if I remember the reporting at the time, this happened more than once); and downloads were replaced with malicious ISO images that included spyware. There is no evidence they changed their security practices, so it's reasonable to suggest that their servers are still compromised, or that it is so trivial to do so that it will happen again. I would recommend installing Debian or Ubuntu directly, as both these distributions have good security practices. But the only package that shows up in Mint's software manager is "torbrowser-launcher", maintained by Ubuntu Developers. I was curious if anyone used this torbrowser-launcher, or if Torproject devs would highly frown on it? Its description: "helps download & install torbrowser." Doesn't mention anything about it verifying TBB signature, which I always do. This is the description: "When you first launch Tor Browser Launcher, it will download TBB from https://www.torproject.org/ and extract it to ~/.local/share/torbrowser, and then execute it. Cache and configuration files will be stored in ~/.cache/torbrowser and ~/.config/torbrowser. Each subsequent execution after installation will simply launch the most recent TBB, which is updated using Tor Browser's own update feature. where TBB would be installed." Tor Browser Launcher is not produced by the Tor Project. It was in Debian Jessie (8, oldstable) in the contrib section, because, while distributing only free software, it downloads executable software that Debian does not build from source. It was removed from Debian Stretch (9, the new stable version) because it was difficult to maintain. The problems related to the way it does signature verification - it has a GPG keyring of the Tor Browser developers' keys, and then it verifies the signature against that. However, because of how it is designed, sometimes false positives occur when the keys of the Tor Browser developers change or are updated, and it will always print a scary warning that signature verification failed. See https://github.com/micahflee/torbrowser-launcher/issues/263 Best, Duncan -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Motivations for certificate issues for onion services
On 10 August 2017 at 01:51, Dave Warrenwrote: > On 2017-08-09 16:53, Seth David Schoen wrote: > > Notably, it doesn't apply to certificate authorities that only issue DV >> certificates, because nobody at the time found a consensus about how to >> validate control over these domain names. >> > > I don't completely understand this, since outside the Tor world it's > possible to acquire DV certificates using verification performed on > unencrypted (HTTP) channels. > I can explain this. I don't agree with it, please don't argue with me, it was a CA/B-forum argument, I am not a member of CA/B-forum, please don't blame me, etc... Also: the argument is gonna be redundant real soon, so there's no point in kicking a dead whale along the beach. Seth has not quite framed the issue properly. The CA/B-forum argument against issuing DV SSL Certificates to 80-bit onions, goes like this: - SHA1 is bad, m'kay? - And Onion addresses are truncated SHA1 - So maybe someone could brute-force a collision, using bad SHA1, to generate their own "facebookcorewwwi" onion certificate? - And the thing about DV certificates is that they can be validated via a simple HTTPS request loopback, m'kay? (eg: LetsEncrypt) - So someone generates their own Facebook Onion certificate, sets up an onion site, and requests and receives a DV certificate via some automated process - And ZOMG this means that SSL will be no longer be perceived as the snow-white, unimpeachable source of trust that it currently is - Therefore: force Onions to use the EV process so that the SSL Issuer *IS REALLY SURE* that it is Facebook who is asking for the certificate, not some SHA1-hacker - And please: nobody point out that equivalent problem in the DNS namespace means that the entirety of SSL's trustworthiness is (in truth) slaved to the ability to revoke a DNS record when someone sets up a fake site. That's it. All of it. Put sarcastically but accurately. There's no point in arguing about it, as geeks so often enjoy. It's over, we can move on, and - as Seth rightly points out - with Prop224 the root of this argument (the SHA1 dependence) simply vanishes, taking the entire rest of the house of cards with it. > Wouldn't the same be possible for a .onion, simply requiring that the > verification service act as a Tor client? This would be at least as good, > given that Tor adds a bit of encryption. Like I say: it's past, we should all move on and be grateful for having got here at all. I know I am, and that I never want to have to deal with the above argument ever again. -a -- http://dropsafe.crypticide.com/aboutalecm -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Motivations for certificate issues for onion services
On Thu, Aug 10, 2017 at 2:53 AM, Roger Dingledinewrote: > > * Admins should be able to run their Tor onion service at a different > location than their webserver. "End to end" in onion encryption means > "Tor client to Tor client", but "end to end" in web encryption means > "Browser to Webserver". You should be able to have both. Never forget > the phrase "SSL added and removed here"! > > * People who write complicated web services should be able to have very > simple "if it's not https, don't allow it" rules, and asking them to > create an onion-sized hole in their security rules is foolish and harmful. > > For me, this is a primary motivation in wanting a DV cert. A number of my sites (for example https://www.bentasker.co.uk) are dual-homed between the WWW and Tor (it's also at http://6zdgh5a5e6zpchdz.onion/ ). I terminate the client's plain HTTP and then use HTTPS for the backhaul to the webserver(s), which in principle feels wrong Of greater concern to me, though, is it means there are various things that I either can't do or are fairly risky to do. Even down to simple things like adding HSTS headers to the site - if I miss stripping just one on the torified end then bad things are going to happen. It also means I can't mark cookies as secure only (not such an issue on the site above, but can be an issue elsewhere). For my own site, I don't need the anonymity (it's plastered with my name, so, yeah), I *could* get an EV, the barrier there is the price - it's just not (IMO) worth it, especially when you start talking about multiple different sites. But, the "cost" I'm paying at the moment is increased complexity in my config and back-end, increasing the risk of me having made a mistake somewhere in there. And that's for a fairly simple (functionality wise) site with an off-the-shelf CMS as the backend. It can easily get more complex (further raising the risk). As Alec alluded too, there's also a trade-off. Either your tor endpoint talks to the backend via HTTP, or (as I do) you use HTTPS for that backhaul, but then have to monkey about in the back-end to have it know that although the connection appears to be HTTPS there's a whole host of things that you cannot use. > - access to secure-locked protocols like WebRTC This too, and as I understand it (unless things have changed), Firefox's intention going forward is to increase the number of features that are HTTPS only. Which isn't necessarily a bad thing, but it does mean that useful features may increasingly become unavailable to hidden services. For a multi-homed site, that's something of an issue because you then have to decide whether to not use those features at all, or to further complicate things by only using them on the non-Tor connections (and put up with user complaints that X should be available via Tor too). > It seems to me that an onion address, where you actually have a private > key that proves that you "are" the onion address, is a slam dunk for > a Domain Validated (DV) situation. It's exactly what everybody should > have wanted for DV certs from the beginning. > When you look at the acceptable steps for proving control of a domain, on the clearnet, yeah. Simply putting a specific file in a specific place is sufficient for validation nowadays, despite the relative ease of messing with DNS and BGP for long enough to pass the 'test'. In comparison, having to have the correct key seems like a much higher burden of proof. > > (In fact, technically speaking, there's no particular need to have a > trusted central third party do the validation, since onion domains are > *self* validating. If we made a tool to generate a cert chain using the > onion private key to certify the traditional TLS key, and we taught Tor > Browser how to verify those cert chains... we wouldn't need the sham > that is a DV certificate authority. But that is a different discussion. :) > > --Roger > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- Ben Tasker https://www.bentasker.co.uk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Motivations for certificate issues for onion services
Dave Warren writes: > I don't completely understand this, since outside the Tor world it's > possible to acquire DV certificates using verification performed on > unencrypted (HTTP) channels. > > Wouldn't the same be possible for a .onion, simply requiring that the > verification service act as a Tor client? This would be at least as good, > given that Tor adds a bit of encryption. I think Roger's reply to my message addresses reasons why I think this is a good argument, and I'm in agreement with you. However, with next-generation onion services, it should no longer be necessary to have any form of this argument. -- Seth SchoenSenior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk