Re: Tor and network security/administration

[Jeremy Chadwick]

On Wed, Jun 21, 2006 at 08:27:18PM -0400, [EMAIL PROTECTED] wrote:
> So if you get a copyright takedown notice regarding infringing material found
> on your network, as per 17 USC 512, you intend to actually take responsibility
> and liability for your user's infringing material? Or do you intend to take 
> the
> ISP Safe Harbor examption, disclaim liability for the material, and nuke the
> user?

FWIW, I've received such notices in the past, for content my users
hosted.  Most organisations sending take-down notices give you a 48
hour window to remove the offending content before legal action is
taken.  I'm thankful for those windows, since I do tend to sleep 10
hours a day... :-)

In the two instances where it happened, the users were removed from
the system immediately (within about 30 minutes) with all of their
data backed up (so they could be given it later, plus in the case
there was any involvement with law enforcement).  Nothing became of
either situation.

In both scenarios, I was prepared to take full responsibility since
technically speaking the facilities (co-location and bandwidth) I pay
for are under my name.  It's my rear on the line, and my users content
can possibly get my co-location network + cage access removed and my
account with my co-location provider terminated (extreme circumstances,
but I have to assume the worst).  That makes the issue my responsibility,
whether I like it or not -- what goes out from my network is my
responsibility.

