[tor-bugs] #26680 [- Select a component]: t that hidden service for as long as possible, so there's still going to be long-term storage somewhere in the chain. Putting it in the directories would mean that as many client as possible could be notified of the hidden service's revocation, even long after the initial revocation is published, in cases where the hidden service operator is unwilling or unable to continue to announce the revocation. Consider that for long-validity revocations, there would actually be less load placed on the network than for a regular short term descriptor. The hidden service would not need to frequently publish a new descriptor about itself. Once a client knows a hidden service is revoked, they do not need to ask about it again. Old revocations could conceivably be stored to disk. The need to revoke hidden service keys is real. It doesn't take long to dig up anecdotes and news reports of .onion sites that have been compromised, but even when detected there is no reliable way for a legitimate hidden service operator to notify the network his service cannot be trusted. Detecting if someone has stolen your hidden service key is easy and is hijacking your traffic is easy, you only have to look out for hidden service descriptors for your service that you did not publish, but there is currently not much that can be done with this information. The hidden service operator could include a notice on his hidden website warning of the compromise and telling users to divert to a different .onion address, but a user has no way of knowing if that warning was published by the attacker and directs to another malicious site. On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote: > Alternatively the original hidden service operator could publish hidden > service descriptors with a normal validity period which contain a > revocation field. A HSDir which receives a descriptor containing the > revocation could replace the (potentially malicious) HS descriptor > stored in its cache. > > A client could be show an alert that the hidden service they are > attempting to access has been compromised

• Previous message (by thread): [tor-bugs] #26679 [- Select a component]: Hi, A good try at solving the problem but one which requires all mail server to get onboard in the presence of established alternatives. The proof of work system you propose doesn't address the problem of tampered email contents or if the email was wanted. It *might* prevent exits from being a source of blacklisting at exchanges. The suppression lists to which you refer aren't generated based on IP (at least not primarily). They're generated based on proof of sender authorization, proof of contents being untampered, and sender reputation (complaint, reject). I'm not certain about where you're sending your email from. > we're encountering a lot of issues related to > sending of email notification behind Tor, with > almost any email provider. Are you trying to send email from the GlobaLeaks domain? At the very least it means all mail servers on the internet would need to accept your proof-of-work as evidence of not being spam and not being tampered. Such emails could still be spam. The emails can still be tampered with by a misconfiguration of sending client (using TLS Wrapper instead of STARTTLS and being forced to fallback to insecure communications by traffic manipulation). In the end it takes more than proof-of-work for public mail servers online. They don't care if the email takes work to produce, they care about if the email is wanted in the first place and if the contents are as originally sent. They're motivated by $$$ and their reputation. If you're trying to send emails behind Tor from a domain you control you should use DKIM. Email servers online can then verify the email was both authorized and un-tampered during transit. Using DKIM
• Next message (by thread): [tor-bugs] #26681 [- Select a component]: e of evidence, it is just that - a conspiracy theory. > You're asserting that Fox and the Govt (or at least some of it's agencies) > are conspiring, but have provided no real no evidence to support it, hence > theory. This was never meant to become a debate over a loosely knit "conspiracy theory", or however you want to define information analysis regarding unlawful Tor-blocking. I do not like the language "conspiracy theory", as the evidence is clear there is a connection between the same corrupt US and UK government officials and executives at News Corp and 21st Century Fox. Remember, those who control the media control the masses, therefore corrupt government officials in both the US and UK, who are abusing their power, use the media as a government run propaganda machine to sway public opinion and control society in a very devious, unlawful manner. Corrupt UK government officials still think they have control over the US, therefore this is one of the many reasons why the US is not a free democracy like naive citizens think it is. >> Why are those of you from the UK of all places so desperate to discredit >> me by the way?! When a citizen posts information for analysis that >> proves foxnews.com, senate.gov, and usps.com are using the exact same >> Tor-blocking software, and the timing that this software was installed >> on the same three domains is not coincidental, how can you in your right >> mind state that there is not a significant connection between these >> three entities? > > Aside from a similar error message, you've not provided anything to show a > 'significant' connection between the three. It is not just a similar error message, the beginning digits on the reference number prove it is the EXACT same software running on all three domains. Perhaps those of you on this mailin
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

#26680: t that hidden service for as long as possible, so there's still  going to
be long-term storage somewhere in the chain. Putting it in the  directories
would mean that as many client as possible could be notified  of the hidden
service's revocation, even long after the initial  revocation is published,
in cases where the hidden service operator is  unwilling or unable to
continue to announce the revocation.  Consider that for long-validity
revocations, there would actually be  less load placed on the network than
for a regular short term  descriptor. The hidden service would not need to
frequently publish a  new descriptor about itself. Once a client knows a
hidden service is  revoked, they do not need to ask about it again. Old
revocations could  conceivably be stored to disk.  The need to revoke
hidden service keys is real. It doesn't take long to  dig up anecdotes and
news reports of .onion sites that have been  compromised, but even when
detected there is no reliable way for a  legitimate hidden service operator
to notify the network his service  cannot be trusted. Detecting if someone
has stolen your hidden service  key is easy and is hijacking your traffic
is easy, you only have to look  out for hidden service descriptors for your
service that you did not  publish, but there is currently not much that can
be done with this  information. The hidden service operator could include a
notice on his  hidden website warning of the compromise and telling users
to divert to  a different .onion address, but a user has no way of knowing
if that  warning was published by the attacker and directs to another
malicious site.  On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote: >
Alternatively the original hidden service operator could publish hidden >
service descriptors with a normal validity period which contain a >
revocation field. A HSDir which receives a descriptor containing the >
revocation could replace the (potentially malicious) HS descriptor > stored
in its cache. > > A client could be show an alert that the hidden service
they are > attempting to access has been compromised
--------------------------------------+--------------------
     Reporter:  cypherpunks           |      Owner:  (none)
         Type:  defect                |     Status:  new
     Priority:  Medium                |  Milestone:
    Component:  - Select a component  |    Version:
     Severity:  Normal                |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |   Reviewer:
