Re: [tor-talk] Motivations for certificate issues for onion services

[Roger Dingledine]

On Wed, Aug 09, 2017 at 03:53:59PM -0700, Seth David Schoen wrote:
>   There was also
> a long-standard concern about cryptographic strength mismatch in the
> sense that the cryptography used by onion services was weaker than the
> cryptography that's now used in TLS.  (I think this concern was misplaced,
> but I believe it's served as one of the main rationales for distinguishing
> EV from DV.)

Right -- I used to buy their reasoning, thinking "you're right, 1024-bit
RSA is indeed not as good as modern TLS, let's wait for the newer onion
design", but then I realized that they're comparing the *authentication
about whether you control the domain* step. That is, they are saying that
1024-bit RSA is not as strong as unauthenticated DNS and unauthenticated
BGP. Which is just nonsense.

At HotPETS this year we had a live demonstration, right there while
we all watched, of a BGP hijack on the real Internet, which obtained
a Let's Encrypt certificate for the hijacked domain. Piece of cake.
I'd say needing to factor a 1024-bit RSA, or needing to generate 2^80
keys to find one that matches the onion address you're trying to attack,
is still a much much higher bar.

> So, there has been a suggestion that this issue might be revisted with
> the next generation onion services because they have stronger
> cryptographic primitives.

Can you help me understand why this is not just more of the same poor
reasoning? One of the reasons we want to use modern TLS, i.e. get real
HTTPS certs, is to use those stronger cryptographic primitives. Waiting
for the stronger onion names is like saying you shouldn't be able to get
an HTTPS cert because we can't trust the DNS system -- and I don't hear
any of the CA vendors saying that.

>  Apparently these have now been not only
> implemented but actually demonstrated:
> 
> https://blog.torproject.org/blog/new-and-improved-onion-services-will-premiere-def-con-25
> 
> I'd like to prepare to raise this issue with the CA/Browser forum in
> anticipation of a ballot there to have it be possible for DV certificates
> to be issued to onion services.  So I wanted to ask two things here:
> 
> (1) What's the status of onion services looking like now?

The v3 onion service code is in the code review stage. The relay
side and HSDir side have been in place since Tor 0.3.0, and Nick just
merged the service-side code into master last night. There is a branch
("dgoulet/ticket17242_032_02") that implements the client side.

If you grab that branch, build it, and stick the resulting tor binary
into Browser/TorBrowser/Tor/tor in your tor browser, then you'll have
a tor browser which can successfully visit
http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion/

>  I haven't seen Roger's DEF CON talk.  (Was it recorded?)

It was recorded, and the Defcon people tell me that the video will be
appearing sometime in October or November.

> (2) What reasons do people have for wanting certificates that cover
> onion names?  I think I know of at least three or four reasons, but I'm
> interested in creating a list that's as thorough as possible.

I like Alec's list. Here's the subset of his list I find most compelling:

* We've taught users that https is what they should see in their browser
tab. Browsers are heading towards not letting you do stuff unless the
url says https. We can't, and shouldn't, fight that trend.

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

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.