In regards to Tor, I'm not referring to "infringing material
found on my network" -- I'm referring to shady individuals using
machines on the Tor network (which are run by willing members of
the network) to do things such as bust root on .gov or .mil boxes
and raise all sorts-of hell.  Since Tor server administrators don't
appear to have any idea of who's using their box for what or when
("I know nothing! I'm innocent! I just installed this Tor daemon
and partook in the whole thing willingly!"), who is going to end
up paying fines and serving jail time for an individual doing
nasty things through aforementioned Tor server?

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

Re: Tor and network security/administration

[Matthew Sullivan]

Jeremy Chadwick wrote:


On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote:
 


If the point of the technology is to add a degree of anonymity, you
can be pretty sure that a marker expressly designed to state the
message "Hi, I'm anonymous!" will never be a standard feature of said
technology.  That's a pretty obvious non-starter.
   



Which begs the original question of this thread which I started: with
that said, how exactly does one filter this technology?
 

..and that is also the reason why SORBS and Tor have been a logger 
heads...  This think that their answer addresses SORBS' position from 
their Abuse FAQ ( http://tor.eff.org/faq-abuse.html.en ):


SORBS is putting some Tor server IPs on their email blacklist as well. 
They do this because they passively detect whether your server connects 
to certain IRC networks, and they conclude from this that your server is 
capable of spamming. We tried to work with them to teach them that not 
all software works this way, but we have given up. We recommend you 
avoid them, and teach your friends (if they use them) to avoid abusive 
blacklists too .


Of course SORBS' position is actually this - if you are allowing Trojan 
traffic over the Tor network you will get listed (regardless of whether 
the Trojans can talk to port 25 or not)  Considering they were told 
that, it shows the lack of concern, respect, intelligence or nettiqette 
for such issues.  The new SORBS DB (coming soon) will include a Tor 
DNSbl (like the AHBL's) where administrators of services can choose to 
block this type of traffic.


Our response to people whilst Tor is "That's what you get for using Tor, 
if you must use Tor we recommend moving it to a server/IP that is not 
used for anything important and getting a good lawyer."



"You can't" doesn't make for a very practical solution, by the way.
The same was said about BitTorrent (non-encrypted) when it came out,
and the same is being said about encrypted BT (which has caused
some ISPs to induce rate-limiting).

I'm also left wondering something else, based on the "Legalities"
Tor page.  The justification seems to be that because no one's ever
been sued for using Tor to, say, perform illegitimate transactions
(Kevin's examples) or hack a server somewhere (via SSH or some other
open service), that somehow "that speaks for itself".
 

I actually know of someone who was caught trying to brute force an ISPs 
SSH server - he blamed it on Tor - that didn't stop legal action and 
getting his connection terminated.  (Sorry I am not permitted to give 
details of who or which ISP - so don't ask) - I don't know whether he 
was the responsible party or not, but I do know he has had several 
accounts terminated for similar 'suspect' activity.  He continues to run 
a Tor node.



I don't know about the rest of the folks on NANOG, but telling a
court "I run the Tor service by choice, but the packets that come
out of my box aren't my responsibility", paraphrased, isn't going
to save you from prison time (at least here in the US).  Your box,
your network port, your responsibility: period.
 

AFAIK nor here (Australia) nor in the UK - if the traffic is seen to be 
coming from your machine *you* are responsible unless *you* can show the 
traffic was generated by someone else. i.e. you cannot say 'sorry 
officer it was not me it was my machine' you have to be able to say (and 
prove), 'sorry officer it was not me it was someone else, I don't know 
who, but here is the information about the next step back to the source 
so that you can continue your investigation.' (same as speeding tickets 
- you can't just say "I wasn't driving" - you have to either say 'x was 
driving' or "It wasn't me, I don't know who was driving but I lent the 
car to x you should ask them."


...and for what it's worth, I have no problems with anonymous networks 
for idealistic reasons, however they are always abused, they will 
continue to be abused, Tor is being abused, and I should be able to 
allow or deny traffic into my networks as I see fit


All of my discussions with Tor people have indicated [they] do not think 
I should have the right to deny traffic based on IP address, and that I 
should find other methods of authenticating traffic into my networks.


Regards,

Mat

Re: key change for TCP-MD5

[Richard A Steenbergen]

On Wed, Jun 21, 2006 at 05:55:21PM -0700, Randy Bush wrote:
> 
> when low-hanging fruit is unavailable, or when they see a
> really cool way to exploit the higher fruit, it would be
> prudent to have done something about it.  who cares about
> openly recursive dns servers?  there are easier ways to
> crack the host.  oops!

There is a fine line between being dilligent about security, and wasting 
your time trying to solve problems that don't exist, which I think has 
been crossed in the discussion.

Not to venture too far away from facts and into the realm of cute 
soundbites and quotable one-liners about lions and fruit, but let me 
propose what I think is a good one:

If the bad guys have copies of your MD5 passwords, then you have way 
bigger problems than the bad guys having copies of your MD5 passwords.

I have yet to hear a reasonable counter-argument to this. If there is one 
out there that had not yet been made then by all means now is the time to 
make it. Otherwise, you would really be better served by devoting your 
time and energy into solving real problems. If you're running low on real 
problems to solve, I would be happy to send you some of mine. :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: Global Crossing/Ashburn - Anyone have any SYMPTOMS?

[John Curran]

Randy -
 
  I actually intentionally didn't post the details or ticket number,
  as I was looking for other folks already involved (once their NOC
  said it was a multiple customer issue with the ar2.dca2 router).

  If you're also affected or engaged on the problem, let me know. 

Thanks!
/John

At 5:41 PM -0700 6/21/06, Randy Bush wrote:
>john:
>
>on ops channel, gx senior eng says:
>  o gx backbone crew knows of no multi-cust outage
>  o gx noc knows of nomulti-cust outage
>
>so i very much doubt anyone on this list will have an eta
>for something no one seems to know about.
>
>maybe, rather than a public slam with no content, post some
>symptoms so someone can actually work on it.
>
>net geeks don't mind work, just need hard stuff on which to
>work.
>
>randy

RE: key change for TCP-MD5

[Randy Bush]

> This one is hard to pull off. I think the general conclusion
> a couple years ago in the study that Sean Convery and Matt Franz
> did was that it was less work to try to own the router or buy your
> own AS ;)

this is the "you don't have to run faster than the lion, you
just have to run faster than your friend," theory.  as those
who survived to report are a biased sample, it is not well
tested.

black hats are opportunistic, but not lazy.  they look for
cracks with mamzing diligence.  e.g the recent brilliant
post on cracking the xbox
.

when low-hanging fruit is unavailable, or when they see a
really cool way to exploit the higher fruit, it would be
prudent to have done something about it.  who cares about
openly recursive dns servers?  there are easier ways to
crack the host.  oops!

unfortunately, this is not just theory.  few talk about the
serious routing attacks that have been seen.

randy

Re: Global Crossing/Ashburn - Anyone have any SYMPTOMS?

[Randy Bush]

john:

on ops channel, gx senior eng says:
  o gx backbone crew knows of no multi-cust outage
  o gx noc knows of nomulti-cust outage

so i very much doubt anyone on this list will have an eta
for something no one seems to know about.

maybe, rather than a public slam with no content, post some
symptoms so someone can actually work on it.

net geeks don't mind work, just need hard stuff on which to
work.

randy

RE: key change for TCP-MD5

[Bora Akyol]

 > 
> Another potential attack is an attempt to insert information 
> into a BGP session, such as to introduce bogus routes, or to 
> even become a "man in the middle" of a BGP session. One issue 
> that worries me about this is that if this allows routing to 
> be compromised, then I can figure out how to make money off 
> of this (and if I can think of it, someone even nastier will 
> probably also think of this). Of course this would be much 
> more difficult to pull off, and might require viewing packets 
> between routers to pull off, but if pulled off and not 
> quickly detected could be unfortunate.
> 
> Ross

This one is hard to pull off. I think the general conclusion
a couple years ago in the study that Sean Convery and Matt Franz
did was that it was less work to try to own the router or buy your
own AS ;)

Bora

Re: Internet 2010 - Predictions for 2010 from a Content Forum and NANOG 37 in San Jose

[William B. Norton]

Wow - so many private messages surrounding this. I'll summarize and
group the comments across the predictions below, but first answer some
of the questions I received.

One suggestion was to bury these in a timevault to be opened at NANOG
in 2010. Another suggestion was to bury these where I want the crops
to grow. Thanks for that suggestion.

Of course, predictions are not certain as this person put it: "Unlike
market focus groups which pick the color of the product, the error
rate of groups of humans predicting the future is multiplicative"

Several of you asked who provided the data.  These were engineers,
peering coordinators, some Director and VP level folks, network
planners and architects from Content and ISP Companies that you
probably all have heard about of and a handful of those you have not.
There was no glue sniffing involved.

Keep in mind too that to answer the initial question, the events had
to be both *plausible *and* remarkable* to the group assembled around
the table in 2010. I personally think many of these in the list fit
the criteria, but a few of the usual suspects said that they believe
almost none of these things are plausible (Stating this politely).
Below are a couple data points from the field surrounding the
predictions for 2010.

Content Provider Predictions for 2010
--
Here is the question I put to a group of Content Providers at a content forum:

"We are sitting around this table in 2010 and we are commenting how
remarkable the last few years have been, specifically that:"
1.  Video streaming volume has grown 100 fold
2.  Last mile wireless replaced local loop

These first two were echod by both the Content and ISP folks with a
variation only regarding the degree. Personally I don't see the local
loop going away in the next 4 years but a new wireless offering that
is being taken up big time is possible. Video traffic for YouTube was
said at the Peering BOF to grow 20%/month so there is a possibly
compounding growth rate here, so maybe we would debate the degree of
and length of the scaling growth. Clearly 100 fold increase would be
remarkable.

3.  Botnets (DDOS attacks) are still an issue

I'm surprised noone protested this one - if botnets are still a
problem for the much large capacity 2010 internet then we may have a
much more significant problem to deal with.

4.  Non-mechanical (i.e. Flash) Drives replaced internal hard
drives on laptops

One comment that this is not realisitic.

5.  10% of all cell phones are now video phones
6.  We have cell phones that we actually like

There appears to be debate surrounding this one - the person positing
this believes all the cell phones on the market suck (everyone has
some complaint about whatever phone and provider they have) and that
there will be a PDA + service that overcomes these objections and
become the new thing.

7.  The U.S. is insignificant traffic wise relative to the rest of the world
8.  Most popular question discussed around the table: 'How do we
operate business in China?'


9.  No online privacy. And the gov't watches everything



the future is now:

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2006/06/21/BUG9VJHB9C1.DTL
and
http://www.salon.com/news/feature/2006/06/21/att_nsa/


10. 18-25 demographic is best reached w/ads on the Internet
11. Next Gen 3D on-line Social Networks are so successful
12. No physical network interfaces are needed


For laptops, phones, desktops, upto the DSL modem that's certainly the
case today. Beyond that we are into the wireless last mile stuff.


13. We will big brother ourselves (video cams 'who scraped my car?')
14. So many special purpose Internet apps – in car google maps, live
traffic updates, etc.
15. So much of our personal information is on the net


http://news.yahoo.com/s/ap/20060620/ap_on_bi_ge/police_phone_data


16. Video IM emerged as a dominant app
17. P2P will emerge for non-pirated videos – DRM in place and embraced


Most comments back suggested that the studios don't move this fast
releasing their crown jewels to unfamiliar and historically shameful
technology.


18. Voice calls are free, bundled with other things


Softbank in Japan does this now at least to other Softbank customers,
and pennies per minute elsewhere.  Come on, phone calls are almost
free already!


[some additional notable predictions from this group, but did not
receive simple majority validation]
IPTV replaces cable TV
IPv6 is adopted
Massive Internet Collapse – Metcalfe regurgitates his column
Flexible screen deployment
SPAM is no longer a problem in 2010
Windows embraces distributed computing
Net is not Neutral
Powerline Broadband emerges
FTTH massive deployment

Internet Service Providers Predictions for 2010
--
We didn't get to do this at the Peering BOF at NANOG, but I did some
table discussion

Re: Global Crossing/Ashburn - Anyone have RFO or ETA insight?

[Randy Bush]

> Since sometime early this morning, some traffic through Global Crossing 
> in Ashburn has been experiencing packet loss and varying latency 
> consistent with congestion.  Global crossing's NOC confirms there is an 
> multiple customer issue, but can't/won't/doesn't-know anything with 
> respect to reason for outage or time to repair...   Is anyone working on 
> the other end of the problem who can share some insight?   
> 
> Thanks in advance; sorry to bother the list with operational matters... :-)