--------------------------------------+--------------------
 t that hidden service for as long as possible, so there's still
 going to be long-term storage somewhere in the chain. Putting it in the
 directories would mean that as many client as possible could be notified
 of the hidden service's revocation, even long after the initial
 revocation is published, in cases where the hidden service operator is
 unwilling or unable to continue to announce the revocation.

 Consider that for long-validity revocations, there would actually be
 less load placed on the network than for a regular short term
 descriptor. The hidden service would not need to frequently publish a
 new descriptor about itself. Once a client knows a hidden service is
 revoked, they do not need to ask about it again. Old revocations could
 conceivably be stored to disk.

 The need to revoke hidden service keys is real. It doesn't take long to
 dig up anecdotes and news reports of .onion sites that have been
 compromised, but even when detected there is no reliable way for a
 legitimate hidden service operator to notify the network his service
 cannot be trusted. Detecting if someone has stolen your hidden service
 key is easy and is hijacking your traffic is easy, you only have to look
 out for hidden service descriptors for your service that you did not
 publish, but there is currently not much that can be done with this
 information. The hidden service operator could include a notice on his
 hidden website warning of the compromise and telling users to divert to
 a different .onion address, but a user has no way of knowing if that
 warning was published by the attacker and directs to another malicious
 site.

 On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote:
 > Alternatively the original hidden service operator could publish hidden
 > service descriptors with a normal validity period which contain a
 > revocation field. A HSDir which receives a descriptor containing the
 > revocation could replace the (potentially malicious) HS descriptor
 > stored in its cache.
 >
 > A client could be show an alert that the hidden service they are
 > attempting to access has been compromised

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26680>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

• Previous message (by thread): [tor-bugs] #26679 [- Select a component]: Hi, A good try at solving the problem but one which requires all mail server to get onboard in the presence of established alternatives. The proof of work system you propose doesn't address the problem of tampered email contents or if the email was wanted. It *might* prevent exits from being a source of blacklisting at exchanges. The suppression lists to which you refer aren't generated based on IP (at least not primarily). They're generated based on proof of sender authorization, proof of contents being untampered, and sender reputation (complaint, reject). I'm not certain about where you're sending your email from. > we're encountering a lot of issues related to > sending of email notification behind Tor, with > almost any email provider. Are you trying to send email from the GlobaLeaks domain? At the very least it means all mail servers on the internet would need to accept your proof-of-work as evidence of not being spam and not being tampered. Such emails could still be spam. The emails can still be tampered with by a misconfiguration of sending client (using TLS Wrapper instead of STARTTLS and being forced to fallback to insecure communications by traffic manipulation). In the end it takes more than proof-of-work for public mail servers online. They don't care if the email takes work to produce, they care about if the email is wanted in the first place and if the contents are as originally sent. They're motivated by $$$ and their reputation. If you're trying to send emails behind Tor from a domain you control you should use DKIM. Email servers online can then verify the email was both authorized and un-tampered during transit. Using DKIM
• Next message (by thread): [tor-bugs] #26681 [- Select a component]: e of evidence, it is just that - a conspiracy theory. > You're asserting that Fox and the Govt (or at least some of it's agencies) > are conspiring, but have provided no real no evidence to support it, hence > theory. This was never meant to become a debate over a loosely knit "conspiracy theory", or however you want to define information analysis regarding unlawful Tor-blocking. I do not like the language "conspiracy theory", as the evidence is clear there is a connection between the same corrupt US and UK government officials and executives at News Corp and 21st Century Fox. Remember, those who control the media control the masses, therefore corrupt government officials in both the US and UK, who are abusing their power, use the media as a government run propaganda machine to sway public opinion and control society in a very devious, unlawful manner. Corrupt UK government officials still think they have control over the US, therefore this is one of the many reasons why the US is not a free democracy like naive citizens think it is. >> Why are those of you from the UK of all places so desperate to discredit >> me by the way?! When a citizen posts information for analysis that >> proves foxnews.com, senate.gov, and usps.com are using the exact same >> Tor-blocking software, and the timing that this software was installed >> on the same three domains is not coincidental, how can you in your right >> mind state that there is not a significant connection between these >> three entities? > > Aside from a similar error message, you've not provided anything to show a > 'significant' connection between the three. It is not just a similar error message, the beginning digits on the reference number prove it is the EXACT same software running on all three domains. Perhaps those of you on this mailin
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]