Re: [tor-talk] Ordering a .onion EV certificate from Digitcert

[Andreas Krey]

On Tue, 15 Dec 2015 17:35:19 +, cyb3rwr3ck wrote:
...
> What about CAcert? I am using them for a while now but I have never
> tried them for .onion...

CAcert isn't in the default cert list of tor browser, so you
get the cert exception dance once for each browser restart.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
-- 
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] Exit MITMing plausible?

[Andreas Krey]

Hi all,

a short question regarding potential state-rogue
exit nodes: Does tor browser pin the certificates
(even/at least in-session) so one could detect when
the certificate offered changes to to a bad exit
which does MITM? (Obviously restricted to
state actors.)

Besides, what/how many big exits aren't operated by
known entities?

Tails obviously can't store across sessions,
and doing do in tor browser would leave
traces of accessed sites on disk. Hmm.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
-- 
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] Ordering a .onion EV certificate from Digitcert

[Tom van der Woerdt]

That's not a guide, it just says 'call us'


> On 15 Dec 2015, at 17:09, Fabio Pietrosanti (naif) - lists 
>  wrote:
> 
> Hello,
> 
> we asked on Twitter to Digicert to provide a quick guide on how order an
> x509v3 certificate for TLS for a .onion, they've just published this
> small guide:
> https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/
> 
> Hopefully other CA will follow and at a certain point letsencrypt too.
> 
> -- 
> Fabio Pietrosanti (naif)
> HERMES - Center for Transparency and Digital Human Rights
> http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
> https://ahmia.fi
> -- 
> 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 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] Why is 'Wgm' (middle-relay-for-guard weight) not zero?

[starlight]

Finally came up with a search that yielded
helpful information.  Searching

   "tor" "Wgd=0"

pulled a mathematically intense post written
by Mike Perry:

https://lists.torproject.org/pipermail/tor-dev/2010-January/001039.html

Which discusses validation of the statistics
with Mathematica and provides insight into
the design.  No mention of Wgm but I will
spend a few days working to understand
the math and perhaps will see how Wgm
fits into the picture.




At 12:01 12/13/2015 -0500, you wrote:
>The recent major fix for #17772 inspired
>reflection on the practical effect
>considering relay weighting.  Knowing
>nothing about it aside from the graph
>lines shown by Atlas and Globe, I thought
>the change might make little difference
>as Guard Weight would mostly prevent
>non-guards from being considered.
>
>However, per dir-spec and the current
>consensus, it seems that middle relays
>have a weight equal to guard relays
>when guard selection occurs:
>
>Wgd=0 - exit as guard
>Wgg=6065  - guard as guard
>Wgm=6065  - no-flag as guard
>
>I would like to understand the purpose
>behind this.  Can anyone comment?
>
>Thanks

-- 
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] Ordering a .onion EV certificate from Digitcert

[Seth David Schoen]

Fabio Pietrosanti (naif) - lists writes:

> Hello,
> 
> we asked on Twitter to Digicert to provide a quick guide on how order an
> x509v3 certificate for TLS for a .onion, they've just published this
> small guide:
> https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/
> 
> Hopefully other CA will follow and at a certain point letsencrypt too.

Let's Encrypt doesn't issue EV, so the CA/B Forum needs to agree that
DV certs can be issued for .onion names too (some people have suggested
that they would be called something other than "DV", but be analogous to
DV, based on proof of possession of a cryptographic key from which the
name is derived).

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

[tor-talk] Ordering a .onion EV certificate from Digitcert

[Fabio Pietrosanti (naif) - lists]

Hello,

we asked on Twitter to Digicert to provide a quick guide on how order an
x509v3 certificate for TLS for a .onion, they've just published this
small guide:
https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/

Hopefully other CA will follow and at a certain point letsencrypt too.

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
https://ahmia.fi
-- 
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] Ordering a .onion EV certificate from Digitcert

[cyb3rwr3ck]

On 15.12.2015 17:09, Fabio Pietrosanti (naif) - lists wrote:
> Hopefully other CA will follow and at a certain point letsencrypt too.
>
What about CAcert? I am using them for a while now but I have never
tried them for .onion...
BR
F
-- 
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] Ordering a .onion EV certificate from Digitcert

[Moritz Bartl]

On 12/15/2015 05:52 PM, Andreas Krey wrote:
>> What about CAcert? I am using them for a while now but I have never
>> tried them for .onion...
> CAcert isn't in the default cert list of tor browser, so you
> get the cert exception dance once for each browser restart.

Plus they don't do EV so they cannot issue certs for .onion.

-- 
Moritz Bartl
https://www.torservers.net/
-- 
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] file size of cached-microdescs

[KB]

Hi there!

I am trying to run a hidden service with very limited resources;
the hidden service does work, but as tor catches *stuff* I am running
out of space on my device quite often (and fast)