presuming that they are working on it if they have symptoms,
if you have actual technical symptoms, you may want to do a
but more of a technical post.

randy

Global Crossing/Ashburn - Anyone have RFO or ETA insight?

[John Curran]

Folks -

Since sometime early this morning, some traffic through Global Crossing 
in Ashburn has been experiencing packet loss and varying latency 
consistent with congestion.  Global crossing's NOC confirms there is an 
multiple customer issue, but can't/won't/doesn't-know anything with 
respect to reason for outage or time to repair...   Is anyone working on 
the other end of the problem who can share some insight?   

Thanks in advance; sorry to bother the list with operational matters... :-)
/John

Re: Tor and network security/administration

[Kevin Day]

On Jun 21, 2006, at 4:08 PM, Todd Vierling wrote:


On 6/21/06, Kevin Day <[EMAIL PROTECTED]> wrote:


Failing that, having an exit node look at HTTP headers back from the
server that contained a "X-No-Anonymous" header to say that the host
at that IP shouldn't allow Tor to use it would work.


What's to stop one or more exit node operators from hacking such a
check right back out of the code?



Nothing, but it's the same nothing that stops me from just blocking  
all Tor exit nodes at the border.


If they showed a little bit of responsibility and allowed other  
people to make the decision if they wanted to deal with anonymous  
users or not, I'd be more than willing not to ban the whole lot of them.


Areas where there already is no expectation of anonymity don't allow  
you to hide your identify in the "real world", so I'm not sure why  
there is the notion that it's a right on the internet. Try applying  
for a credit card anonymously, or cashing a check in a bank wearing a  
ski mask and refusing to show any ID.