(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

Re: [tor-talk] Motivations for certificate issues for onion services

[Dave Warren]

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.


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.


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

[tor-talk] torproject package repository

[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?


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.


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

[Alec Muffett]

(2) What reasons do people have for wanting certificates that cover
onion names?  I think I know of at least three or four reasons, but I'm
interested in creating a list that's as thorough as possible.


Six to start with:

- not having to rewrite CMS code which assumes HTTPS, eg for secure
cookies; the Onion acts as a straight deployment on a new domain name

- corollary: not having to lobby browser manufacturers to pollute their
code to understand that http under this magical "onion" TLD is somehow
almost but not entirely treatable like https.

- access to secure-locked protocols like WebRTC

- protection of traffic for the link between Tor daemon (basically a
reverse-proxy) and the site load-balancer fanout in enterprise deployment

- user expectation for padlocks, consistency rather than special-snowflake
creeping featurism

- EV: attestation.

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

[tor-talk] Motivations for certificate issues for onion services

[Seth David Schoen]

Hi folks,

For a long time, publicly-trusted certificate authorities were not
clearly permitted to issue certificates for .onion names.  However, RFC
7686 and a series of three CA/Browser Forum ballots sponsored by Digicert
have allowed issuance of EV certificates (where the legal identity of
the certificate requester is verified offline before the certificate is
issued).  This has allowed Digicert to issue a number of such certificates
to interested (extremely non-anonymous!) onion service operators.

https://crt.sh/?Identity=%25.onion

So far Digicert is the only browser-trusted CA to have taken advantage of
this policy.  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.  There was also
a long-standard concern about cryptographic strength mismatch in the
sense that the cryptography used by onion services was weaker than the
cryptography that's now used in TLS.  (I think this concern was misplaced,
but I believe it's served as one of the main rationales for distinguishing
EV from DV.)

So, there has been a suggestion that this issue might be revisted with
the next generation onion services because they have stronger
cryptographic primitives.  Apparently these have now been not only
implemented but actually demonstrated:

https://blog.torproject.org/blog/new-and-improved-onion-services-will-premiere-def-con-25

I'd like to prepare to raise this issue with the CA/Browser forum in
anticipation of a ballot there to have it be possible for DV certificates
to be issued to onion services.  So I wanted to ask two things here:

(1) What's the status of onion services looking like now?  I haven't
seen Roger's DEF CON talk.  (Was it recorded?)

(2) What reasons do people have for wanting certificates that cover
onion names?  I think I know of at least three or four reasons, but I'm
interested in creating a list that's as thorough as possible.

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

Re: [tor-talk] Tor 0.3.1.5-alpha is released!

[Roman Mamedov]

On Sun, 6 Aug 2017 02:19:05 +0500
Roman Mamedov  wrote:

> > There's a new alpha Tor release available!  The source is available
> > from the "download" page on the website on the website, and packages
> > should be available before long.
> 
> So I am using:
> > deb http://deb.torproject.org/torproject.org 
> > tor-experimental-0.3.1.x-jessie main
> and still do not see the update.

And now my relays get slapped with an "Outdated Tor version" badge for running
Tor 0.3.1.4-alpha. Yet there is no newer package available from the repository.

-- 
With respect,
Roman
-- 
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

[tor-talk] Help us build Tails reproducibly

[u]

Dear Tails and Tor contributors,
dear Reproducible Builds community,

As you might know, Tails [1] has received the Mozilla Open Source
Software award (MOSS) to make Tails ISO images build reproducibly.
Since this project has started, less than a year ago, we've made huge
progress and we've finally seen some ISO images build reproducibly on
the build environments of our core developers as well as on our
isobuilder machines. (See our previous reports [2]).

However, there are still some remaining issues which we'd like to know
more about in order to fix them. That's why we are asking for your
help: Please try and build the Tails 3.1 ISO image and report your
findings back to us. You will find all instructions for doing so
hereafter. Please don't hesitate to contact us if you get stuck at some
point in the process, for example by connecting to our chatroom [3].
You can also send us email to tails-...@boum.org (public) or
ta...@boum.org (private).

# How?

For your convenience all instructions needed to attempt to reproduce
Tails 3.1 are included hereafter. However all commands are
adapted for Debian Stretch (and Buster/Sid), so your results may vary if
you run another Linux distribution. Our full build instructions [4]
might help if you are having problems.

## Setup the build environment

Building Tails requires the KVM virtual machine hypervisor to be
available, a minimum of 1 GiB of free RAM and a maximum of 20 GB of
free storage.

### Install dependencies

sudo apt-get install \
git \
rake \
libvirt-daemon-system \
dnsmasq-base \
ebtables \
qemu-system-x86 \
qemu-utils \
vagrant \
vagrant-libvirt \
vmdebootstrap && \
sudo systemctl restart libvirtd

### If building as a non-root user

(Skip this section if you intend to build Tails as the root user!)

Make sure that the user that is supposed to initiate the build is part
of the relevant groups:

for group in kvm libvirt libvirt-qemu; do sudo adduser $user $group;
done

Then run `newgrp` (or just reboot) to apply the new group memberships
to the session.

## Build Tails 3.1

git clone https://git-tails.immerda.ch/tails
cd tails
git checkout 3.1
git submodule update --init
rake build

# Send us feedback!

No matter how your build attempt turned out we are interested in you
sending us feedback. For that we'll first need some information of the
system you used -- please run these commands in the exact same
terminal session that you ran `rake build` in (e.g. run them right
after `rake build`)!

sudo apt install apt-show-versions || :
(
  for f in /etc/issue /proc/cpuinfo
  do
echo "--- File: ${f} ---"
cat "${f}"
echo
  done
  for c in free locale env 'uname -a' '/usr/sbin/libvirtd --version' \
'qemu-system-x86_64 --version' 'vagrant --version'
  do
echo "--- Command: ${c} ---"
eval "${c}"
echo
  done
  if which apt-show-versions >/dev/null
  then
echo '--- APT package versions ---'
apt-show-versions qemu:amd64 linux-image-amd64:amd64 vagrant \
  libvirt0:amd64
  fi
) | bzip2 > system-info.txt.bz2

Please have a look at the generated file with

bzless system-info.txt.bz2

to make sure it doesn't contain any sensitive information you do not
want to leak in case you send this file to us or make it public!

Next, please follow the instructions below that match your situation!

## If the build failed.

Please open a ticket on our bug tracker [5] with "Category" set to
"Build system" and `system-info.txt.bz2` attached (note that this makes
this file public).

## If the build succeeded ...

Please compute the SHA-512 checksum of the resulting ISO image:

sha512sum tails-amd64-3.1.iso

and compare it to:

843427fa13446c4b7134a10d3269b693317bbb898759e9d4e5dd8a25583372bed767e575974f5ca0229f1b44a99d4c7b64872c3dc433c0caf8965961cac9fb30

### Use the SHA256sum from our signed upgrade files instead

This is optional, but if you want to use an authenticated checksum,
you can find the sha256 checksum in our upgrade files:
https://tails.boum.org/upgrade/v1/Tails/3.0.1/amd64/stable/upgrades.yml
.. which are signed by the Tails signing key [7]:
https://tails.boum.org/upgrade/v1/Tails/3.0.1/amd64/stable/upgrades.yml.pgp

The SHA256 checksum should be:
0ef1c7d880308ee9f98c255b2658b75445cc84622eae2944a342dcc50cea71c7

### ... and the checksums match (i.e. reproduction succeeded).

Congrats for successfully reproducing Tails 3.1! Please send an email
to tails-...@boum.org (public) or ta...@boum.org (private) with the
subject "Reproduction of Tails 3.1 successful" and attach
`system-info.txt.bz2` to it.

### ... and the checksums differ (i.e. reproduction failed).

Now you are in a great position to help Tails improve its
reproducibility! Please install
`diffoscope` [8] version 83 or higher. If you
run Debian