e.g.:
   1.3M Dec 15 18:58 cached-microdesc-consensus
   1.0M Dec 15 18:39 cached-microdescs
   2.3M Dec 15 19:02 cached-microdescs.new

As i said, tor works most of the time, but when it fills up my space, I
am unable to restart it, until i delete those cached files and let tor
re download what it *really* needs.

Question:
+ Is there a way to limit the cached files sizes?
+ If i run tor with an other user, who's /home is mounted on an other
filesystem (micro sd card) should this work with tor, or would this lead
to permission problems?
+ Which of these files can be deleted without having tor to re download
everything?

Thanks in advance!

Looking forward to any reply :)
Best Regards
KB
-- 
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] Ordering a .onion EV certificate from Digitcert

[Aymeric Vitte]

For what use exactly? ie why people should want a TLS certificate for a
.onion, which by definition is something not tied to an official
"domain", like anything that has no other choice than using self-signed
certificates?

Something can be done to verify that someone owns the .onion "domain"
and probably we should study this (for letsencrypt for example) and get
rid of this notion of "domain" which is obsolete, please take a look at
this thread
http://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0205.html
(follow the previous posts if you have time, this addresses the very
same problematic, including letsencrypt), still not convincingly
answered (despite of the fact that the W3C obviously does not follow its
security policy for WebRTC), since people there seem to find a kind of
funny the Tor protocol but, happier for the planet, succeeded to secure
it with a fb .onion certificate.

Le 15/12/2015 17:09, Fabio Pietrosanti (naif) - lists a écrit :
> Hello,
> 
> we asked on Twitter to Digicert to provide a quick guide on how order an
> x509v3 certificate for TLS for a .onion, they've just published this
> small guide:
> https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/
> 
> Hopefully other CA will follow and at a certain point letsencrypt too.
> 

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-- 
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] Ordering a .onion EV certificate from Digitcert

[Elrippo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Well,
I personally think the CA mechanism is broken, so letsencrypt would be the 
better choice of the bad ones.
Maybe the tordevs could implement a mechanism for selfsigned certs with the key 
mechanism of the hidden service itself to avoid the need of a CA...

Am 15. Dezember 2015 22:24:05 MEZ, schrieb Aymeric Vitte 
:
>For what use exactly? ie why people should want a TLS certificate for a
>.onion, which by definition is something not tied to an official
>"domain", like anything that has no other choice than using self-signed
>certificates?
>
>Something can be done to verify that someone owns the .onion "domain"
>and probably we should study this (for letsencrypt for example) and get
>rid of this notion of "domain" which is obsolete, please take a look at
>this thread
>http://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0205.html
>(follow the previous posts if you have time, this addresses the very
>same problematic, including letsencrypt), still not convincingly
>answered (despite of the fact that the W3C obviously does not follow
>its
>security policy for WebRTC), since people there seem to find a kind of
>funny the Tor protocol but, happier for the planet, succeeded to secure
>it with a fb .onion certificate.
>
>Le 15/12/2015 17:09, Fabio Pietrosanti (naif) - lists a écrit :
>> Hello,
>>
>> we asked on Twitter to Digicert to provide a quick guide on how order
>an
>> x509v3 certificate for TLS for a .onion, they've just published this
>> small guide:
>> https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/
>>
>> Hopefully other CA will follow and at a certain point letsencrypt
>too.
>>
>
>--
>Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>Check the 10 M passwords list: http://peersm.com/findmyass
>Anti-spies and private torrents, dynamic blocklist:
>http://torrent-live.org
>Peersm : http://www.peersm.com
>torrent-live: https://github.com/Ayms/torrent-live
>node-Tor : https://www.github.com/Ayms/node-Tor
>GitHub : https://www.github.com/Ayms
>--
>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

- --
We don't bubble you, we don't spoof you ;)
Keep your data encrypted!
Log you soon,
your Admin
elri...@elrippoisland.net

Encrypted messages are welcome.
0x84DF1F7E6AE03644

- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.11 (GNU/Linux)

mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd
BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb
UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+
B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5
Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R
9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs
e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9
jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h
q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z
+rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI
KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB
tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs
cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL
BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7
uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd
U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW
oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s
IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb
BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI
kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/
axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM
XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi
dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ
qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU
1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY
s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz
f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc
ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich
O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt
7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5
KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB
FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN
LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv
5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ
MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos
UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC
AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo
N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L

[tor-talk] Tor-ramdisk 20151215 released

[Anthony G. Basile]

Hi everyone,

I want to announce that a new release of tor-ramdisk is out.
Tor-ramdisk is a uClibc-based micro Linux distribution whose only
purpose is to host a Tor server in an environment that maximizes
security and privacy.  Security is enhanced by hardening the kernel and
binaries, and privacy is enhanced by forcing logging to be off at all
levels so that even the Tor operator only has access to minimal
information.  Finally, since everything runs in ephemeral memory, no
information survives a reboot, except for the Tor configuration file and
the private RSA key, which may be exported/imported by FTP or SCP.


