Doctor Who

On Fri, 26 Oct 2007 05:00:48 GMT, Joan Battaglia <joanmaxwell@sbcglobal.net> wrote:

>Thanks to you all, I was able to install Tor/Vidalia/Privoxy freeware for
>anonymous web browsing.
>
>When I log into an https email web page, I assume my password is protected
>from snoopers on the Tor network itself. That is, I assume the https
>encryption prevents a rogue Tor server itself from seeing my password.
>
>But - what about if I have to log into a web page that does not have an
>https encrypted login method? Is Tor now compromised? Am I now sending my
>password in the clear to a Tor server which "could" be a rogue Tor server?
>
>Is my password still secure when logging into an http account with
>Tor/Privoxy running?

Tor offers anonymity, but if the last Tor node is malicious it could read non
encypted data, meaning HTTP, for example. With HTTPS your browser
should be set to alert you if therer is a change of certificate.

I would strongly urge you never to use Tor for login to your Bank account.
Pretty pointless in most cases as they already know you. Different, of course
if you have a secret overseas account, ahem. . .

VanguardLH has pretty much covered most of your points.

Joan Battaglia

On Fri, 26 Oct 2007 20:27:10 +0100, Doctor Who wrote:
On Fri, 26 Oct 2007 20:27:10 +0100, Doctor Who wrote:
> I would strongly urge you never to use Tor for login to your Bank account.

I'm more worried about my email account.
The basic question I am asking is this.

Given that using Tor to access http-based email accounts (eg
http://mail.yahoo.com) is KNOWN to be passing your password to the Tor
operator - the question was if using https-based email (eg
https://mail.google.com) provided any protection of the password from the
rogue Tor operator.

Sorry for not understanding. Can a one-word answer suffice?

Does https protect the password from Tor - or not?

Andy Walker

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
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.

Ari

On Sat, 27 Oct 2007 13:54:59 -0400, 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
> 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.

Recirded, yes, read, less probable.
--
"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

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.

Fritz Wuehler

Andy Walker <awalker@nspank.invalid> wrote:

> 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.

And the client would warn its user because it doesn't recognize your bogus
authority. Unless you install your bogus CA certificate as trusted certs
into the client. You failed to answer that part again.

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" bullshit.

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. You cannot
establish an authenticated session with a "honest to dog" cert signed by an
"honest to dog" CA. You probably don't even get the fingerprint right, that
the bank handed out to their clients on paper.

Why do you think anyone would pay good money for certificates if every Andy
Walker and his dog could fake one?

Nomen Nescio

Fritz Wuehler wrote:

> Andy Walker <awalker@nspank.invalid> wrote:
>
> > 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.
>
> And the client would warn its user because it doesn't recognize your
> bogus authority. Unless you install your bogus CA certificate as
> trusted certs into the client. You failed to answer that part again.

Precious few reasons for that.

> 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.

There *have* been known cases where CA's were a little "lax" in the
verification process, but those CA's don't last long, And even if they
do manage to slip through the cracks from time to time we're still
talking about certificates that are without any realistic probability
of the contrary, going to be existing certificates on the client's
machine. The problem will at the very least be a differing certificate,
then one that doesn't match the destination, and then of course the CA
issues.

Yes, I see teh CA issue itself as a tertiary issue because the others
are going to be so much more visible no matter how "trusted" a bogus
certificate is at face value.

>
> > 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"
> > bullshit.
>
> 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. You
> cannot establish an authenticated session with a "honest to dog" cert
> signed by an "honest to dog" CA. You probably don't even get the
> fingerprint right, that the bank handed out to their clients on paper.

Thank you. I was actually wondering if I hadn't horribly misread what
Andrew wrote it was so utterly ridiculous.

All his attacks hinge on the fact that he can modify the client's
software directly so that it will accept his bogus certificates.
Without that key element they fail miserably. Nobody has ever denied
this was possible, or even improbable in a strictly monitored and
controlled environment like a business or military arena. Nobody can
deny the fact that it's impossible for a Tor node to do it.

> Why do you think anyone would pay good money for certificates if
> every Andy Walker and his dog could fake one?

They wouldn't of course. And they don't. Nor does sane software accept
certificates that haven't gone through that process without
complaining.

Anonymous

Andy Walker wrote:

> 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

No, you can't. You can only load your own certificates and then
substitute those for the ones used by the users intended target site.
Which is trivial to spot if you haven't disabled the inevitable
warnings and alerts.

Apparently your grasp of networking and SSL is so utterly embryonic you
don't even realize that SSL is based on a PKI. Which places your "we do
this at work" banter squarely in on the side of the fence marked "bald
faced lie". You don't really have a clue what the IT people at your
place of work actually do, you're making wild ass guesses based on blind
speculation fueled by what someone told you at the company Christmas
party after three too many glasses of cheap swill.

That about right? ;=)

In case you were actually wondering, PKI or Public Key Infrastructure
means that there's a private and a public component to each encryption
key. The public portion is what's distributed, and it's only used to
encrypt data back to the originator (and verify hashes). YOu can't
encrypt data with it and still have decrypt using the same key, so
unless you've broken into "www,mybank.com" and stolen their private
key, you're entire "use the same certificate as the other site" rant is
nothing but pure, unadulterated. *bull shit*.

And I know for a *fact* that's right.


> 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.

Utter bullshit. You start swapping certs and you generate errors.
Period. Unless you have pure autonomy over the client. Period.

> Better still, if I control
> your DNS I can make your client think I've got a honest to dog EV Cert

DNS spoofing has been around as a ready-made adversary to SSL since '99
as far as I'm aware. It doesn't solve a single problem we're discussing
here. You still generate warnings in unmolested clients.

> with the green address bar and the feel good "verified by" bullshit.
> 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.

How clueless people are isn't the issue, nor are your ego stimulated
bogus estimations of such. In any case, clueless can be fixed most of
the time. But certainly not by spreading the sort of FUD and outright
bovine excrement you're layering on here.

Anonymous Sender

Joan Battaglia wrote:

> 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.

Then by your own words you wouldn't be fooled, as you only *use* to
blindly accept certs, and in spite of what Andrew tries to mislead
you into believing you *would* see those same warnings issued by all
modern browsers at their default settings, and most other software.

Even certs signed by Trusted CA's generate errors when they don't match
the site you're visiting, and they would not because they're not issued
in that name. Whether what you type into a navigation bar or click on
is seen by proxy or not is irrelevant. The site you're ultimately
visiting is ABC.com and the cert you're seeing from the proxy belongs
to XYZ.com. The fact that it's signed by a trusted authority actually
strengthens that security ad increases the validity of the alerts and
errors, not diminishes them.

Yes, a "high trust" certificate belonging to a third party used in a
data stream is even more obviously erroneous than an "iffy" certificate
substituted for a Joe Blow site's.