Re: [tor-talk] torproject package repository

2017-08-10 Thread James
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

2017-08-10 Thread dguthrie

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

2017-08-10 Thread 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

2017-08-10 Thread Duncan

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

2017-08-10 Thread Alec Muffett
On 10 August 2017 at 01:51, Dave Warren  wrote:

> 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

2017-08-10 Thread Ben Tasker
On Thu, Aug 10, 2017 at 2:53 AM, Roger Dingledine  wrote:

>
> * 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

2017-08-10 Thread Seth David Schoen
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 Schoen  
Senior 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