How safe is Tor for logging into http (nont https) web sites

[VanguardLH]

So a cert is not alerted against if a root CA is listed in the
heirarchy of CAs? Okay, so if the list of root CAs is not static
(which it can't be) then it can get updated. When you THINK you are
visiting your bank's web site and get prompted to accept their cert,
are you really going to say no? After all, you went there to use
their site and won't be able to use their HTTPS interface unless you
accept their cert and obviously you are going to assume that you
really are at their site. Otherwise, no matter if you were using Tor
or not, you would never know you were truly at the intended site and
would always refuse any certs which means you never get to do your
banking online.

Whether or not you are using Tor, and when you get your bank's cert
info, to just what CA are you going to authenticate that cert? Isn't
it the one specified within the cert itself? And if the CA isn't
currently listed in your list of trusted root CAs, are you really
going to deny the cert from the site you think you are visiting? Are
you going to verify the root CA listed in the cert which is not
currently in your trusted root CAs list is actually an authorized root
CA? How much research do you expect normal users to commit in
researching the proposed cert before accepting it? No site gets an
infinite lifed cert. They expire. Sites change their certs. Sites
change or add domains and need new certs. So a site that you've
visited before that wants you to save the new one isn't something
rare. Your bank has never changed their cert or somehow managed to
have one that lasted for decades while the rest of us only get one
that lasts for a year?

[VanguardLH]

"Anonymous" <nobody@remailer.paranoici.org> wrote in message
news:6045421bc866304696ca70701e0b9631@remailer.par anoici.org...
> VanguardLH wrote:
>
>> To shorten the arguments, just which CA is used to verify a signed
>> certificate?
>
> That depends on which CA is used to sign that verified certificate.
>
>
> There's a number of trusted authorities. Most (all?) browsers ship
> with
> a standard set, and the checking is done automatically unless you
> examine certificates manually. That's what the errors and warnings
> are
> suppose to prompt you to do... manually verify the certificate and
> accept it or reject it based on your own trust model rather than
> Verisign's, or Thawtes's.


So the CA hierarchy listed in the cert is used. The trusted root CA
list is not static and can be updated or modified, or the cert simply
accepted despite not including an already listed root CA without
updating the root CA list.

The point of SSL was so users would know they were using encrypted
communications but to the expected target site. Watch users. How
many go researching whether the root CA listed in the hierarchy in a
cert is a validly authorized root CA. Say you have never heard of
geoTrust but that's the root CA for a cert from the site you THINK you
visited. You find geoTrust's web site. Looks legit but how are you
going to verify it isn't another web site dedicated to the spoofing of
the MITM site that you actually ended up visiting? Remember that even
root CAs self-sign their own certs. It is required because, well,
they are the root. While some users, not all, have heard of Verisign
and would probably trust those rooted certs without further
investigation, how many that are even moderately aware of using SSL
certs would've heard of CA 1, C&W, Comodo, SIA, etc?

SSL was supposed to *enable* trust, not engender distrust in having to
do all the research to investigate the cert. For users to have the
wherewithall to do that investigation, they would already have the
expertise needed to determine whether the route they took actually
ended at the target site and the intervening hops in that route were
trustworthy.

Since you mentioned the paranoid clearing out the root CA list and
always manually intervening to select which ones to trust (provided
they have previously thoroughly investigated them), and of your boss
or other malcontent adding a root CA, then obviously malware could do
the same by adding a root CA so your browser trusts it and won't alert
when that malware redirects you from the intended target site to the
spoofed site.

All this work expected (by you) on the user to validate SSL certs goes
against the intented purpose of those certs. The normal user expects
to trust a site they think they are visiting because it gave them an
SSL cert that is *supposed* to be validated by someone other than that
site. SSL works on trusted 3rd parties. Normal users don't go
investigating WHO are those trusted 3rd parties. Yes, you could do
all the investigating or checking that you mention. Distrusting SSL
certs what not why this scheme was created.

[Krazee Brenda]

On Sun, 28 Oct 2007 03:30:05 +0100 (CET), Nomen Nescio wrote:

>>> Baloney. There's perfectly good reasons for conducting sensitive
>>> business through Tor, in fact certain scenarios within that context are
>>> the reasons Tor exists in teh first place. And there's secure ways of
>>> doing just that. All you need to do is learn some basics, and pay
>>> attention to any warnigns or errors you get.
>>=20
>> Here's mustard for your Baloneyware.
>>=20
>> http://www.derangedsecurity.com/
>
> Some cites from your own cite, just to demonstrate what a clueless
> tool you really are to anyone who isn't already aware. Not that I
> believe there's many of them left at this point...
>
> "ToR isn't bad! Every time you do anything unencrypted you are at risk
> even when you don't use ToR. When you put in a password on a site or
> log on a pop3 unencrypted your password can be stolen, you are sending
> it clear-text. You know nothing about who will be listening in and
> sometimes you don't even know anything about the site you are
> communicating with."

I never said ToR was bad, I said, and it is proven, ToR can be busted.
Is this news to you? Apparently,. Your argument is that if the data is
encytped, then ToR is fine? Ya' think? Really? For sure on that? Learn
this in Comp Science 201? Last year?
--
"I drink lots of water, know how to make bee's wax candles, play with
clay, eat mangoes nude, give great massages."

[Ari]

On Sun, 28 Oct 2007 10:24:30 +0100 (CET), Anonymous wrote:

> You can use Tor for anonymity, and privacy on your end of the network
> because it keeps your data safe from eavesdroppers until it leaves the
> Tor network. There's also an element of privacy added by Tor to the
> other end of the connection as long as you don't specifically transmit
> privacy-trashing data like user names and passwords. Since your
> identity is disassociated from any content, your privacy is maintained
> as long as the content doesn't reveal anything that identifies you.
>
> You can use HTTPS/SSL/etc for end-to-end privacy. That's what it was
> designed for. The encrypted connecting is established and maintained
> between you and the specific site you're doing business with. It's a
> very robust channel when used properly. The keys to using it properly
> are using modern software and paying attention to what's on your screen.

Which is where this entire argument pro-Tor falls apart operationally.
Joan Battawhatever is the perfect example. She *may* get this right but
look at the number of days this thread has circled? She's still in a
plane with no ****ing landing strip in sight. And what is she? .0001% of
the using population? See any other noobs wading through these bull****
theoretical, operationally inconsequential blabberings?

Nope, there is *no* safety, security or anonymity for the vast majority
of the user population and I doubt there ever will be.

Conclusion:

How safe is Tor for logging into http (non https) web sites?

As aafe as your expertise.

How safe is Tor for logging into http (non https) web sites *in a real
world, User population.

Unsafe.
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

[Ari]

On Sun, 28 Oct 2007 10:24:30 +0100 (CET), Anonymous wrote:

> Tor is like a large black pipe, with a whole bunch of smaller pipes
> running inside it all exiting out the other end and going their own
> way. While your connection is inside the black pipe nobody can see it.
> Once it leaves that outer covering at the Tor exit node it's in the
> clear again. But since there's thousands upon thousands of smaller
> pipes all mixed up inside the "Tor pipe" nobody can really figure out
> which pipe belongs to which user.

Nobody? Aw, Jesus H. Christ, whom my people killed lol, nobody? Live
beyond your 20x30 data center, then call me. We can talk about how real
adversaries operate.
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

[Ari]

On Sun, 28 Oct 2007 10:23:23 +0100 (CET), Anonymous wrote:

>> I'm soooooo confused by all the details! Sorry.
>>
>> It seems you are saying two things here (are you?)
>> 1. Using http://mail.yahoo.com is not safe over a Tor network
>> (because the Tor operator gets your password every time)
>> 2. Using https://mail.yahoo.com is safe (is it?)
>
> Yes. That is correct.
>>
>> The whole point of this question was to ask if http(s) protected my
>> password from recreant Tor operators. Does it or does it not?
>
> It absolutely does, as long as acceptable standards of SSL use are
> adhered to. And of course assuming nobody finds a hole in SSL itself.

And if the moons rise above the planet and giants eat Mars thinking it's
a candy bar.
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

[Krazee Brenda]

On Sat, 27 Oct 2007 21:36:06 -0400, Andy Walker wrote:

> Nomen Nescio wrote:
>
>>No, Tor doesn't change the fact that SSL has safeguards against MITM
>>attacks built into it. You're misunderstanding something you've read,
>>and you're spreading FUD as a result.
>
> Guess again Skippy, we do it in-house to scan SSL sessions for data
> leaks and malicious content.

Peanutbutterware
--
"I drink lots of water, know how to make bee's wax candles, play with
clay, eat mangoes nude, give great massages."

[Ari]

On Sun, 28 Oct 2007 06:54:36 +0100, Fritz Wuehler wrote:

> SSL certificates rely on the integrity of trusted CAs. Verisign signs your
> certificate request for foo.bar.com only if they can verify (veri-sign,
> clever, eh?) your authority over the real foo.bar.com. They won't sign a
> certificate for your little proxy scheme.
>
>> Better still, if I control
>> your DNS I can make your client think I've got a honest to dog EV Cert
>> with the green address bar and the feel good "verified by" bull****.
>
> Worse still, it would not be valid because you simply do not possess the
> secret key tied to the certificate signed by a trusted CA.

Which can't be trusted completely in the first place.
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

[Nomen Nescio]

Ari wrote:

> On Sun, 28 Oct 2007 10:24:30 +0100 (CET), Anonymous wrote:
>
> > Tor is like a large black pipe, with a whole bunch of smaller pipes
> > running inside it all exiting out the other end and going their own
> > way. While your connection is inside the black pipe nobody can see it.
> > Once it leaves that outer covering at the Tor exit node it's in the
> > clear again. But since there's thousands upon thousands of smaller
> > pipes all mixed up inside the "Tor pipe" nobody can really figure out
> > which pipe belongs to which user.
>
> Nobody? Aw, Jesus H. Christ, whom my people killed lol, nobody? Live
> beyond your 20x30 data center, then call me. We can talk about how real
> adversaries operate.

Right. You don't even know what torify is, but you're some sort of
expert on how to crack Tor.

*chuckle*

Watching you appear, make a fool of yourself, and then melt down is
always a good show Ari.

[Anonymous]

Krazee Brenda wrote:

> >> http://www.derangedsecurity.com/
> >
> > Some cites from your own cite, just to demonstrate what a clueless
> > tool you really are to anyone who isn't already aware. Not that I
> > believe there's many of them left at this point...
> >
> > "ToR isn't bad! Every time you do anything unencrypted you are at risk
> > even when you don't use ToR. When you put in a password on a site or
> > log on a pop3 unencrypted your password can be stolen, you are sending
> > it clear-text. You know nothing about who will be listening in and
> > sometimes you don't even know anything about the site you are
> > communicating with."
>
> I never said ToR was bad, I said, and it is proven, ToR can be busted.

Nothing of the sort has been proved. Tor has not been "busted" by
anyone. The only successful "attacks against Tor" have employed methods
that Tor was never designed to protect you against. Things that are
clearly and concisely explained in Tor's documentation, on its web site
and all it's mirrors, and dozens if not hundreds of other places across
the net.

Your own cites quite plainly reiterate those same facts and sentiments
whether the disarray in your synaptic pathways allows you to assimilate
the words properly or not.