Changelog:
Tor was updated to version 0.2.7.6, busybox to 1.24.1, openssh to
7.4_p1, and the kernel to 4.2.6 plus Gentoo's
hardened-patches-4.2.6-8.extras.  We also switched from openssl to
libressl 2.2.5.

i686:
Homepage: http://opensource.dyc.edu/tor-ramdisk
Download: http://opensource.dyc.edu/tor-ramdisk-downloads

x86_64:
Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk
Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
-- 
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] Opponents launch 11th-hour campaign to veto CISA bill

[grarpamp]

-- Forwarded message --
From: Henry Baker <hbak...@pipeline.com>
Date: Tue, Dec 15, 2015 at 1:10 PM
Subject: Opponents launch 11th-hour campaign to veto CISA bill


FYI -- "it's a surveillance bill by another name." -- Senator Ron Wyden

Go to the following web site; they will connect you to a number of
people at the White House who are getting irritated by so many calls!

https://www.obamadecides.org/

-
https://www.techdirt.com/articles/20151215/06470133083/congress-drops-all-pretense-quietly-turns-cisa-into-full-surveillance-bill.shtml

Congress Drops All Pretense: Quietly Turns CISA Into A Full On Surveillance Bill

by Mike Masnick

Tue, Dec 15th 2015 9:28am

Remember CISA?  The "Cybersecurity Information Sharing Act"?  It's
getting much much worse as Congress and the administration look to ram
it through -- and in the process, removing any pretense that it's not
a surveillance bill.

https://www.techdirt.com/blog/?tag=cisa

As you may recall, Congress and the White House have been pushing for
a "cybersecurity" bill for a few years now, that has never actually
been a cybersecurity bill.  Senator Ron Wyden was one of the only
people in Congress willing to stand up and directly say what it was:
"it's a surveillance bill by another name."  And, by now, you should
know that when Senator Wyden says that there's a secret interpretation
of a bill that will increase surveillance and is at odds with the
public's understanding of a bill, you should know to listen.  He's
said so in the past and has been right... multiple times.

https://www.wyden.senate.gov/news/press-releases/wyden-cybersecurity-bill-lacks-privacy-protections-doesnt-secure-networks

https://www.techdirt.com/articles/20151207/17063433015/final-text-cisa-apparently-removed-what-little-privacy-protections-had-been-there.shtml

Either way, a version of CISA passed the House a while back, with at
least some elements of privacy protection included.  Then, a few
months ago it passed the Senate in a much weaker state.  The two
different versions need to be reconciled, and it's been worked on.
However, as we noted recently, the intelligence community has
basically taken over the process and more or less stripped out what
few privacy protections there were.

And, the latest is that it's getting worse.  Not only is Congress
looking to include it in the end of year omnibus bill -- basically a
"must pass" bill -- to make sure it gets passed, but it's clearly
dropping all pretense that CISA isn't about surveillance.  Here's what
we're hearing from people involved in the latest negotiations.  The
latest version of CISA that they're looking to put into the omnibus:

1. Removes the prohibition on information being shared with the NSA,
allowing it to be shared directly with NSA (and DOD), rather than
first having to go through DHS.  While DHS isn't necessarily
wonderful, it's a lot better than NSA.  And, of course, if this were
truly about cybersecurity, not surveillance, DHS makes a lot more
sense than NSA.

2. Directly removes the restrictions on using this information for
"surveillance" activities.  You can't get much more direct than that,
right?

3. Removes limitations that government can only use this information
for cybersecurity purposes and allows it to be used to go after any
other criminal activity as well.  Obviously, this then creates
tremendous incentives to push for greater and greater information
collection, which clearly will be abused.  We've just seen how the DEA
has regularly abused its powers to collect info.  You think agencies
like the DEA and others won't make use of CISA too?

https://www.techdirt.com/articles/20151214/08492533071/dea-loses-big-drug-case-thanks-to-illegal-wiretap-warrants-prosecutor-calls-procedural-errors.shtml

4. Removes the requirement to "scrub" personal information unrelated
to a cybersecurity threat before sharing that information.  This was
the key point that everyone kept making about why the information
should go to DHS first -- where DHS would be in charge of this
"scrub".  The "scrub" process was a bit exaggerated in the first
place, but it was at least something of a privacy protection.
However, it appears that the final version being pushed removes the
scrub requirement (along with the requirement to go to DHS) and
instead leaves the question of scrubbing to the "discretion" of
whichever agency gets the information.  Guess how that's going to go?

In short: while before Congress could at least pretend that CISA was
about cybersecurity, rather than surveillance, in this mad dash to get
it shoved through, they've dropped all pretense and have stripped
every last privacy protection, expanded the scope of the bill, and
made it quite clear that it's a very broad surveillance bill that can
be widely used and abused by all parts of the government.

There is still some hesitation by some