I realize fighting open proxies(even ones like this that aren't the  
result of being trojaned/backdoored) is a losing battle, but the  
sheer ease in ANYONE being able to click "Give me a new identity"  
with Tor has really invited the masses to start playing with credit  
card fraud at a level I hadn't seen before. I'm willing to bet others  
are experiencing the same thing, but just don't realize they are  
because they're unfamiliar with Tor and don't know where to look.


On top of all of that, I fully understand that the authors of Tor  
would have no desire to add such a feature. Their users are the end  
users, and placating pissy network operators gives them no benefit.  
All I can say is that if we had a better way of detecting Tor nodes  
automatically, and making policy decisions based around that fact,  
we'd be less likely to flat out ban them all.



On Jun 21, 2006, at 4:53 PM, Jeremy Chadwick wrote:


I'm also left wondering something else, based on the "Legalities"
Tor page.  The justification seems to be that because no one's ever
been sued for using Tor to, say, perform illegitimate transactions
(Kevin's examples) or hack a server somewhere (via SSH or some other
open service), that somehow "that speaks for itself".

I don't know about the rest of the folks on NANOG, but telling a
court "I run the Tor service by choice, but the packets that come
out of my box aren't my responsibility", paraphrased, isn't going
to save you from prison time (at least here in the US).  Your box,
your network port, your responsibility: period.




We had a sheriff in a small town in Alabama quite ready to test that  
theory at one point. A Tor exit node was used to purchase several  
hundred dollars of services on a 75 year old woman's credit card that  
had never used a computer in her life. It took a LOT of explaining,  
but after he and the county DA understood what Tor was about, they  
were completely willing to bring charges against the owner of the IP  
of the exit node. The credit card holder, however, asked that they  
drop the matter, so it never went anywhere. I would have been very  
curious to see how it turned out though.




On Jun 21, 2006, at 5:18 PM, Steve Atkins wrote:


Why bother?

If the traffic is abusive, why do you care it comes from Tor? If  
there's

a pattern of abusive traffic from a few hundred IP addresses, block
those addresses. If you're particularly prone to idiots from Tor (IRC,
say) then preemptively blocking them might be nice, but I doubt the
number of new Tor nodes increases at a fast enough rate for it to be
terribly interesting.



Normally if we get a lot of fraud from one user, we force all  
transactions inside that /24 (or whatever the bgp announcement size  
is) to be manually approved.


This is different because one cranky/pissed off/thieving user has  
control of hundreds of IPs scattered across the world. You can play  
whack-a-mole with them for hours, and they can keep coming back on a  
new IP. Each one can be a fraudulent credit card order, costing us  
hundreds of dollars each.


We have preemptively blocked all the Tor exit nodes we can find, but  
they do change at a rate fast enough that a static list isn't  
sufficient. Many run off cable modems out of a DHCP pool that get a  
new address periodically.

Re: Tor and network security/administration

[Steve Atkins]

On Jun 21, 2006, at 2:53 PM, Jeremy Chadwick wrote:



On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote:

If the point of the technology is to add a degree of anonymity, you
can be pretty sure that a marker expressly designed to state the
message "Hi, I'm anonymous!" will never be a standard feature of said
technology.  That's a pretty obvious non-starter.


Which begs the original question of this thread which I started: with
that said, how exactly does one filter this technology?


Why bother?

If the traffic is abusive, why do you care it comes from Tor? If there's
a pattern of abusive traffic from a few hundred IP addresses, block
those addresses. If you're particularly prone to idiots from Tor (IRC,
say) then preemptively blocking them might be nice, but I doubt the
number of new Tor nodes increases at a fast enough rate for it to be
terribly interesting.

If you want to take legal action you know exactly who is responsible
for the traffic, so whether it's coming from a Tor exit node or not  
isn't

terribly interesting in that case either.

If you still do want to then there are some very obvious ways to do
so, combining a Tor client and a server you run.

(And this is from the perspective of someone who does not believe
there is any legitimate use for Tor at all.)

Cheers,
  Steve

Re: Tor and network security/administration

[Jeremy Chadwick]

On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote:
> If the point of the technology is to add a degree of anonymity, you
> can be pretty sure that a marker expressly designed to state the
> message "Hi, I'm anonymous!" will never be a standard feature of said
> technology.  That's a pretty obvious non-starter.

Which begs the original question of this thread which I started: with
that said, how exactly does one filter this technology?

"You can't" doesn't make for a very practical solution, by the way.
The same was said about BitTorrent (non-encrypted) when it came out,
and the same is being said about encrypted BT (which has caused
some ISPs to induce rate-limiting).

I'm also left wondering something else, based on the "Legalities"
Tor page.  The justification seems to be that because no one's ever
been sued for using Tor to, say, perform illegitimate transactions
(Kevin's examples) or hack a server somewhere (via SSH or some other
open service), that somehow "that speaks for itself".

I don't know about the rest of the folks on NANOG, but telling a
court "I run the Tor service by choice, but the packets that come
out of my box aren't my responsibility", paraphrased, isn't going
to save you from prison time (at least here in the US).  Your box,
your network port, your responsibility: period.

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

