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

[Nomen Nescio]

Andy Walker wrote:

> Joan Battaglia wrote:
>
> >the question was if using https-based email (eg
> >https://mail.google.com) provided any protection of the password from the
> >rogue Tor operator.
>
> Not if the Tor proxy provides the encryption for the mail.google.com
> site. In which case the Tor site would establish an encrypted session

If a Tor node could do this then SSL is horrifically broken. If you
have an actual example of anyone doing this, you need to contact the
developers of SSL immediately.

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.

> with your browser, decrypt the traffic as it passes through their
> servers, and then re-encrypt the traffic as they establish the
> connection to mail.google.com. Unless you are absolutely certain that
> the certificate your browser is using to encrypt the session with is
> from the intended destination, there a possibility that everything you
> send is being recorded.

Fortunately for users, SSL's primary goal is to assure that the
certificate you're using is genuine. The encryption itself is
essentially a secondary concern. Indeed, it's not part of SSL itself at
all, but an implementation of something developed by other people. SSL
is at its core the protocol that makes establishing secure encrypted
sessions possible.

[Andy Walker]

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.

[VanguardLH]

To shorten the arguments, just which CA is used to verify a signed
certificate?

[Nomen Nescio]

Krazee Brenda wrote:

> On Sat, 27 Oct 2007 10:28:46 +0000 (UTC), Anonymous Sender wrote:
>=20
> >> Don't trust your bank accounts, online buying, PayPal, login=20
> >> passwords, or any other privacy data over Tor. What you send to the=20
> >> target site is obviously available to a Tor operator, too.=20
> >>=20
> >=20
> > 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."

"The person who wrote the security policy on these accounts should
reconsider changing profession, start cleaning toilets! These
administrators are responsible for giving away their own countries
secrets to foreigners. I can=E2=80=99t call it a mistake, this is pure
stupidity and not forgivable!"

"Five ToR exit nodes, at different locations in the world, equipped
with our own packet-sniffer focused entirely on POP3 and IMAP traffic
using a keyword-filter looking for words like =E2=80=9Cgov, government,
embassy, military, war, terrorism, passport, visa=E2=80=9D as well as domai=
ns
belonging to governments."

"ToR isn=E2=80=99t the problem, just use it for what it=E2=80=99s made for."

Doe your tiny little brain have the ability to wrap itself around all
that? The fact that Tor isn't the problem, or a risk, it's unencrypted
connections that compromised ALL the accounts in question?

It probably does, you're just too immature to admit it.

[VanguardLH]

Please explain why, if the old SSL model was so secure and could not
be corrupted by MITM attacks or spoofing, that now Verisign offers
"high assurance" or "extended verification" certs. If the previous
and still existing SSL model was/is so great, gee, now why would there
be a need to improve it.

http://www.verisign.com/ssl/ssl-info...tificates.html

Are all current sites that implement SSL certs required to migrate to
EV certs? No, but they can *optionally* upgrade. Will users know the
difference? No. They see the padlock in the browser for the cert
proffered by an SSL-enabled site but whose CA is not a root CA. Have
all the SSL-enabled sites that you visit always use HA certs? No. In
fact, seeing the HA indicator in IE7 is unusual, not the norm. But
then the HA cert simply has the *trusted* CA to include validated info
in the cert (domain name, company name, address, city, state,
country).

As I recall, one of the improvements to IE7 was it alerts when an EV
SSL cert is being proffered. I suspect that IE7 still relies on the
"Trusted Root Certification Authorities" list. Is that list truly
static that no one else after the list was created can become a root
CA? And does an SSL cert only become accepted by the browser only
where a root CA from this list is in their certs CA hierarchy? If so,
does alerts popup all over because the CA came from the "Third-Party
Root Certificate Authority" list?

Versus EV or HA certs, you have heard of low-assurance certs. "Some
CAs now issue low-assurance server certificates without authenticating
the subscriber, thereby providing only two security services -
confidentiality and integrity. Using current browser technology, it
is very difficult for an Internet user to dinstinguis between higher-
and lower-assurance server certificates"
(http://www.us.kpmg.com/RutUS_prod/Do...2/DC80502.pdf). So,
since 2002 when this report was issued, have these low-assurance CAs
been wiped from the face of the Earth?

Seems a bit odd that cybersoft.com would patent
(http://www.freepatentsonline.com/20020129237.html) a process for SSL
interception that you say is impossible; see
http://www.cybersoft.com/products/nticry.shtml. Since this was back
in 2000, seems a bit odd that you don't know about SSL interception.
The company still exists. I doubt they would survive if they sold a
product that didn't deliver [some of] its promises.

A bit odd that NATO would waste their time describing MITM for SSL
interception
(http://ftp.rta.nato.int/public//PubF...IST-041-19.pdf)
if, according to you, it were impossible.

[Andy Walker]

VanguardLH wrote:

>A bit odd that NATO would waste their time describing MITM for SSL
>interception
>(http://ftp.rta.nato.int/public//PubF...IST-041-19.pdf)
>if, according to you, it were impossible.

I don't know whether to laugh at or feel sorry for all these clueless
n00bs trying to assume there way out of being wrong. They're easy
targets for anyone who wants to exploit their ignorance.

[Anonymous]

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.

With the proxy running under the 5 versions outdated installation of PHP
you're still using? ;-)

Here's a clue: It doesn't work. Not without exerting physical control
over client softwares and the certificates they accept it doesn't
anyway. You conveniently left that part out, the part about you
mandating security policies, or you're just flat out flinging lies
hoping something will stick.

If you own the client you can make it do anything you want just like
inattentive users can. Accept any bogus certificate you offer, skip any
and all security checks, etc. And it's trivial to proxy SSL connections
themselves. You can even block connections you can't monitor so that
you force your users to use your certificates even if they do figure
out how to reset your broken security to defaults.

Hell, for that matter, readers can use something as simple as stunnel to
proxy SSL certificates locally and do the exact same thing as an
experiment, using a certificate they created themselves and manually
authorized in some client. Works just the same.

Of course not one bit of any of that has anything at all to so with the
subject at hand, so all you've really done here is yap about nothing of
any import. We're not talking about local network administrators
auditing and controlling installed software. Now are we? Hmmmmm??

[Anonymous Sender]

VanguardLH wrote:

> To shorten the arguments, just which CA is used to verify a signed
> certificate?

How does this shorten the argument?

Your browser (or other software) has or should have a list of them
installed by default. It varies from browser to browser, and it can be
modified by you. When you receive a certificate that's not on your list
or signed by a trusted authority on your list, you're shown an error and
presented with options. Exactly like you're warned about certificates
that don't match URL's, or certificates that have changed.

Your software should offer you some sort of way to view the
certificates you've accepted and the ones that were installed by
default. There should be details available regarding who the cert
belongs to, it's "fingerprint", creation/expiration dates, information
about encryption algorithms, and even a URL to the original certificate
on a company server in a lot of cases. If you're in doubt about a
certificateor connection this is the place to start looking for paths
to answers. Even posting a fingerprint in a public forum and asking for
it to be verified by others is preferable to doing nothing or blindly
accepting certificates.

[Andy Walker]

Anonymous wrote:

>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.
>
>With the proxy running under the 5 versions outdated installation of PHP
>you're still using? ;-)
>
>Here's a clue: It doesn't work. Not without exerting physical control
>over client softwares and the certificates they accept it doesn't
>anyway. You conveniently left that part out, the part about you
>mandating security policies, or you're just flat out flinging lies
>hoping something will stick.
>
>If you own the client you can make it do anything you want just like
>inattentive users can. Accept any bogus certificate you offer, skip any
>and all security checks, etc. And it's trivial to proxy SSL connections
>themselves. You can even block connections you can't monitor so that
>you force your users to use your certificates even if they do figure
>out how to reset your broken security to defaults.
>
>Hell, for that matter, readers can use something as simple as stunnel to
>proxy SSL certificates locally and do the exact same thing as an
>experiment, using a certificate they created themselves and manually
>authorized in some client. Works just the same.
>
>Of course not one bit of any of that has anything at all to so with the
>subject at hand, so all you've really done here is yap about nothing of
>any import. We're not talking about local network administrators
>auditing and controlling installed software. Now are we? Hmmmmm??

You really don't get it, do you? If I load a certificate for ANY site
on a proxy and you connect to it, I can make it look like you are
connecting to the site you intended to connect to. True, I can't
change the original information on the originating CA, but then your
client won't be looking for the real CA anyway because the cert is
signed by one of my bogus authorities. 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****.
Does this mean that someone with enough of a clue couldn't detect it?
No, but then there are so many clueless people out there it would
probably fool 99.9% of them.

[Joan Battaglia]

On Sun, 28 Oct 2007 00:21:24 -0400, Andy Walker wrote:
> Does this mean that someone with enough of a clue couldn't detect it?
> No, but then there are so many clueless people out there it would
> probably fool 99.9% of them.

It would fool me. I don't know what to look for.
I just used to say yes to all those popups.