Hy there.
I did some graphs of the attacks raiding against the network and the method is quite interesting.
Take a look at it, maybe it helps a bit.
https://elrippoisland.net/public/tor_attack/attack.html
On Fri, 08 Nov 2013 18:19:16 +0100 elrippo elrippo@elrippoisland.net wrote:
Hy there.
I did some graphs of the attacks raiding against the network and the method is quite interesting.
Take a look at it, maybe it helps a bit.
I could understand not using recognized SSL CAs for "philosophical reasons", but ffs, at least get the hostname right?
"Common Name: https://www.elrippoisland.net"
1) but you point people to an URL including hostname with no www.
2) afaik you should NOT have the "https://" string in the Common Name field at all, only the bare hostname.
Please don't train the users to blindly click "Ignore certificate error" if you don't have any valid reason other than your own sloppiness.
I am not sure just what you are calling an "attack". Is it a connection attempt? A probe? A port test?
Also, a heads up... saying "So if you would try to DOS my system, you will probably end up trying without success." is like a call to action. Be careful what you ask for. A DOS on your system would actually be trivial for many people. I dare think ebay and certain unamed government agencies have quite robust systems and sophisticated levels of protection, yet if I am not mistaken they have succumbed to DoS attacks.
That aside, you have some interesting graphs. Trouble is I do not understand what they reveal. Is there a vulnerability design of Tor or the network?
On 11/8/2013 12:19 PM, elrippo wrote:
Hy there.
I did some graphs of the attacks raiding against the network and the method is quite interesting.
Take a look at it, maybe it helps a bit.
https://elrippoisland.net/public/tor_attack/attack.html
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Jope. I tend to have some issues with some CA's. But yes you are right, i should get me a decent certificate. I will do that, promise.
You self signed your site certificate...?
On Fri, 08 Nov 2013 20:15:51 +0100 elrippo elrippo@elrippoisland.net allegedly wrote:
Jope. I tend to have some issues with some CA's. But yes you are right, i should get me a decent certificate. I will do that, promise.
You self signed your site certificate...?
I don't see any problem per se with a self-signed certificate on a site which does not purport to protect anything sensitive (such as financial transactions). The problem with this particular certificate is that the common name identifier is both wrong (www) and badly formattted (http://) But both of those errors can be corrected very quickly.
Why pay a CA if you don't trust the CA model?
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Sat, Nov 09, 2013 at 12:50:18PM +0000, mick wrote:
On Fri, 08 Nov 2013 20:15:51 +0100 elrippo elrippo@elrippoisland.net allegedly wrote:
Jope. I tend to have some issues with some CA's. But yes you are right, i should get me a decent certificate. I will do that, promise.
You self signed your site certificate...?
I don't see any problem per se with a self-signed certificate on a site which does not purport to protect anything sensitive (such as financial transactions). The problem with this particular certificate is that the common name identifier is both wrong (www) and badly formattted (http://) But both of those errors can be corrected very quickly.
Why pay a CA if you don't trust the CA model?
You may want to take a look at https://blog.torproject.org/blog/life-without-ca
-Paul
On Sat, 9 Nov 2013 09:22:12 -0500 Paul Syverson paul.syverson@nrl.navy.mil allegedly wrote:
On Sat, Nov 09, 2013 at 12:50:18PM +0000, mick wrote:
I don't see any problem per se with a self-signed certificate on a site which does not purport to protect anything sensitive (such as financial transactions). The problem with this particular certificate is that the common name identifier is both wrong (www) and badly formattted (http://) But both of those errors can be corrected very quickly.
Why pay a CA if you don't trust the CA model?
You may want to take a look at https://blog.torproject.org/blog/life-without-ca
Paul
Thanks for the pointer - nice post. I tend to agree, though I am not personally that fanatical about deleting all CAs in my browser. I /am/ deeply sceptical about what any particular SSL cert may, or may not, be telling me.
I use self signed certs on my email server and on my website. But they are are there to protect my authentication. I do not expect anyone else to trust them.
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
Hi List :)
Paul Syverson:
You may want to take a look at https://blog.torproject.org/blog/life-without-ca
What about the Perspectives addon? http://www.cs.cmu.edu/~perspectives/ (or http://perspectives-project.org/ where it redirects me) and the talk "BlackHat USA 2011: SSL And The Future Of Authenticity" https://www.youtube.com/watch?v=Z7Wl2FW2TcA
[CW]ould you recommend using it? (e.g. in conjunction with Certificate Patrol)
I have the impression, there aren't that many people regularly using (and relying on) it.
But probably, it could be interesting to (1) have a notary as a hidden service and/or (2) as normal (outside tor) server that does the queries through tor. If in addition, (3) the Perspectives user uses tor for the queries, (s)he hides his identity from the notary.
Purpose of (1): Hide the notary to make it harder to MiM it. Purpose of (2): Randomly* change the perspective of the notary as it views through the exit.
For (2): - On the other hand, the "quality of results" then depends on the number of exit nodes and the probability to choose different exits (with high bandwidth exits being chosen more frequent by tor(?)). - Effectively, this would be the same as without Perspectives and using tor to retrieve the SSL certificates, though it would require multiple exit node changes and queries to get multiple views.
I have to admit, that I'm not knee deep into these topics, so consider these just as some unqualified thoughts... -- n
On Sat, 9 Nov 2013 12:50:18 +0000 mick mbm@rlogin.net wrote:
I don't see any problem per se with a self-signed certificate on a site which does not purport to protect anything sensitive (such as financial transactions). The problem with this particular certificate is that the common name identifier is both wrong (www) and badly formattted (http://) But both of those errors can be corrected very quickly.
Why pay a CA if you don't trust the CA model?
If your primary objection is the need to pay for certificates (and not e.g. the possibility of CA itself being backdoored etc), then I'd suggest considering CACert[1]. It provides free wildcard certificates which are already trusted out of the box by some[2] FOSS operating systems such as Debian.
I'd say it is better than trusting individual self-signed certs, and somewhat better than using your own root CA cert, since it saves the effort required to install your own CA on all machines you need to use it on.
[1] http://www.cacert.org/ [2] http://wiki.cacert.org/InclusionStatus
On Sat, 9 Nov 2013 21:30:13 +0600 Roman Mamedov rm@romanrm.net allegedly wrote:
On Sat, 9 Nov 2013 12:50:18 +0000 mick mbm@rlogin.net wrote:
I don't see any problem per se with a self-signed certificate on a site which does not purport to protect anything sensitive (such as financial transactions). The problem with this particular certificate is that the common name identifier is both wrong (www) and badly formattted (http://) But both of those errors can be corrected very quickly.
Why pay a CA if you don't trust the CA model?
If your primary objection is the need to pay for certificates (and not e.g. the possibility of CA itself being backdoored etc), then I'd suggest considering CACert[1]. It provides free wildcard certificates which are already trusted out of the box by some[2] FOSS operating systems such as Debian.
I'd say it is better than trusting individual self-signed certs, and somewhat better than using your own root CA cert, since it saves the effort required to install your own CA on all machines you need to use it on.
[1] http://www.cacert.org/ [2] http://wiki.cacert.org/InclusionStatus
Roman
Paying for certificates is not my objection. My objection is to the model which says that "if I give money to a commercial entity in exchange for a certificate, that means that the trust chain is valid."
I've actually bought certificates for websites I managed in the past and I am deeply unimpressed with the process. And, as you say, the cert could be backdoored. There are a huge number of CAs from all over the place in the default set shipped in ca-certificates - who do I trust?
I have looked at CA-Cert in the past. They have the problem of very limited acceptability (https://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers)
But as I said, in my particular case, my certs are there to protect my credentials in transit. I don't have to care about whether others trust me. So I don't need a CA. (Though if I did want others to trust me, I'd probably use CAcert).
Best
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Fri, Nov 08, 2013 at 06:19:16PM +0100, elrippo@elrippoisland.net wrote 5.8K bytes in 0 lines about: : I did some graphs of the attacks raiding against the network and the method is : quite interesting.
Perhaps I missed something, what are the attacks? These graphs show some sort of numbers increasing over time.
tor-relays@lists.torproject.org
-
andrew＠torproject.is -
Daniel Case -
elrippo -
gq -
mick -
nb.linux -
Paul Syverson -
Roman Mamedov