Re: Tor and network security/administration

[Todd Vierling]

On 6/21/06, Kevin Day <[EMAIL PROTECTED]> wrote:


Failing that, having an exit node look at HTTP headers back from the
server that contained a "X-No-Anonymous" header to say that the host
at that IP shouldn't allow Tor to use it would work.


What's to stop one or more exit node operators from hacking such a
check right back out of the code?

This is a better idea, but still has a bit of defeats-the-whole-point
to it, as it would depend on people obeying that header voluntarily.
Social vs. technological divide, again.

--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Tor and network security/administration

[Todd Vierling]

On 6/21/06, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote:


> Here's where your misunderstanding is evident.  The filtering proxy
> is not at the Tor exit node; it's at the *entry*.

If the proxy is not at the Tor exit node, how can the tor network
enforce the addition of the "this connection went through tor" HTTP
header that Kevin Day was asking for?


And Tor users will desire to do this ... why?  I have been referring
to the proxying behavior *currently in use* on Tor and likely to be
developed further in the near future.  It is highly *unlikely* that
Tor will add such a header by default, so there's little point in
thinking that such a so-called "solution" might actually come to
light.

Note that nowhere have I implied that Tor HTTP requests would look
like anything but regular HTTP requests, and in fact, that's exactly
the point of Tor's design.  I am NOT using this thread to comment on
the appropriateness of that behavior (I have mixed personal opinions
on that), but rather, to point out what its *users* want, which is
what is likely to be implemented.  Hence my earlier comment about
addressing social vulnerabilities via solely technological methods.


if you rely on a
program sitting on the user's computer adding that header, then
malevolent users can not add this header,


And non-malevolent users who simply wish to avoid marketeers'
statistical data tracking.  There's more than one use for the
technology, y'know.


so Kevin Day's purpose is not served.


If the point of the technology is to add a degree of anonymity, you
can be pretty sure that a marker expressly designed to state the
message "Hi, I'm anonymous!" will never be a standard feature of said
technology.  That's a pretty obvious non-starter.

--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: insane over-regulation - what not to do

[Randy Bush]

> That's going to be fun to watch.

from the outside, not from the inside

randy

Re: insane over-regulation - what not to do

[David W. Hankins]

On Wed, Jun 21, 2006 at 10:36:04AM -0700, Randy Bush wrote:
> the whole thing as a piece.  it looks to be a, likely well-meaning,
> attempt by a gang of bureaucrats and a fancy consultant to put the
> universe in a glass jar and preserve it.  from end user, to net
> operations, to infrastructure, to administration, to law.

There is one thing in here which has great amusement appeal to me:

g. ensure compliance with accepted International technical
   standards in the provision and development of electronic
   communications and transactions;

The protocol police!

It sounds like they're going to create an Industry Forum (GHANOG?),
which may produce a "voluntary industry code."

About like our housing code in the US.


That's going to be fun to watch.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineer   you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpeSQViOyltm.pgp
Description: PGP signature

Re: Tor and network security/administration

[Kevin Day]

On Jun 21, 2006, at 12:43 PM, Lionel Elie Mamane wrote:


If the proxy is not at the Tor exit node, how can the tor network
enforce the addition of the "this connection went through tor" HTTP
header that Kevin Day was asking for? Fundamentally, if you rely on a
program sitting on the user's computer adding that header, then
malevolent users can not add this header, so Kevin Day's purpose is
not served. And that is what is being discussed here.




Just to chime in before this gets any further off what I meant:


I know any intermediary nodes can't inject headers into HTTPS  
connections, that kinda defeats the purpose of SSL. :)


When doing any financial transaction, before any user enters anything  
sensitive, we bounce them to an HTTP page first, then look for common  
proxy headers on that request. If none are found, they're given a  
cookie that allows them to continue on that IP only for HTTPS  
transactions for the next 15 minutes.


Failing that, having an exit node look at HTTP headers back from the  
server that contained a "X-No-Anonymous" header to say that the host  
at that IP shouldn't allow Tor to use it would work.



*Anything* would be better for Tor users if we could keep Tor abuse  
off our financial services without having to just ban all Tor IPs at  
the border. On a credit card transaction page, you have no anonymity  
anyway, since you're having to give us your credit card number, home  
address, etc. Yet, until we banned as many known Tor IPs as we could  
find from our network, Tor IPs accounted for a pretty high percentage  
of our credit card fraud, and nearly zero non-fraudulent use. Tor IPs  
had some significant(legitimate) use on some of our other sites, but  
that's gone because they're all null routed at the border now.


Tor may have some legit uses, but when it's costing us $BIGNUM in  
credit card fraud, I'm not going to spend too much time trying to  
only selectively ban it from our network.

Comcast.net, Usa.net, Verizon

[Elijah Savage]

Are there anyone on the list from these organizations that could possibly
put me in contact with the postmasters please?

Thank you

Re: Tor and network security/administration

[Lionel Elie Mamane]

On Wed, Jun 21, 2006 at 01:14:52PM -0400, Todd Vierling wrote:
> On 6/20/06, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote:

 You don't do your financial transactions over HTTPS? If you do, by
 the very design of SSL, the tor exit node cannot add any HTTP
 header. That would be a man-in-the-middle attack on SSL.

