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

[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" 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. 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"
> > 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. 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 *****.

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 bull****. 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" 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.

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.

[Anonymous Sender]

VanguardLH wrote:

It might help the flow of things if you'd quote some of what you're
replying to....


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

Technology advances. Leaps forward are made in various areas and the
people who are involved in projects which secure data both respond
proactively, and re-actively. Most often proactively, and/or in
response to perceived demands regardless of how valid they are. EV is
an example of the latter. They even market it as such quite plainly.

Why would you need to try and paint the natural evolution of encryption
and security protocols as some sort of failure, when it's actually an
advantage?

> http://www.verisign.com/ssl/ssl-info...ded-validatio=
n-ssl-certificates.html
>=20
> Are all current sites that implement SSL certs required to migrate to=20
> 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.

EV certs are easily distinguishable from "standard" certs.

You should have read your own cite.

In any case, this has little or nothing at all to do with MITM attacks.
EV certifications add trust to the CA signature, not the certificate
itself in this trusted/untrusted context. The problems and
errors/warnings we're dealing with here won't be impacted at all
because that's not the attack vector we're discussing. We're talking
about forging previously known certificates, not getting people to
install bogus certificates as trusted authorities.

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

Irrelevant. MITM attacks aren't launched by holders of valid
certificates, even older ones issued under less secure trust models.
Logically they don't have to be. The question here isn't how secure a
good certificate is, it's how detectable an obviously bad certificate
is. SSL has been hardened against that since about forever. That's why
it exists essentially as an "extension" to plain vanilla encryption.

> As I recall, one of the improvements to IE7 was it alerts when an EV=20
> SSL cert is being proffered. I suspect that IE7 still relies on the=20
> "Trusted Root Certification Authorities" list. Is that list truly=20
> static that no one else after the list was created can become a root=20

Of course it's not static, nor does it need to be. It would break if it
were in fact.

> CA? And does an SSL cert only become accepted by the browser only=20
> where a root CA from this list is in their certs CA hierarchy? If

No, there's several methods for accepting certificates. That's
precisely what we're discussing here. Certificates with no Root CA
signature or unknown Root CA signatures are presented to the user for
approval just as they should be. Users can chose to accept, install, or
reject those certificates. If you're visiting a bank site through Tor
and see this warning, or visiting a bank site you've previously visited
at ALL and get this warning, you need to learn to not be a fool and
blindly accept things.

It really is just as simple as that...

> so, does alerts popup all over because the CA came from the
> "Third-Party Root Certificate Authority" list?

Of course it does. For a party to get on the "First Party" Root CA list
that's exactly the process that has to occur.

> Versus EV or HA certs, you have heard of low-assurance certs. "Some=20

Yes. They generate warnings and I choose to accept them or not based on
what I know about the certificate, and what I was doing at the time. IN
fact in my software even shiny new EV certs generate the same
warnings.

> 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"=20
> (http://www.us.kpmg.com/RutUS_prod/Do...2/DC80502.pdf). So,=20
> since 2002 when this report was issued, have these low-assurance CAs=20
> been wiped from the face of the Earth?

No need to be. You just don't trust them as you would a normal
Authority.=20

> Seems a bit odd that cybersoft.com would patent=20
> (http://www.freepatentsonline.com/20020129237.html) a process for SSL=20
> interception that you say is impossible; see=20

<chuckle>

You obviously don't understand what you're reading at all. There's
nothing about 20020129237 that says anything about intercepting SSL
encrypted passwords or anything else. Nada. It's a patent on certain
technology that identifies SSL traffic itself and segregates it, not
subverts it (although if the underlying encryption isn't strong that
could happen after a few million years of cryptanalysis).

> http://www.cybersoft.com/products/nticry.shtml. Since this was back=20
> in 2000, seems a bit odd that you don't know about SSL interception.=20

It doesn't seem odd at all that you'd confuse interception of traffic
with actually decrypting an SSL data stream, after seeing you
misrepresent things you blindly cut and paste from sources you don't
understand. Wild ass grasping at straws and guessing often do lead to
that sort of confusion.

> The company still exists. I doubt they would survive if they sold a=20
> product that didn't deliver [some of] its promises.

They're not promising anything like what you have fooled yourself into
believing they promised. You must have been oblivious to the fact that
not all SSL encrypted traffic is easily distinguishable from other
encrypted traffic, and being as secure and flexable as it is SSL often
gets abused in the corporate world as a way to bypass company imposed
limitations and restrictions.

There's much value in simply identifying SSL traffic itself and
determining it's origins without every even trying to decipher its
contents. A whole cottage industry revolves around this cat and mouse
game in fact. You've just stumbled across that industry, and mistaken
it for something it's not.

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

Not one person said it was impossible, lair. In fact the specific
conditions that make it possible have already been offered for your
perusal if you had known what you're looking at. They won't exist at
Tor nodes because they can't. Tor nodes don't have direct control over
your machine. The only other options is "fooling" users into accepting
bogus certificates in spite of all the warnings.

That's what we're discussing here and now.

Ironically amusing as it is, even your NATO cite recognizes the fact
that the sort of mucking around you're claiming is possible generates
warnings in unmolested clients...

"The proxy masquerades the server=E2=80=99s certificate and presents it to =
the
client. Depending on the application service requested the client would
receive a warning concerning the server=E2=80=99s certificate. This can be
eliminated by adding the proxy=E2=80=99s certificate to the client=E2=80=99=
s trusted
Certificate Authority (CA) list."

You really SHOULD learn to read your own cites, don't you think?

If someone owns your box they can do anything they damned well please
with it. That includes installing their own cert as a Trusted CA and/or
configuring away any warnings and dialogs they please.

Why this looks like something "special" to you can only be guessed at,
and mine would be a combination of willful ignorance and laziness. You
desperately want to believe something that's not true, and you seem to
lack the motivation to even casualy browse through the stuff you're
quoting.

I see that as rather pathetic actually. =20

[Nomen Nescio]

Andy Walker wrote:

> VanguardLH wrote:
>=20
> >A bit odd that NATO would waste their time describing MITM for SSL=20
> >interception=20
> >(http://ftp.rta.nato.int/public//PubF...IST-041/MP-IS=
T-041-19.pdf)=20
> >if, according to you, it were impossible.
>=20
> 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.

I feel sorry for and amused by people who don't read their own cites...

"SSL traffic is largely unmanageable using the suite of available
network security tools and devices. At the most exhaustive level,
payload analysis of every packet on the wire yields gibberish when
dealing with encrypted traffic."

And...

"The proxy masquerades the server=E2=80=99s certificate and presents it to
the client. Depending on the application service requested the client
would receive a warning concerning the server=E2=80=99s certificate. This c=
an
be eliminated by adding the proxy=E2=80=99s certificate to the client=E2=80=
=99s trusted
Certificate Authority (CA) list.

Once the masqueraded certificate is accepted, the proxy completes the
SSL handshake with the client=E2=80=99s original destination."

What part of "adding to the trusted CA list" and "once the masqueraded
certificate is accepted" is so confusing? And what par of a Tor node
not having the sort of control necessary to do either to your browser is
it that's so hard to understand?

I'll do my best to bring you up to speed if you state your problems in
a clear and concise manner, but hurling childish epithets will only
result in your continued embarrassment.

Up to you. :-/

[Anonymous]

Joan Battaglia wrote:

> On Fri, 26 Oct 2007 20:51:05 +0000 (UTC), Anonymous Sender wrote:
>
> >> http://arstechnica.com/news.ars/post...passwords.html
> > You do realize that *none* of those passwords were intercepted from
> > encrypted connections, right?
> > Simple common sense would have prevented 100% of this.
>
> 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.

IOW, Tor has no real impact on SSL at all. It's no more vulnerable when
routed through the Tor network than it is outside the Tor network.

[Anonymous]

Joan Battaglia wrote:

> On Fri, 26 Oct 2007 21:07:50 -0500, VanguardLH wrote:
>
> > Don't trust your bank accounts, online buying, PayPal, login
> > passwords, or any other privacy data over Tor. What you send to the
> > target site is obviously available to a Tor operator, too.
>
> I'm not sure I understand the bottom line.
> Are you saying BOTH http and https are compromised when one uses a Tor?

Of course not. It simply gives amateur crackers a slightly easier point
from which to launch attacks that fail or succeed based on things that
have absolutely nothing at all to do with Tor. Or more precisely,
things that fail or succeed based on how under- or misinformed the end
user is.

This "Tor lets you break SSL" FUD is nothing more than the very same
misinformation that leads to people being compromised. It clouds the
real issues and diverts attention away from the real strengths and
weaknesses of encrypted layered networks.

> In other words, does Tor give us anonymity but not privacy?

Tor gives you both, but privacy in most ways ends where Tor ends. That's
why you need to use things like SSL for browsing and PGP for email.

> Or, can we use https for the privacy and http for the anonymity?

Plain vanilla HTTP offers neither.

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.

> Sorry I'm confused.

It is confusing at first. Think of it like plastic pipe. HTTP is a
clear pipe running from you to your destination. Anyone can see through
the pipe and know everything that flows through it. They can also
follow the pipe from beginning to end very easily.

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.

SSL/HTTPS is like a single black pipe running between you and your
destination. It's trivial to follow that pipe from end to end and know
who the source and destination are, but nothing flowing inside the pipe
is visible.

Combining Tor and SSL/HTTPS puts a bunch of black pipes inside a larger
black pipe for a time, but then those smaller pipes still retain their
opaque quality after leaving the Tor pipe. So you not only have the
anonymity of hiding your connection inside a "larger pipe" mixed up with
everyone else's, you still maintain privacy because nobody can see
what's flowing through the connection once it leaves that collective.

HTH.

[Anonymous Sender]

Anonymous Sender wrote:

> VanguardLH wrote:
>
> It might help the flow of things if you'd quote some of what you're
> replying to....
>
>
> > Please explain why, if the old SSL model was so secure and could not=20
> > be corrupted by MITM attacks or spoofing, that now Verisign offers=20
> > "high assurance" or "extended verification" certs. If the previous=20
> > and still existing SSL model was/is so great, gee, now why would
> > there be a need to improve it.
>
> Technology advances. Leaps forward are made in various areas and the
> people who are involved in projects which secure data both respond
> proactively, and re-actively. Most often proactively, and/or in
> response to perceived demands regardless of how valid they are. EV is
> an example of the latter. They even market it as such quite plainly.

Indeed. It's essentially a marketing gimmick response to users who
really don't know what to believe in not feeling "safe" doing their
shopping on line. Mostly because of the same misinterpretation and
misrepresentation of fact that we're seeing right here in this group.

It's a story as old as the net. Rumors get started, people demand
solutions to problems that don't really exist, the industry responds,
and people end up being less safe because they're relying on flash and
fluff rather than common sense and applied IQ.

People like Vanguard and Andrew are part of the problem, not the
solution.

> > Are all current sites that implement SSL certs required to migrate to=20
> > 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.
>
> EV certs are easily distinguishable from "standard" certs.

Indeed again. IE7 supports them and distinguishes then visually, as does
Firefox 3 (and 2 with the proper plugin). as well as Opera. Not sure
about "lesser" browsers, or how console based browsers like Lynx
support or handle them, but the general pattern is to turn things green
and display the EV trusted certificate owners identification.

> In any case, this has little or nothing at all to do with MITM attacks.
> EV certifications add trust to the CA signature, not the certificate
> itself in this trusted/untrusted context. The problems and

Indeed again. There's nothign about EV certificates that make them
significantly more suitable for detecting completely bogus certificates
swapped for good ones. SSL has had this ability built into it for about
as long as I can remember.

<snipped for brevity>

> If someone owns your box they can do anything they damned well please
> with it. That includes installing their own cert as a Trusted CA and/or
> configuring away any warnings and dialogs they please.

That's the skinny. And by owning your box you have to include owning the
operator. If they can fool you into accepting bogus certs then they
have you too.

Fortunately it's child's play to avoid being fooled as long as you have
some basic and ACCURATE information.

[Anonymous]

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.

NOTE: Some paranoid users will delete all their preinstalled CA
certificates and add them manually as needed, only after carefully
verifying each one.

NOTE2: CA's aren't perfect. And an attacker (or boss) who controls your
machine and wants to snoop your private connection can insert their own
certificate as belonging to a trusted authority. These are a good
reasons to be one of those paranoid type users.