>>> Which, for an anonymizing network, could be a deliberate situation.

>> The user then loses end-to-end encryption with the final server he
>> want to connect to.

> Depends on your definition of "end-to-end" -- if one "end" is "an
> agent on the user's computer", it still fits.  But I think you
> misunderstand the reason for a filtering proxy in the context of
> anonymizing networks; read on:

>> So suddenly this daemon needs an UI on every single user on
>> the desktop of the user.

> Here's where your misunderstanding is evident.  The filtering proxy
> is not at the Tor exit node; it's at the *entry*.

If the proxy is not at the Tor exit node, how can the tor network
enforce the addition of the "this connection went through tor" HTTP
header that Kevin Day was asking for? Fundamentally, if you rely on a
program sitting on the user's computer adding that header, then
malevolent users can not add this header, so Kevin Day's purpose is
not served. And that is what is being discussed here.

>> Let's suppose the tor exit node does this https-man-in-the-middle
>> dance. It is not desirable for all connections, so you need some
>> way for the user to say per connection what whether it should
>> happen or not. SOCKS doesn't have such a thing in its protocol,
>> so...

> With SOCKS, automated filter control based on IP address (and
> hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is
> trivial.

What I was trying to say was: The SOCKS protocol has no mechanism for
the SOCKS proxy to tell the SOCKS client "before I establish that
connection, please ask the user that question and report the answer
back to me".

-- 
Lionel

RE: insane over-regulation - what not to do

[Bill Woodcock]

  On Wed, 21 Jun 2006, Randy Whitney wrote:
> Could you be more specific? Are you talking about "Part VIII
> DOMAIN NAME REGISTAR" or something else?

Not presuming to answer for Randy, just for myself:

This follows one of the typical failure-modes of technical legislation, 
which is that it contains quite a few good ideas (cryptographic signatures 
should be deemed to fulfill the role of signatures, nonrepudiatable  
electronic delivery should be deemed to constitute delivery, etc.) which 
are re-worded in less-specific "more accessible" language by lawyers, 
chopped into very small bits, mixed and blended until uniformly 
unrecognizable, and allowed to ferment until twelve times larger.

These things typically create a bit of a baby-with-the-bathwater conundrum 
for people who think they know what _should_ be done, since many of the 
things that _should_ be done are in fact buried in the legalese, and 
starting over from scratch with the same seeds would, like as not, yield 
a very similar bloated bloated end-product, with another year or two 
wasted in the mean-time.  Which all comes down to the old maxim: you can't 
legislate stupidity out of existence.  Or, perhaps, legislation, by its 
very existence, brings some stupidity into existence.

Less is more.

-Bill

RE: insane over-regulation - what not to do

[Randy Bush]

> Could you be more specific? Are you talking about "Part VIII
> DOMAIN NAME REGISTAR" or something else?

the whole thing as a piece.  it looks to be a, likely well-meaning,
attempt by a gang of bureaucrats and a fancy consultant to put the
universe in a glass jar and preserve it.  from end user, to net
operations, to infrastructure, to administration, to law.

[ i do not do the GH domain.  folk in ghana do, but i let them run
  it on one of my servers. ]

randy


> 
> rsw.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Randy Bush
> > Sent: Wednesday, June 21, 2006 12:59 PM
> > To: [EMAIL PROTECTED]
> > Subject: insane over-regulation - what not to do
> > 
> > 
> > just so one can see how deep in a hole things can go if no
> > grownups are present, look at what ghana is about to do to
> > kill the goose that laid the golden egg
> > 
> >   http://rip.psg.com/~randy/ghana-insanity.pdf
> > 
> > randy
> > 
> > 
> 
> 

Re: insane over-regulation - what not to do

[Valdis . Kletnieks]

On Wed, 21 Jun 2006 12:21:34 CDT, Jerry Pasker said:

> I like Part XIII, Subsecton 115.   "Thing." myself.

Actually, that serves a very important purpose - it codifies the concept
that a string of ones and zeros can represent something with actual value.
If it wasn't there, a defendant could argue that they didn't steal/forge
a bank account withdrawal authorization, they just copied/created a stream
of bits.


pgp469JBcfKfx.pgp
Description: PGP signature

RE: insane over-regulation - what not to do

[Jerry Pasker]

Could you be more specific? Are you talking about "Part VIII
DOMAIN NAME REGISTAR" or something else?

rsw.



I like Part XIII, Subsecton 115.   "Thing." myself.

-Jerry

Re: Tor and network security/administration

[Todd Vierling]

On 6/20/06, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote:


>> You don't do your financial transactions over HTTPS? If you do, by
>> the very design of SSL, the tor exit node cannot add any HTTP
>> header. That would be a man-in-the-middle attack on SSL.

> Which, for an anonymizing network, could be a deliberate situation.



The user then loses end-to-end encryption with the final server he
want to connect to.


Depends on your definition of "end-to-end" -- if one "end" is "an
agent on the user's computer", it still fits.  But I think you
misunderstand the reason for a filtering proxy in the context of
anonymizing networks; read on:


That is unacceptable for a whole range of uses. If
a _user_  wants to control browser headers, he can instruct the
_browser_ in what headers to send or not.


The reason filtering proxies exist (and are popular with anonymizing
networks) is because most browsers don't provide a deep level of
configurability for this sort of thing.


Let's suppose the tor exit node does this https-man-in-the-middle
dance. It is not desirable for all connections, so you need some way
for the user to say per connection what whether it should happen or
not. SOCKS doesn't have such a thing in its protocol, so...


With SOCKS, automated filter control based on IP address (and
hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is
trivial.


So suddenly this daemon needs an UI on every single user on
the desktop of the user.


Here's where your misunderstanding is evident.  The filtering proxy is
not at the Tor exit node; it's at the *entry*.

Marrying the UI and the user using the proxy is precisely the point --
the filter is controlled by the person using it.  Thus the UI is
provided to the user who both installed, and is using, the filtering
proxy.  This is typically the way in which e.g. Privoxy+Tor is used,
as Privoxy has no facility for per-user filter settings.


And how do you handle client certificates in there?


Install the client certs into the proxy agent.


And how do you handle the verification of the server certificate? How
do you know which CA's the client trusts?


Use the proxy agent's UI to pop up the same sort of dialog-box
validation that the browser would traditionally provide.  There happen
to be ready-made code libraries for just this purpose.


And even if you have solved all this for SSL, then there is the _next_
protocol that you have to "man in the middle fiddle with". This way
lies madness.


Filtering proxies target a somewhat narrow scope, but broad use,
subset of possible protocols.  HTTP + HTTPS cover a pretty huge chunk
of traffic and user involvement.  Certainly some other common
protocols could be filtered for anonymizing purposes in their own
ways.

--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

RE: insane over-regulation - what not to do

[Randy Whitney]

Could you be more specific? Are you talking about "Part VIII
DOMAIN NAME REGISTAR" or something else?

rsw.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Randy Bush
> Sent: Wednesday, June 21, 2006 12:59 PM
> To: [EMAIL PROTECTED]
> Subject: insane over-regulation - what not to do
> 
> 
> just so one can see how deep in a hole things can go if no
> grownups are present, look at what ghana is about to do to
> kill the goose that laid the golden egg
> 
>   http://rip.psg.com/~randy/ghana-insanity.pdf
> 
> randy
> 
> 

Re: key change for TCP-MD5

[Iljitsch van Beijnum]

On 21-jun-2006, at 16:24, Ross Callon wrote:


If DOS is such a large concern, IPSEC to an extent can be used
to mitigate against it.



Well, this one comment is the one that I don't understand. I
don't see how IPSEC mitigates against DOS attacks. In fact, it
seems to make things worse, since it hides the TCP header.


Only if you use encryption. You can also use authentication only, in  
two ways: with ESP, which only protects and/or encrypts the payload,  
or with AH, which protects the entire packet except for fields that  
may/must be changed in transit. But due to layering, it's unlikely  
you'll be looking at TCP stuff before performing the authentication  
check.


The reason IPsec helps against a DoS against the CPU is that it has  
an anti replay counter. IPsec implementations are supposed to  
maintain a window, not unlike a TCP window, that allows them to  
reject packets with an anti replay counter that's too far behind or  
ahead of the last seen packets. So in order to make a packet reach  
the CPU an attacker has to observe or guess an acceptable value for  
the anti replay counter.


An even better way to protect against spoofed BGP packets (ones that  
come from "far away" at least) is GTSM (RFC 3682), as Randy remarked  
in his usual concise manner. GTSM means setting the TTL to 255 when  
sending and checking if it's still 255 when receiving BGP packets.  
This way you know that there weren't any routers between you and the  
real source of the packet.


Unfortunately, GTSM isn't used much in practice because the BGP RFC  
requires routers to set and check for TTL = 1, so a router employing  
GTSM can't talk to one that doesn't. This means you have to enable it  
manually at both ends and suffer downtime during the period where one  
end has it enabled and the other doesn't. If only someone would have  
taken the extra time to define a BGP option that would allow routers  
to negotiate the use of GTSM automatically...

insane over-regulation - what not to do

[Randy Bush]

just so one can see how deep in a hole things can go if no
grownups are present, look at what ghana is about to do to
kill the goose that laid the golden egg

  http://rip.psg.com/~randy/ghana-insanity.pdf

randy

Re: key change for TCP-MD5

[David Barak]

--- Ross Callon <[EMAIL PROTECTED]> wrote:

> Another potential attack is an attempt to insert
> information
> into a BGP session, such as to introduce bogus
> routes, or
> to even become a "man in the middle" of a BGP
> session. One
> issue that worries me about this is that if this
> allows routing to
> be compromised, then I can figure out how to make
> money off
> of this (and if I can think of it, someone even
> nastier will probably
> also think of this). Of course this would be much
> more difficult to
> pull off, and might require viewing packets between
> routers to pull
> off, but if pulled off and not quickly detected
> could be unfortunate.

But it's safe to say that it would be a lot easier to
crack a router itself than to unobtrusively insert
useful false information, or if the ISP's routers are
sufficiently hardened, it would be easier to crack a
customer (or peer)'s router, and use that for the
injection.  

The same mechanisa which can detect bogus prefixes
from a peer/customer can detect them from a hijacked
session.  The cost/benefit ratio is better for
securing the routers themselves.

-David

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: key change for TCP-MD5

[Randy Bush]

>> All the multiple keys do is to decrease the cost of the DOS.
> Yes

let's try to remember that, in reality, this is all about allowing
two bgp peers to move to a new key without having the operators on
the phone to keep the bgp session from resetting.  i.e.,

  o it will be uncommon that there is more than one key active
at any one time

  o it is not expected that there are more than two, current and
new (soon to be current and old:-) active at any one time

smb is proposing a simple, compatible, unilaterally implementable,
and unilaterally deployable hack to solve a real ops problem.

the RSs aside, a lot of very big and small networks use tcp/md5 on
their bgp sessions, and key roll is a major pita and therefore a
serious barrier to good key hygiene.

randy

Re: key change for TCP-MD5

[Ross Callon]

At 07:29 PM 6/20/2006 -0400, Richard A Steenbergen wrote:

On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote:
...I'd still like someone to explain why we're wasting man hours, CPU time,
filling up our router logs, and potentially making DoS easier, for an
attack that doesn't exist


I think that it does make sense to be clear what attack
or set of attacks we are trying to protect against.

One type of attack is the TCP reset attack. I personally don't
have a strong opinion regarding whether it is worth protecting
against only this attack.

Another potential attack is an attempt to insert information
into a BGP session, such as to introduce bogus routes, or
to even become a "man in the middle" of a BGP session. One
issue that worries me about this is that if this allows routing to
be compromised, then I can figure out how to make money off
of this (and if I can think of it, someone even nastier will probably
also think of this). Of course this would be much more difficult to
pull off, and might require viewing packets between routers to pull
off, but if pulled off and not quickly detected could be unfortunate.

Ross

RE: key change for TCP-MD5

[Ross Callon]

At 04:23 PM 6/20/2006 -0700, Bora Akyol wrote:

...The DOS is a concern whether you have a valid key or not, correct?


Yes, People who do NOT have a valid key can certainly launch
DOS attacks.


I can DOS the router with fake packets that it needs to verify as long
as I want.


Yes, but the attack needs to get past whatever packet filters
(ACLs) are between them and the CPU that they are trying
to overwhelm. This might include packet filters on ingress to
whatever network the attacker is in, packet filters on ingress
to the network of the victim, or on ingress to the router under
attack.


All the multiple keys do is to decrease the cost of the DOS.


Yes


...For example,
if we allow 4 keys at a time and the router dies at a 100 Mbps
attack traffic, now it will die at 25 Mbps. While this may look like a
big
deal, I think the dark side has enough firepower that essentially 25
equals 100.


There are of course two multiplicative effects: The effect of using
authentication at all, and the effect of having multiple keys active
at once. However, yes, the effect of having "n" keys active at once
is no worse than n times the effect of using authentication.


If DOS is such a large concern, IPSEC to an extent can be used
to mitigate against it. And IKEv1/v2 with IPSEC is not the
horribly inefficient mechanism it is made out to be. In practice,
it is quite easy to use.


Well, this one comment is the one that I don't understand. I
don't see how IPSEC mitigates against DOS attacks. In fact, it
seems to make things worse, since it hides the TCP header.

If a packet is authenticated at the TCP level, then the attack
packet needs to get past (hopefully line rate) packet filters on
the IP header, and some fields in the TCP header before it can
contribute to the DOS attack (but it can still contribute to DoS
even if the authentication fails). If the TCP sequence number is
out of range, then a smart implementation may indeed discard
the packet before checking the authentication, but it still likely
has gotten past the packet filters and gotten to the CPU.

If a packet is authenticated using IPSEC (between IP and TCP),
then it only needs to get past the IP packet filters before it can
contribute to the DOS, and doesn't need to get past whatever
checks occur at the TCP level (including not having to get past
the sequence number check prior to having the authentication
checked).

Ross

Re: key change for TCP-MD5

[Randy Bush]

 The added cost for CPU-bound systems is that they have to try
 (potentially) multiple keys before getting the **right** key
 but in real life this can be easily mitigated by having a rating
 system on the key based on the frequency of success.
>>> This mitigates the effect of authenticating valid packets. However,
>>> this does not appear to help at all in terms of minimizing the DOS
>>> effect of an intentional DoS attack that uses authenticated packets
>>> (with the processing time required to check the keys the intended
>>> damage of the attack).
>> gstm
> this doesn't help if the vendor can't implement it
> correctly and does the md5 calc before checking the ttl :(

hard to imagine anything that will help such a vendor

randy

Re: key change for TCP-MD5

[Jared Mauch]

On Tue, Jun 20, 2006 at 05:18:20PM -0700, Randy Bush wrote:
> 
> >> The added cost for CPU-bound systems is that they have to try
> >> (potentially) multiple keys before getting the **right** key
> >> but in real life this can be easily mitigated by having a rating
> >> system on the key based on the frequency of success.
> > 
> > This mitigates the effect of authenticating valid packets. However,
> > this does not appear to help at all in terms of minimizing the DOS
> > effect of an intentional DoS attack that uses authenticated packets
> > (with the processing time required to check the keys the intended
> > damage of the attack).
> 
> gstm

this doesn't help if the vendor can't implement it
correctly and does the md5 calc before checking the ttl :(

- jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.