How to tell a fake SSL certificate from a real one

What does a forged SSL situation look like to the user logging into email?
Do you have an example?

I read with interest all the help kindly provided by the likes of helpful
folks like VanguardLH & mark carter & others - which basically concluded
Tor compromised mail login passwords under both circumstances
- http (the Tor gets your mail password in the clear)
- https (the Tor _could_ impersonate the "certificate")

So, I ask ... how can I tell if a certificate is impersonated by a rogue
Tor? I routinely say yes to all certificate requests because I never
understood them. Now I will take the time to read them.

But, what does a fake SSL situation look like?

For example, I just initiated a connection to my legimate router:
https://192.168.1.1
And it said (as it always does):
"Security Error: Domain Name Mismatch"
It went on:
"You have attempted to establish a connection with 192.168.1.1.
However, the security certificate presented belongs to Linksys.
It is possible, though unlikely, that someone may be trying to
intercept your communications with this web site.
It gave the recommendation:
"If you suspect the certificate shown does not belong to
192.168.1.1, please cancel the connection and notify the
site administrator?

Obviously this whole situation is a false alarm.

Does anyone have an example of a situation we can go to in order to see
what a "real" SSL forgery looks like to the user as they try to log into
their email web site?

Re: How to tell a fake SSL certificate from a real one

On 27 oct, 23:45, Joan Battaglia wrote:

You maybe should read about assymetrical encryption, it's all about
SSL, in wikipedia. Also, you can see it "live", by loging into an SSL
server like gmail by using OpenSSL (or even Lynx)

OpenSSL will allow you to log into gmail throught an SSL telnet
session. POP 3 protocol commands work as usual.

Asymetrical encryption : Gmail sends you a huge random number, from
which you PC compute de public key and return it to google (for
encryption) and the private key which you use to decrypt datas send by
gmail. The public key can be used for encryption. and the privat key
is not send; So it should be secure ;) almost

L

Re: How to tell a fake SSL certificate from a real one

Joan Battaglia wrote in
news:yjOUi.1213$yV6.108@newssvr25.news.prodigy.net:

[snip]

> I routinely say yes to all certificate requests because I
> never understood them.

Unfortunatly you're not the only person to do so. :-( Other people will
also click [YES] when some malwareis asking to be installed.

> Now I will take the time to read them.

Good Luck.

Re: How to tell a fake SSL certificate from a real one

In message Joan
Battaglia wrote:

>So, I ask ... how can I tell if a certificate is impersonated by a rogue
>Tor? I routinely say yes to all certificate requests because I never
>understood them. Now I will take the time to read them.

Good plan. In general, any error at all in a SSL certificate and you
should be suspicious.

You can pull the fingerprint and compare it against the fingerprint of
that same SSL certificate provided via another method (like from a
different internet connection, and not passing through Tor), and then
once you've confirmed the error, safely proceed, but otherwise, by
ignoring SSL errors you are all but not using SSL at all.

(Well, in practice you're raising the bar to snoop on your traffic from
just sniffing to man-in-the-middle attacks. Tor is ideal for
man-in-the-middle attacks since you're intentionally passing your
traffic through several more hosts)

>But, what does a fake SSL situation look like?
>
>For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
>And it said (as it always does):
> "Security Error: Domain Name Mismatch"
>It went on:
> "You have attempted to establish a connection with 192.168.1.1.
> However, the security certificate presented belongs to Linksys.
> It is possible, though unlikely, that someone may be trying to
> intercept your communications with this web site.
>It gave the recommendation:
> "If you suspect the certificate shown does not belong to
> 192.168.1.1, please cancel the connection and notify the
> site administrator?

The example above is a perfect case of a forgery -- Your router has an
invalid certificate, and the SSL layer is offering virtually no
protection against anything other then casual snooping.

A more common forgery case would be a valid URL, valid not-expired
timestamp, but a certificate which was not signed by a trusted authority
(And is otherwise 100% valid and complete)

--
You can get more with a kind word and a 2x4 than just a kind word.

Re: How to tell a fake SSL certificate from a real one

Joan Battaglia wrote:

> What does a forged SSL situation look like to the user logging into email?
> Do you have an example?
>
> I read with interest all the help kindly provided by the likes of helpful
> folks like VanguardLH & mark carter & others - which basically concluded
> Tor compromised mail login passwords under both circumstances

The problem is that their conclusions are not only unwarranted
technically, the results of the incident they're all talking about
whether they even realize it or not specifically state that all these
passwords were sniffed from connections that *were not* SSL/TLS
encrypted.

http://www.lightbluetouchpaper.org/2007/09/10/embassy-email- accounts-breached-by-unencrypted-passwords/

The only mystery here is why government agencies are not mandating
secure email access. It's astounding that any IT people in charge of
embassy communications could be so utterly clueless.

> - http (the Tor gets your mail password in the clear)
> - https (the Tor _could_ impersonate the "certificate")

Not unless your browser is horribly broken, or you blindly click the
'OK' buttons on dialogs without reading the clear and concise warnings
contained therein.

>
> So, I ask ... how can I tell if a certificate is impersonated by a rogue
> Tor? I routinely say yes to all certificate requests because I never
> understood them. Now I will take the time to read them.

You read the error message.

>
> But, what does a fake SSL situation look like?

A big pop up with a suitable warning symbol, and likely some sort of
"broken lock" notification in your status bar, all telling you that the
certificate doesn't match the site you're visiting, isn't signed, or
has changed.

> For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
> And it said (as it always does):
> "Security Error: Domain Name Mismatch"
> It went on:
> "You have attempted to establish a connection with 192.168.1.1.

Exactly. The certificate was issued under the name of your router
manufacturer and you've entered a URL that doesn't match that name.
This is just one of the warning signs. Since you manually typed in a
non-routable IP address and know what it is you're trying to connect
to, you can ignore this particular warning. If you had been trying to
reach www.mybank.com ignoring it would just as obviously be a
BadThing(tm).

> Obviously this whole situation is a false alarm.
>
> Does anyone have an example of a situation we can go to in order to see
> what a "real" SSL forgery looks like to the user as they try to log into
> their email web site?

It will look exactly the same if this is how the forgers are trying to
attack you. Except the names will have changed of course... "You have
attempetd to establish a connection with www.mybank.com, how ever the
certificate belongs to XXXX". Or it will be unsigned, or won't match
the cert you've received on previous visits to your bank site. Or more
likely a combination of all three.

Re: How to tell a fake SSL certificate from a real one

bealoid wrote:

> Joan Battaglia wrote in
> news:yjOUi.1213$yV6.108@newssvr25.news.prodigy.net:
>
> [snip]
>
> > I routinely say yes to all certificate requests because I
> > never understood them.
>
> Unfortunatly you're not the only person to do so. :-( Other people will
> also click [YES] when some malwareis asking to be installed.

You're right of course. There's no shortage of inattentive or ignorant
users in the world. But this is a PEBKAC problem, not a software or
security methods issue.

>
> > Now I will take the time to read them.
>
> Good Luck.

It's really pretty simple. If you get an error that you didn't expect
or one that can't be easily explained by things like the Linksys
router issue or periodic rotation of expired SSL certificates, then you
don't accept them. Period. Unless you know for sure that the reason for
the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
or whatever negative response your software offers you. If you're in
doubt as to what to click, close the software all together.

If you've made a mistake and the connection was actually kosher then no
harm done. You have ample time to sort it out and make a final
determination about a given certificate. OTOH, if you err on the side
opposite of caution you may have precious few minutes to sort it out
before some script kiddie cleans out your bank account by wire
transferring your entire balance to Taiwan. :(

Re: How to tell a fake SSL certificate from a real one

On Sat, 27 Oct 2007 21:45:02 GMT, Joan Battaglia wrote:

> What does a forged SSL situation look like to the user logging into
email?
> Do you have an example?
>
> I read with interest all the help kindly provided by the likes of helpful
> folks like VanguardLH & mark carter & others - which basically concluded
> Tor compromised mail login passwords under both circumstances
> - http (the Tor gets your mail password in the clear)
> - https (the Tor _could_ impersonate the "certificate")
>
> So, I ask ... how can I tell if a certificate is impersonated by a rogue
> Tor? I routinely say yes to all certificate requests because I never
> understood them. Now I will take the time to read them.
>
> But, what does a fake SSL situation look like?

Mainly, you can see one because it obfucates the microcode in your HOSTS
files. Another way is to log to HTTPS the source code (unless it is C#) to
a NON HTTPS website.

> For example, I just initiated a connection to my legimate router:
> https://192.168.1.1
> And it said (as it always does):
> "Security Error: Domain Name Mismatch"
> It went on:
> "You have attempted to establish a connection with 192.168.1.1.
> However, the security certificate presented belongs to Linksys.
> It is possible, though unlikely, that someone may be trying to
> intercept your communications with this web site.
> It gave the recommendation:
> "If you suspect the certificate shown does not belong to
> 192.168.1.1, please cancel the connection and notify the
> site administrator?
>
> Obviously this whole situation is a false alarm.
>
> Does anyone have an example of a situation we can go to in order to see
> what a "real" SSL forgery looks like to the user as they try to log into
> their email web site?

Sure, take this URL.

http://tinyurl.com/2tt98s

Then when it loads, do a quick, CTRL-ALT-ampersand. If Java is scripted
server side only, then you can see the talisman algorithms. If not, then
you have to look at the compiled (previous not present, prior to browser
time-outs or MITM attacks).Either way, you have your answer.

HTH

Re: How to tell a fake SSL certificate from a real one

DevilsPGD wrote:

> In message Joan
> Battaglia wrote:
>
> >So, I ask ... how can I tell if a certificate is impersonated by a rogue
> >Tor? I routinely say yes to all certificate requests because I never
> >understood them. Now I will take the time to read them.
>
> Good plan. In general, any error at all in a SSL certificate and you
> should be suspicious.
>
> You can pull the fingerprint and compare it against the fingerprint of
> that same SSL certificate provided via another method (like from a
> different internet connection, and not passing through Tor), and then
> once you've confirmed the error, safely proceed, but otherwise, by
> ignoring SSL errors you are all but not using SSL at all.

Agreed. The whole problem boils down to users not paying attention to
the warnings in front of their faces, or not using secure methods at
all.

> (Well, in practice you're raising the bar to snoop on your traffic from
> just sniffing to man-in-the-middle attacks. Tor is ideal for

MITM attacks have been occurring since long before Tor was ever in use.
Packages like dsniff have been around since the late 90's, including
specifc tools to spoof DNS, and then attack both SSH and SSL/HTTPS
connections. They're part of the reason SSH and SSL have evolved much
of their authenticity checking. My SSH client for example, absolutely
refuses to connect if keys change until the old key is manually removed
and the new one accepted.

Tor makes it a little easier for certain levels of technically inept
attackers to attempt certain attacks, but it in no way changes the
nature of the attack itself. The protocols and specifications will
protect you just the same over a Tor connection as they will a naked
connection.

> man-in-the-middle attacks since you're intentionally passing your
> traffic through several more hosts)
>
> >But, what does a fake SSL situation look like?
> >
> >For example, I just initiated a connection to my legimate router:
> > https://192.168.1.1
> >And it said (as it always does):
> > "Security Error: Domain Name Mismatch"
> >It went on:
> > "You have attempted to establish a connection with 192.168.1.1.
> > However, the security certificate presented belongs to Linksys.
> > It is possible, though unlikely, that someone may be trying to
> > intercept your communications with this web site.
> >It gave the recommendation:
> > "If you suspect the certificate shown does not belong to
> > 192.168.1.1, please cancel the connection and notify the
> > site administrator?
>
> The example above is a perfect case of a forgery -- Your router has an
> invalid certificate, and the SSL layer is offering virtually no
> protection against anything other then casual snooping.

???

The SSL certificate used by your router *must* be registered to the
router manufacturer, not some arbitrary IP address. This is a perfect
case of a valid certificate generating the warnings it's suppose to
generate because it's used in an implementation where it's impossible
to do it any other way and still maintain a secure connection to your
router. Linksys has no way of knowing that what your router's internal
IP address will be.

> A more common forgery case would be a valid URL, valid not-expired
> timestamp, but a certificate which was not signed by a trusted authority
> (And is otherwise 100% valid and complete)

Which also generates warnings and/or errors, and can't be installed or
even accepted by some software.

These types of forgeries are very uncommon though, because they require
that the attacker generate and selectively substitute unsigned
certificates for a whole range of potential targets. And do it in the
hopes that they're going to be the first one to submit the bogus
certificate to a potential victim, who in turn ignores the "unsigned"
warnings.

The chances of success are next to zero. It's a fruitless waste of
resources to generate certs with "Forged" UID's. Just as easy to
generate one, possibly even get it officially certified, and then
substitute that for the targets real certificate in hopes that a user
will miss the "changed" and/or "doesn't match" error.

SSL has been around for quite a while now. It's paid its dues. The
attacks we're talking about here are nowhere as easy to launch as some
people apparently think they are. Under normal circumstances (Tor usage
included) they're impossible to launch. It's only very rare cases of
user negligence or broken software where they'll have any chance at
success.

Re: How to tell a fake SSL certificate from a real one

Anonymous Sender writes:
> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.

we were called in to consult with this small client/server startup
that wanted to do payments on their server. this resulted in something
that is frequently now called electronic commerce ... misc.
related postings
http://www.garlic.com/~lynn/subnetwork.html#gateway

they also had invented this technology called SSL that they wanted to
use for the payments. As part of the payment transaction stuff ... we
had to do this detailed audit of the SSL protocol as well as walk thru
of this new organizations calling themselves certification authorities
.... and these things that they were issuing called digital certificates.
somewhat related past postings
http://www.garlic.com/~lynn/subpubkey.html#sslcert

part of the browser/webserver interaction assumptions for SSL ... was
not only did the users understand the whole PKI gorp ... but were also
required to understand the relationship between the webserver they thot
they were talking to and the corresponding URL. SSL then would provide
for verifying the correspondance between the URL and the webserver they
were actually talking to (both are a requirement in order to result in
the webserver a user actually talks to, is the webserver that the user
thinks they are talking to).

this criteria was almost immediately compromised in actual deployments.
merchants fairly quickly found that use of SSL cut their thruput by
80-90 precent so they regressed to just using SSL for checkout/pay phase
with a CLICK button provided to enduser.

The CLICK button paradigm contributed sigificantly to obfuscating what
the user thot of as a website and the corresponding URL (they were no
longer paying attention to the actual URL used ... in part because they
were no longer actually typing it).

Now there was no longer (any SSL) verification of the initial website
contact ... and the (possibly fraudulent) website was then providing the
CLICK button URL for the SSL portion. An attacker could possibly obtain
a perfectly valid digital certificate that corresponds to the URL
provided by the CLICK button ... and effectively nearly all users would
never pay any attention.

misc. recent posts mentioning this issue:
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007q.html#73 Value of SSL client certificates?

This obfuscation has also been leveraged by various phishing email
exploits ... either by taking a user to fraudulent impersonation website
(with perfectly valid SSL digital certificate) and/or using some flavor
of proxy technology for a man-in-the-middle attack (again possibly with
perfectly valid SSL digital certificate) ... recent posts discussing a
man-in-the-middle using some form of proxy technology
http://www.garlic.com/~lynn/2007q.html#6 what does xp do when system is copying
http://www.garlic.com/~lynn/2007q.html#29 what does xp do when system is copying
http://www.garlic.com/~lynn/2007q.html#31 what does xp do when system is copying

misc. posts mentioning man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 05:36:07 -0400, Nil wrote:
I followed everyone's advice and installed Tor/Vidalia/Privoxy.
I learned it's UP TO ME to determine if a certificate is fake.
So, I test the system - and I take your advice to READ the certificate
warning - but I still don't know what to do with the result.

Is THIS a fake certificate?

Here's what happened.
I went to http://torcheck.xenobite.eu/index.php
I clicked on the HTTPS-Mode button to see what it would say
Up popped a "Security Error: Domain Name Mismatch"
Which warned
You have attempted to establish a connection with
torcheck.xenobite.eu. However the security certificate
presented belongs to 217.160.111.190. It is possible, though
unlikely, that someone may be trying to intercept your
communication with this web site.
And, then:
If you suspect the certificate shown does not belong to
torcheck.xenobite.eu, please cancel the connection and notify
the site administrator.

So what do I do?
Most of these posts say to examine the certificate, so I press
the "View Certificate" button.

It says:
This certificate has been verified for the following uses:
SSL Server Certificate
Huh? Is that telling me something?

Then it says:
Issued To
Common Name (CN) 217.160.111.190
Organization (O) Kraus Computertechnik
Organizational Unit (OU) StartCom Free Certificate Member
Serial Number 01:84:54
To which my head is spinning - I guess I'm supposed to tell from this
if it's legitimate or not - but I don't know where to look.

It goes on:
Issued By
Common Name (CN) StartCom Class 1 Primary Intermediate Free CA
Organization (O) StartCom Ltd.
Organizational Unit (OU) Secure Certificate Signing
Huh? I still don't know what is wheat and what is chaff.

Moving on:
Validity
Issued On 9/25/2007
Expires On 9/24/2008
Does this tell me anything useful other than when it will expire.

Lastly:
Fingerprints
SHA1 Fingerprint
D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61:11:B9:1B
MD5 Fingerprint:
24:00:31:6D:F3:3B:E2:90:BC:73:CE:4D:BF:9C:2A:D7

I won't even go into what it says in the DETAILS tab!
Oh my. If all this which I'm supposed to read actually means something to
you guys, then you ARE rocket scientists!

What do I (decidedly not a rocket scientist) do with this information?
Is this a fake certificate or a real certificate?
How would I know?

Re: How to tell a fake SSL certificate from a real one

Post removed (X-No-Archive: yes)

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 14:43:58 GMT, Joan Battaglia wrote:

> Lastly:
> Fingerprints
> SHA1 Fingerprint
> D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61:11:B9:1B
> MD5 Fingerprint:
> 24:00:31:6D:F3:3B:E2:90:BC:73:CE:4D:BF:9C:2A:D7
>
> I won't even go into what it says in the DETAILS tab!
> Oh my. If all this which I'm supposed to read actually means something to
> you guys, then you ARE rocket scientists!
>
> What do I (decidedly not a rocket scientist) do with this information?
> Is this a fake certificate or a real certificate?
> How would I know?

You will need to reboot, then check HOSTS for non 8080 correspondence.
Look for asterisks where there should be commas.
--
Vern, vermin, Kevin, whatever, I would have thought holding your hand as
we praised Ian would not have passed for a "I want to fuck you".

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 09:51:34 -0400, Anne & Lynn Wheeler wrote:

> we were called in to consult with this small client/server startup
> that wanted to do payments on their server. this resulted in something
> that is frequently now called electronic commerce ... misc.
> related postings
> http://www.garlic.com/~lynn/subnetwork.html#gateway
>
> they also had invented this technology called SSL that they wanted to
> use for the payments.

Small?

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

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 04:58:16 +0000 (UTC), Anonymous Sender wrote:

> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.

So basically you're telling us you don't have an argument anymore after
you found out Tor's developers have no problem with the commercial
nature of Xerobank so you're reduced to puerile whining. You conceded
your idiotic "stolen software" argument, abandoned the "bandwidth" issue
in record time, and rather than be adult enough to just admit your
mistakes you'd rather impress us with taking cheap shots at anonymous
posters in general from behind a remailer.

How pathetic. Thanks for clearing all that up for us this week too,
kiddo. :)
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 04:58:16 +0000 (UTC), Anonymous Sender wrote:

> bealoid wrote:
>
>> Joan Battaglia wrote in
>> news:yjOUi.1213$yV6.108@newssvr25.news.prodigy.net:
>>
>> [snip]
>>
>>> I routinely say yes to all certificate requests because I
>>> never understood them.
>>
>> Unfortunatly you're not the only person to do so. :-( Other people will
>> also click [YES] when some malwareis asking to be installed.
>
> You're right of course. There's no shortage of inattentive or ignorant
> users in the world. But this is a PEBKAC problem, not a software or
> security methods issue.
>
>>
>>> Now I will take the time to read them.
>>
>> Good Luck.
>
> It's really pretty simple. If you get an error that you didn't expect
> or one that can't be easily explained by things like the Linksys
> router issue or periodic rotation of expired SSL certificates, then you
> don't accept them. Period. Unless you know for sure that the reason for
> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
> or whatever negative response your software offers you. If you're in
> doubt as to what to click, close the software all together.
>
> If you've made a mistake and the connection was actually kosher then no
> harm done. You have ample time to sort it out and make a final
> determination about a given certificate. OTOH, if you err on the side
> opposite of caution you may have precious few minutes to sort it out
> before some script kiddie cleans out your bank account by wire
> transferring your entire balance to Taiwan. :(

> I have never insulted you to the best of my belief and knowledge.

ROTFLMAO!

That's the biggest load of shit you've EVER posted.

> It appears it is insulting to you when someone disagrees with you.

Talk about the pot calling the kettle black.

Insulting people who disagree with you is ALL you do.

> The remainder of the trolling rubbish removed.

Can't face the truth eh?

Just blame everyone else for doing what you do and run away little boy.
That makes it all go away.

NOT!

--
----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQB5AwUBRx4c0gEP2aowjishfaHfJAQGLWwMgjZk5mxNcthP1YeCHaXldbqO UOUbvgkYp
/EdaOVSasH6Okkz2UMQapklsfjqipoejgSPj/EgGiAzZkitdCE64mJ/vP3aY ISL8/DNask3JPfF
U1zJXY87GynBB1jq+APaNXyrE1DpU75zz9Twpw==
=A8Gm
-----END PGP SIGNATURE-----

Re: How to tell a fake SSL certificate from a real one

Joan Battaglia wrote:

> On Sun, 28 Oct 2007 05:36:07 -0400, Nil wrote:
> I followed everyone's advice and installed Tor/Vidalia/Privoxy.
> I learned it's UP TO ME to determine if a certificate is fake.
> So, I test the system - and I take your advice to READ the certificate
> warning - but I still don't know what to do with the result.
>
> Is THIS a fake certificate?
>
> Here's what happened.
> I went to http://torcheck.xenobite.eu/index.php
> I clicked on the HTTPS-Mode button to see what it would say
> Up popped a "Security Error: Domain Name Mismatch"
> Which warned
> You have attempted to establish a connection with
> torcheck.xenobite.eu. However the security certificate
> presented belongs to 217.160.111.190. It is possible, though
> unlikely, that someone may be trying to intercept your
> communication with this web site.
> And, then:
> If you suspect the certificate shown does not belong to
> torcheck.xenobite.eu, please cancel the connection and notify
> the site administrator.
>
> So what do I do?


Well, it's written there. Do you suspect it? For me, torcheck.xenobite.eu
resolves to 217.160.111.190, and I got my reply through DNSsec.

> It says:
> This certificate has been verified for the following uses:
> SSL Server Certificate
> Huh? Is that telling me something?


Well, it should. The purpose of this certificate is to verify the identity
of the server. This is what you're using it for at the moment. Thus, this is OK.

If it told you that it's only purpose is for eMail verification, you should
suspect it when it's used for server identification.

> Issued To
> Common Name (CN) 217.160.111.190
> Organization (O) Kraus Computertechnik
> Organizational Unit (OU) StartCom Free Certificate Member
> Serial Number 01:84:54
> To which my head is spinning - I guess I'm supposed to tell from this
> if it's legitimate or not - but I don't know where to look.


CN, O and OU are well-defined in the X.509v3 standard. Why don't you look it
up? The CN seems a bit bogus to me.

> It goes on:
> Issued By
> Common Name (CN) StartCom Class 1 Primary Intermediate Free CA
> Organization (O) StartCom Ltd.
> Organizational Unit (OU) Secure Certificate Signing
> Huh? I still don't know what is wheat and what is chaff.


Well, then should definitely start reading. Class 1 typically is a
verification level by domain, thus they only send a reply to mail address at
the domain, and getting a reply then it the authentication. They
authenticate that the cert owner has control over the domain he's issuing a
certificate for, nothing more. They don't verify whether the Organization
belongs to this domain.

Class 3 is personal authentication by ID card and a written letter through
snail mail, Class 4 and above additionally verify that the Organization Unit
with the Organization exists.

Then again, you should always check the exact policy of the company issuing
the certificate. Why aren't you on the website of StartCom yet?

> Moving on:
> Validity
> Issued On 9/25/2007
> Expires On 9/24/2008
> Does this tell me anything useful other than when it will expire.


It tells you that this cert is current valid unless explicitly invalidated.

> Oh my. If all this which I'm supposed to read actually means something to
> you guys, then you ARE rocket scientists!


No, you're just (sorry for saying that) incompetent. Without even knowing
what the SSL certificate details means you should never ever do any
financial transactions on the web, and neither submit any personal data. In
fact you should better not even surf the web at all, because this is some of
the basic stuff that you absolutely need to know to not blind run into all
kind of troubles. The lack of seeing what's actually needed is the cause of
exactly the problems we're facing now, f.e. phishing, which, by definition,
actually is a pure non issue if everyone would just know this absolute minimum.

Re: How to tell a fake SSL certificate from a real one

Anonymous Sender wrote:


>> It's really pretty simple. If you get an error that you didn't expect
>> or one that can't be easily explained by things like the Linksys
>> router issue or periodic rotation of expired SSL certificates, then you
>> don't accept them. Period. Unless you know for sure that the reason for
>> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
>> or whatever negative response your software offers you. If you're in
>> doubt as to what to click, close the software all together.
>>
>> If you've made a mistake and the connection was actually kosher then no
>> harm done. You have ample time to sort it out and make a final
>> determination about a given certificate. OTOH, if you err on the side
>> opposite of caution you may have precious few minutes to sort it out
>> before some script kiddie cleans out your bank account by wire
>> transferring your entire balance to Taiwan. :(
>
>> I have never insulted you to the best of my belief and knowledge.
>
> ROTFLMAO!
>
> That's the biggest load of shit you've EVER posted.


WTF? This is actually the most sensible advice one could give. If in doubt,
an SSL error should be considered as a consequence of an attack, and the
protocols specifies to cancel the connection altogether.

Re: How to tell a fake SSL certificate from a real one

On Sun, 28 Oct 2007 15:49:20 -0500, Anonymous Sender wrote:

>>>> Now I will take the time to read them.
>>>
>>> Good Luck.
>>
>> It's really pretty simple. If you get an error that you didn't expect
>> or one that can't be easily explained by things like the Linksys
>> router issue or periodic rotation of expired SSL certificates, then you
>> don't accept them. Period. Unless you know for sure that the reason for
>> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
>> or whatever negative response your software offers you. If you're in
>> doubt as to what to click, close the software all together.
>>
>> If you've made a mistake and the connection was actually kosher then no
>> harm done. You have ample time to sort it out and make a final
>> determination about a given certificate. OTOH, if you err on the side
>> opposite of caution you may have precious few minutes to sort it out
>> before some script kiddie cleans out your bank account by wire
>> transferring your entire balance to Taiwan. :(
>
>> I have never insulted you to the best of my belief and knowledge.
>
> ROTFLMAO!
>
> That's the biggest load of shit you've EVER posted.

Except that I didn't post it, A$$hole. lol
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/

Re: How to tell a fake SSL certificate from a real one

Ari wrote:

> On Sun, 28 Oct 2007 15:49:20 -0500, Anonymous Sender wrote:
>
> >>>> Now I will take the time to read them.
> >>>
> >>> Good Luck.
> >>
> >> It's really pretty simple. If you get an error that you didn't expect
> >> or one that can't be easily explained by things like the Linksys
> >> router issue or periodic rotation of expired SSL certificates, then you
> >> don't accept them. Period. Unless you know for sure that the reason for
> >> the error has a verifiable and natural cause, you click 'NO', 'CANCEL',
> >> or whatever negative response your software offers you. If you're in
> >> doubt as to what to click, close the software all together.
> >>
> >> If you've made a mistake and the connection was actually kosher then no
> >> harm done. You have ample time to sort it out and make a final
> >> determination about a given certificate. OTOH, if you err on the side
> >> opposite of caution you may have precious few minutes to sort it out
> >> before some script kiddie cleans out your bank account by wire
> >> transferring your entire balance to Taiwan. :(
> >
> >> I have never insulted you to the best of my belief and knowledge.
> >
> > ROTFLMAO!
> >
> > That's the biggest load of shit you've EVER posted.
>
> Except that I didn't post it, A$$hole. lol

Nobody said you did, "asshole".

So why would you "defend" yourself from something that you were never
even involved in? Freudian slip, or just some childish little game?

Either way you're an obnoxious cretin.

Re: How to tell a fake SSL certificate from a real one

Anne & Lynn Wheeler wrote:



Congratulations Captain obvious!

You've just confirmed exactly what people have been saying all along.
The problem with SSL isn't SSL, but improper implementation and to a
greater degree user ignorance. Tor has nothing at all to do with
anything.

You did make one glaring mistake though...

> This obfuscation has also been leveraged by various phishing email
> exploits ... either by taking a user to fraudulent impersonation website
> (with perfectly valid SSL digital certificate) and/or using some flavor
> of proxy technology for a man-in-the-middle attack (again possibly with
> perfectly valid SSL digital certificate)

That's is a patently false statement. If a site spoofs certificates
they're not "perfectly" anything but forgeries. At which point the
problem lies squarely in the hands of the user. And education is the
only way to fix that broken wheel. The finest tools in the world placed
in the hands of the incompetent won't result in a fine family heirloom.

Again, this is in no way an SSL problem. The secure layer that can't be
misused is a myth.

Re: How to tell a fake SSL certificate from a real one

Joan Battaglia wrote:



> Is THIS a fake certificate?
>
> Here's what happened.
> I went to http://torcheck.xenobite.eu/index.php

Yes. at this juncture you're dealing with a fake certificate. You have
no way of immediately knowing whether or not someone has hijacked your
connection to xenobite.eu, and is trying to "sniff" some bit of
important information. You should immediately drop the connection and
start asking questions. Which you just did. :-)

There's a couple ways to resolve the issue in a more situation specific
way. The most obvious is determining exactly what it is you're trying
to do. IOW, is the information you're sharing with "Xenobite" worth
protecting in the first place? This particular test is to show you what
information your browser hands out over an HTTP connection as opposed to
an HTTPS connection. That information can be different. especially if
you're using something like Privoxy to scrub content. Privoxy can't see
content inside an HTTPS connection so that scrubbing fails. A good
reason to leave all that stuff in the hands of your browser itself, and
plugins like NoScript. They can scrub content/headers before the data
is encrypted.

The Xenobite test is specifically designed to bring the above points to
light, FWIW.

So in essence you're really not transferring critical content. No
"bank account" information or anything. It's more of an informational
venture. That alone might be enough on which to base the decision to
accept the "fake" certificate and allow the connection.

You might also use DNS to verify the IP address of Xenobite, however
any IP could be in the certificate owner's field so this isn't reliable
even if you're doing secure DNS lookups. This is where known trusted
CA's come into play, and the certificate in question isn't signed by
any.

Another way is to compare the fingerprint of the certificate with the
fingerprint other people see. Using the SHA fingerprint because it's
somewhat more secure...

Yours:

D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61:11:B9:1B

Mine:

D3 CF DC 24 BC 3E E9 59 27 2B 82 51 27 67 D2 E8 61 11 B9 1B

They match, so you know someone isn't attacking your connection
specifically. I visited the site "naked", so you know it's not a Tor
node, if anyone has managed to compromise the other end.

A few more confirmations, especially from people who have examined the
cert in the past, and you have a reasonable assurance that the
certificate is acceptable. I wouldn't trust anonymous confirmations
though, I could be anyone. ;-) But I do know in this case that if you
pursue those lines you'll find people who will confirm the fingerprint.

You can dig even deeper than that if you want to, but at this point I'd
say we've determined that Xenobyte is simply using a free, untrusted
certificate for the purposes of demonstrating how SSL affects your
anonymous connection. The information you're giving Xenobite isn't
critical, the trust factor is more than high enough to make you feel
"comfortable" with what you're doing, so you can safely accept the
certificate and proceed with the test.

If the same scenario occurs with your banking site, however, you should
run like hell. ;)

Re: How to tell a fake SSL certificate from a real one

Aaron wrote:

> Anonymous Sender wrote in
> news:6dda6448ead9cb5bb66f2e45a96775b7@remailer.metacolo.com:
>
>
> >> Does anyone have an example of a situation we can go to in order to
> >> see what a "real" SSL forgery looks like to the user as they try to
> >> log into their email web site?
> >
> > It will look exactly the same if this is how the forgers are trying to
> > attack you. Except the names will have changed of course... "You have
> > attempetd to establish a connection with www.mybank.com, how ever the
> > certificate belongs to XXXX". Or it will be unsigned, or won't match
> > the cert you've received on previous visits to your bank site. Or more
> > likely a combination of all three.
>
> Seems to be the bottom line here.
>
> I thought I basically understood how SSL works, but i guess it can be
> really confusing.

It can be made confusing anyway. ;-)

The underlying principals and actions you should take are fairly
straightforward. If you get an error *read it*. If you don't understand
it, stop. Only when you've figured it out should you continue.

> I don't know about all this ssl intercepting thingies, but i used to have a
> setup involving a local proxy, proxomitron handling https as well. I had to
> accept a local (self-signed???) cert from proximitron (that i downloaded)
> before it could work.
>
> I presume anyone in the TOR chain that tried to do so, would cause the same
> thing?

Yes, that's essentially what an evil Tor node attempts and the same
sort of error you'll get. The wording may be different because there's
different errors, different browsers will represent them in their own
"language", and I don't remember what the specific problem with the
Proximitron cert was, but the principals are the same. Something or
things won't "jive". For evil Tor nodes and other MITM attackers, even
ones with certs signed by trusted authorities, it will most likely be
something akin to "The cert doesn't match the site you're connecting
to". It's not the only scenario that can generate that error, but MITM
attacks will almost always generate them.

The Truth About Anonymous Blowhards

*On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*

>> I have never insulted you to the best of my belief and knowledge.

On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:

> > > ROTFLMAO!
> > >
> > > That's the biggest load of shit you've EVER posted.

*ARI:*

> > Except that I didn't post it, A$$hole. lol

* Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*

> Nobody said you did, "asshole".

lol

See what remailers do to you? Match that with this absurd, combative,
over-inflated valuation of yourself (" I have to be Anonymous, I am
sooooooo important") which flies directly in the face of "I will risk all I
am important about to play like a child on Usenet 7/24/366" combined w/ "I
have to uphold my Usenet reputation" shtick you are on. You can't keep up
with your own allegations.

You want to argue with me? When you can't keep up with your own postings?
Or be consistent between feeding your fucking ego and exposing yourself ("I
am Anonymous b/c I am laden with great tasks" v.s. "The Boss will kick my
ass to the curb")

You're a walking paradox of total bullshit. And a coward to boot.

Fuck off. If I want to banter with kids, techie wannabees, or dark corner
hiding flashers, I'll go to the nearest kindergarten, Star Trek
Extravaganza or urban alley where dogs piss.

See ya'.

Re: The Truth About Anonymous Blowhards

Ari wrote:



Your middle initial wouldn't be an 'S' by any chance would it?

Re: The Truth About Anonymous Blowhards

Ari wrote:

> > > Except that I didn't post it, A$$hole. lol
>
> * Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> > Nobody said you did, "asshole".
>
> lol
>
> See what



You forgot to explain why you would feel the need to defend yourself
against something that you had absolutely no part in what so ever. Your
name didn't even appear, yet you're denying doing it.

Odd, that.

Re: The Truth About Anonymous Blowhards

Ari wrote:

> *On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> >> I have never insulted you to the best of my belief and knowledge.
>
> On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:
>
> > > > ROTFLMAO!
> > > >
> > > > That's the biggest load of shit you've EVER posted.
>
> *ARI:*
>
> > > Except that I didn't post it, A$$hole. lol
>
> * Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:*
>
> > Nobody said you did, "asshole".
>
> lol
>
> See what remailers do to you? Match that with this absurd, combative,
> over-inflated valuation of yourself (" I have to be Anonymous, I am
> sooooooo important") which flies directly in the face of "I will risk
> all I am important about to play like a child on Usenet 7/24/366"
> combined w/ "I have to uphold my Usenet reputation" shtick you are
> on. You can't keep up with your own allegations.
>
> You want to argue with me? When you can't keep up with your own
> postings? Or be consistent between feeding your fucking ego and
> exposing yourself ("I am Anonymous b/c I am laden with great tasks"
> v.s. "The Boss will kick my ass to the curb")
>
> You're a walking paradox of total bullshit. And a coward to boot.
>
> Fuck off. If I want to banter with kids, techie wannabees, or dark
> corner hiding flashers, I'll go to the nearest kindergarten, Star Trek
> Extravaganza or urban alley where dogs piss.

Poor precious Ari, skittering about from post to post desperately
trying to inject enough venom to make himself feel significant again
after his latest beating.

Old story, bright new day. Almost feel sorry for ya' kidlet.

>
> See ya'.

Ta ta!

Re: How to tell a fake SSL certificate from a real one

On Mon, 29 Oct 2007 00:49:45 +0000 (UTC), Anonymous Sender wrote:

>>>>
>>>> If you've made a mistake and the connection was actually kosher then no
>>>> harm done. You have ample time to sort it out and make a final
>>>> determination about a given certificate. OTOH, if you err on the side
>>>> opposite of caution you may have precious few minutes to sort it out
>>>> before some script kiddie cleans out your bank account by wire
>>>> transferring your entire balance to Taiwan. :(
>>>
>>>> I have never insulted you to the best of my belief and knowledge.
>>>
>>> ROTFLMAO!
>>>
>>> That's the biggest load of shit you've EVER posted.
>>
>> Except that I didn't post it, A$$hole. lol
>
> Nobody said you did, "asshole".
>
> So why would you "defend" yourself from something that you were never
> even involved in? Freudian slip, or just some childish little game?
>
> Either way you're an obnoxious cretin.

I'll have to eat crow on that one, Ari, you didn't post that.

Mea Culpa.

Re: How to tell a fake SSL certificate from a real one

On Oct 28, 1:22 pm, Krazee Brenda wrote:
> Small?
>
> Netscapeware?

re:
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL
certificate from a real one

at one time ... way back when.

slightly related archeological post
http://www.garlic.com/~lynn/2007r.html#13 What do ATMS and card
readers use?

a couple of people from a large dbms vendor, that we had worked with
when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and scaleup for large distributed databases ... had joined the small
startup
and were in charge of developing something called a commerce server.

random post about long ago and far away meeting at the dbms vendor
where some names were mentioned
http://www.garlic.com/~lynn/95.html#13
http://www.galric.com/~lynn/95.html#15

Re: How to tell a fake SSL certificate from a real one

Nomen Nescio writes:
> That's is a patently false statement. If a site spoofs certificates
> they're not "perfectly" anything but forgeries. At which point the
> problem lies squarely in the hands of the user. And education is the
> only way to fix that broken wheel. The finest tools in the world placed
> in the hands of the incompetent won't result in a fine family heirloom.
>
> Again, this is in no way an SSL problem. The secure layer that can't be
> misused is a myth.

re:
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real one

the comment wasn't about an attacker spoofing a certificate ... the
comment was about spoofing a website (at a totally different URL)
.... for which they might have a perfectly valid certificate.

the phishing attackers have been succesful with "click" paradigm
.... claiming to be one thing and actually having duplicated the site at
a totally different website/URL (for which they have a valid
certificate).

the issue was that the original SSL deployment about the end-users
knowing the binding between the site they thought they were talking to
and the URL for that site. Almost immediately there was widely
deployment based on using "click" buttons ... and for possibly for most
users they never acquired a knowledgeable awareness of the URL for the
website they believed they were talking to.

other phishing attacks have used variation on proxy technologies ...
having valid certificate for the URL (they had convinced victims) click
on. they would create a (SSL) session with the end-user ... and then
also create another (SSL) session with the "real" site ... and
transparently pass communication between the two sessions.

SSL was originally suppose to 1) guarentee that the website that the
user thot they were talking to was the actual website they were talking
to and 2) encrypt/hide that communication. However, there was somewhat
implicit assumption that the end-user had to explicity know/provide the
URL for the website they were talking to ... and the only SSL actually
did was guarentee that the website being talked to corresponded with the
provided URL. SSL was widely advertised as "1" ... which allowed
attackers to take advantage of the fact that majority of the users in
the world were interacting with websites ... not by explicity entering a
known URL ... but by clicking on buttons.

This divergent between what SSL was frequently being claimed to
solve and how it was actually being used started to happen very
early.

Part of this was almost immediately the majority of the merchant
ecommerce sites found that use of SSL cut their thruput by
80-90percent. As a result the switched to not using SSL for the initial
connection (which may have been actually entered by a user instead of
clikcing), but restricting its use for the pay/checkout portion of the
shopping experience ... which was a click operation ... for a URL
provided by (potentially fraudulent) merchant website.

Almost immediately, possibly 99.999 percent of the SSL use in the world
was open to attackers being about to redirect users to a different URL
(which users become conditioned to not pay attention to) and for which
the attackers could have a perfectly valid digital certificate.

this contributed to some my comments about "comfort" certificate,
mentioned in some of these past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

there was a large disconnect between what most users in the world were
conditioned to believe was provided by SSL ... and what SSL was actually
providing.

Re: How to tell a fake SSL certificate from a real one

Anne & Lynn Wheeler wrote:


> the phishing attackers have been succesful with "click" paradigm
> ... claiming to be one thing and actually having duplicated the site at
> a totally different website/URL (for which they have a valid
> certificate).
>
> the issue was that the original SSL deployment about the end-users
> knowing the binding between the site they thought they were talking to
> and the URL for that site.


Which is why it's purely a PEBKAC problem. A user who doesn't understand the
URL syntax precisely should never surf the web, and he should be aware of
that. If he doesn't due to pure ignorance, he is to blame - not the
developers of the perfectly precise syntax.

> which allowed attackers to take advantage of the fact that majority of the users in
> the world were interacting with websites ... not by explicity entering a
> known URL ... but by clicking on buttons.


Even if you click buttons, the address bar still shows the URL. And
highlighting mechanisms that precisely show protocol, user/pass (where
applicable), host, path and URL parameter have been existing forever (but
surely you should be able to go without these).

> This divergent between what SSL was frequently being claimed to
> solve and how it was actually being used started to happen very
> early.


But was recognized very lately. Wasn't it a study from the Berkeley
University that shocked all intelligent users on the web with the simple
fact that ~ 90% of the users can even read URLs and judge websites purely by
their appearance?

Re: The Truth About Anonymous Blowhards

In article <1cylxmiu1brmq.uaaizbxc15hg.dlg@40tude.net>,
arisilverstein@yahoo.com says...

Heh heh. He said blow.

AB

Re: How to tell a fake SSL certificate from a real one

"Sebastian G." writes:
> But was recognized very lately. Wasn't it a study from the Berkeley
> University that shocked all intelligent users on the web with the
> simple fact that ~ 90% of the users can even read URLs and judge
> websites purely by their appearance?

re:
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/20074.html#13 What do ATMS and card readers use?
http://www.garlic.com/~lynn/2007r.html#17 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#18 How to tell a fake SSL certificate from a real one

no, it was realized very early ... it was built into the original
assumptions for using SSL to meet electronic commerce requirement. The
security issue was how can the user be sure that the website they
thought they were talking to was the website they were talking to.

SSL was proposed as addressing the problem ... so long as the user had
adequate knowledge and provided the URL for the website they thought
they were talking to ... then SSL would complete the other part of
establishing that the the website being talked to corresponded to the
provided URL.

This was part of end-to-end evaluation of using SSL for electronic
commerce application. The problem was that as soon as the end-user
starting clicking on buttons (that provided the URL) ... it invalidated
the original requirements needed for meeting the end-to-end security
requirements for electronic commerce applications and the role that SSL
played in addressing it.

We saw it as soon as merchants didn't require SSL as part of the full
session (which was another requirement that we had for SSL addressing
the electronic commerce application) ... so the user no longer had
assurance that the merchant website they thought they were talking to
was the website they were talking to. It then was further aggrevated
when the merchant websites started providing the CLICK buttons for
pay/checkout. Since the initial merchant website contact wasn't being
validated ... there was no trust that the website being talked to was
the website the enduser believed they were talking to ... and therefor
could be a fraudulent website. Then the potentially fraudulent website
is providing a URL for pay/checkout ... this could be a perfectly valid
website with a perfectly valid SSL digital certificate ... but operated
by fraudulent organization.

It was the small client/server startup that suggested their SSL
invention as electronic commerce solution ... assuring users that the
website that they thought they were talking to was, in fact, the website
they were talking to. This became the widest deployed and supported
purpose for SSL on the web (as well as the main source of revenue for
the entities calling themselves certification authorities). However, we
showed that SSL could only meet those objectives if certain other
criteria were met. When those criteria were not met ... then it was no
longer possible to claim that SSL was satisfying the security
requirements for electronic commerce.

The user had to provide the URL (and understand the relationship between
the website they thought they were talking to and the provided URL) to
satisfy the end-to-end security paradigm needed for SSL. Anything that
interfered with that was going to create security exposures and
vulnerabilities. It was obvious that the whole button click paradigm
would obfuscate the relationship between URL and website. It was further
obvious that security risks were especially part of any environment
where non-validated and non-trusted sources might provide click buttons
(and the corresponding URL). This was part of the analysis that if the
initial merchant website contact/URL wasn't validated ... then it could
be a potentially fraudulent website, and therefor any click button
providing a URL (originating from a potentially fraudulent website)
couldn't also be trusted (even if it involved a valid SSL digital
certificate).

It became really borken when "click" buttons started to show up in
untrusted/unvalidated "spamming" email ... taking the enduser to
fraudulent websites (potentially with valid SSL digital certificates).
However, simple end-to-end security analysis shows that clicking on
buttons (providing URLs) from sources that aren't trusted/validated,
then there isn't a lot of reason to believe the resulting session (even
with SSL) is to be trusted.

Endusers were encouraged to believe that SSL provided end-to-end
security for electronic commerce. this helped convince merchants that
they should pay for the digital certificates in support of SSL
operation. click buttons broke critical part of the end-to-end paradigm
that SSL (for electronic commerce) was dependent on.

Re: How to tell a fake SSL certificate from a real one

Anne & Lynn Wheeler wrote:

> This was part of end-to-end evaluation of using SSL for electronic
> commerce application. The problem was that as soon as the end-user
> starting clicking on buttons (that provided the URL) ... it
> invalidated the original requirements needed for meeting the

Nonsense. It' modified the "problem" slightly, and had no impact what
so ever on most of what we're discussing here.

The URL is still available for the user to inspect if they care to
glance at an address or status bar. So your theory fails on that fact
alone. However *most* users are still going to be providing their own
links when engaging in mission critical activities anyway, in the form
of previously stored (and working) bookmarks or such. Many will even be
typing in www.mybank.com (I do every time I visit my bank site). So
while your "theory" may hold true in select first encounter scenarios,
for the *vast* number of SSL connections it's completely irrelevant
even as a minor modification to the problem of user attentiveness.

> Endusers were encouraged to believe that SSL provided end-to-end
> security for electronic commerce. this helped convince merchants that
> they should pay for the digital certificates in support of SSL
> operation. click buttons broke critical part of the end-to-end
> paradigm that SSL (for electronic commerce) was dependent on.

I realize you're just cutting and pasting here, but do you have any
idea how tinfoil beanie this is beginning to sound? ;)

Re: How to tell a fake SSL certificate from a real one

Nomen Nescio writes:
> The URL is still available for the user to inspect if they care to
> glance at an address or status bar. So your theory fails on that fact
> alone. However *most* users are still going to be providing their own
> links when engaging in mission critical activities anyway, in the form
> of previously stored (and working) bookmarks or such. Many will even be
> typing in www.mybank.com (I do every time I visit my bank site). So
> while your "theory" may hold true in select first encounter scenarios,
> for the *vast* number of SSL connections it's completely irrelevant
> even as a minor modification to the problem of user attentiveness.

re:
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real on
http://www.garlic.com/~lynn/2007r.html#17 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#18 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#19 How to tell a fake SSL certificate from a real one

the counter example is the subsequent vast proliferation of spamming
email with "click" URL and the problem with phishing websites ... as per
previous post.

the theory behind and design point of digital certificates and PKIs were
the letters of intent/introduction from sailing ship days for first time
interaction between strangers where the relying party had no other
recourse to the information about the party they were dealing with.

this recent post discusses some of the limitations on the actual value
of digital certificates and PKIs in SSL and other protocols for
electronic commerce
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game

where, in fact, the vast majority of electronic commerce transactions
involved repeated and/or well-known websites (i.e. transactions rates
quite skewed, negating the underlying justification for using PKI and
digital certificates in these applications).

original justification for using SSL for electronic commerce (by
far the most widely deployed use of SSL in the world) was

* is the website that the user think they are talking to, actually
the website they are talking to (SSL use for this was dependent
on user knowing the relationship between the website they believed
they were talking to and the corresponding URL)

* hiding information (typically transaction account numbers) for
information in transit

going to "known" websites with URLs from trusted repository easily
eliminates the justification and requirement for digital certificates
and PKI operation ... i.e. if there is a trusted respository of URLs
then it is possible to store the associated public keys in the same
repository. this is the certificateless mode of operation
http://www.garlic.com/~lynn/subpubkey.html#certless

recent discussion about (redundant and superfluous) certificate/PKI
operation being added to the simple public key specification of
for kerberos
http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos
http://www.garlic.com/~lynn/2007q.html#5 Windows Live vs Kerberos

or old email from 1981 discussing pgp-like public key proposal
http://www.garlic.com/~lynn/2006w.html#email810515

even before we had finished the SSL related activity for
doing payment transactions on the internet ... something
that is frequently now referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#payment

.... we had started to realize that PKIs and digital certificates were
redundant and superfluous for most applications. As part of deploying
the backend portion (between webservers and something called a payment
gateway) we had specified requirement and implementation for (first) SSL
mutual authentcation. However, both the websites and payment gateway
was registered with the other, respective party ... making the
digital certificates redundant and superfluous (other than re-using
existing SSL library with requirement to have something called
a digital certificate).

Eliminating the requirement for digital certificates ... and the client
starting out with the servers public key (along with the servers URL),
it is possible to do a drastically simplified and lower overhead
SSL-like protocol.

The case for trusted respository of URLs ... along with the elimination
for any digital certificates ... can be extended to not only local
repositories ... but also online repositories like a secure, trusted DNS
.... where public keys are stored along with the mapping of domain name
to ip-address. Starting out the client-side of the protocol already
having the server-side public key ... can simplify the protocol
.... misc. past posts discussing how improving the security of DNS (with
registered public keys) is important to SSL domain name certification
authorities ... but also can represent a catch22 ... also eliminating
any requirement for PKI, certification authorities, and digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

in the mid-90s, after having worked on what is now comingly referred
to as electronic commerce (and associated SSL deployments), we
got involved with the x9a10 financial standard working group that
had been the requirement to preserve the integrity of the
financial infrastructure for all retail payments (internet,
non-internet, point-of-sale, debit, credit, stored-value/gift,
check/ach, card-present, card-not-present, etc ... i.e. ALL).
the result was x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959

part of the effort was doing some detailed threat and vulnerability
analysis ... for all kinds of retail transanctions (not just the
internet ones ... represented by electronic commerce, and the largest
deployed use for SSL). A big problem was the ease that account numbers
could be used for performing fraudulent transactions. Account numbers
showed in in a vast array of places ... things like internet
transmission (i.e. "data-in-flight") where SSL was being used to "hide"
the information ... but also things like transaction repositories
(i.e. "data-at-rest") which were required by a large number of backroom
processes (not normally apparent to customers and the general public).
This is somewhat the general "harvesting" vulnerability (skimming,
evesdropping, data breaches, security breaches, phishing, etc) ... lots
of past posts
http://www.garlic.com/~lynn/subintegrity.html#harvest

the vast number of places that account numbers existed and were required
led to the comment that even if the planet were buried of information
hiding encryption ... it still couldn't prevent leakage. so the x9.59
approach was to eliminate account number leakage as a vulnerability
(i.e. skimming, evesdropping, data breaches, security breaches,
phishing, etc, could still happen but the information wouldn't be useful
to the attackers).

the side-effect is not only doesn't it eliminate fraud from data
breaches and security breaches ... but also any evesdropping exploits on
the internet ... the type of thing that SSL is targeted at preventing
(and the major deployment purpose of SSL in the world today).

First off, there are numerous reasons that PKI and digital certificates
for SSL have become redundant and superfluous. Then it can be shown that
a single, common protocol (x9.59) ... can eliminate the major deployed
use of SSL for hiding accounts numbers at the same time eliminating much
of the fraud that arises from data and security breaches.

Re: How to tell a fake SSL certificate from a real one

In message
Anonymous wrote:

>The SSL certificate used by your router *must* be registered to the
>router manufacturer, not some arbitrary IP address. This is a perfect
>case of a valid certificate generating the warnings it's suppose to
>generate because it's used in an implementation where it's impossible
>to do it any other way and still maintain a secure connection to your
>router. Linksys has no way of knowing that what your router's internal
>IP address will be.

Not at all. A self-signed certificate generated by the router with a
valid hostname would be best, since the user can simply install the
certificate once and never have warnings again.

Linksys simply cannot get a certificate registered for "192.168.0.1"
even if they wanted one.

Another option though, and this would be fairly trivial to implement if
Linksys (and others) were actually serious about security. Purchase a
certificate for "router.linksys.com", on the internet point that IP to
192.168.0.1 (or whatever is the standard for routers that use that
default) and then have the router's DNS server override that mapping and
supply the valid IP.

This would work for all browsers and all networks where the network uses
the router as a DHCP server, and the router passes DNS up to the ISP (as
is the case with most consumer grade routers)

As it is, they distribute a certificate which isn't valid, thereby
adding virtually no security, and worse, training users to ignore
certificate errors.

I consider that a negative in the grand scheme of things.

--
You can get more with a kind word and a 2x4 than just a kind word.

Re: How to tell a fake SSL certificate from a real one

DevilsPGD wrote:

> In message
> Anonymous wrote:
>
> >The SSL certificate used by your router *must* be registered to the
> >router manufacturer, not some arbitrary IP address. This is a perfect
> >case of a valid certificate generating the warnings it's suppose to
> >generate because it's used in an implementation where it's impossible
> >to do it any other way and still maintain a secure connection to your
> >router. Linksys has no way of knowing that what your router's
> >internal IP address will be.
>
> Not at all. A self-signed certificate generated by the router with a
> valid hostname would be best, since the user can simply install the
> certificate once and never have warnings again.

That's the problem. Routers don't have valid host names from where
you need to access them from. Internally they're straight IP addresses.
Your suggestion would mean that every router would have to have a
public facing administrative interface (and no private administrative
interface).

Noooooooo thankyou. ;)

> Linksys simply cannot get a certificate registered for "192.168.0.1"
> even if they wanted one.
>
> Another option though, and this would be fairly trivial to implement
> if Linksys (and others) were actually serious about security.
> Purchase a certificate for "router.linksys.com", on the internet
> point that IP to 192.168.0.1 (or whatever is the standard for routers
> that use that default) and then have the router's DNS server override
> that mapping and supply the valid IP.

First of all, there is no standard. There's defaults, they vary from
router to router, and they can easily be changed (in many cases they
have to be).

Second of all this is flatly impossible. the 192.168.x.x IP block is
what's known as "non-routable". Those addresses can't be resolved from
the outside under any circumstances. If they could, every router still
set at defaults would conflict with every other similar router.

> This would work for all browsers and all networks where the network
> uses the router as a DHCP server, and the router passes DNS up to the
> ISP (as is the case with most consumer grade routers)
>
> As it is, they distribute a certificate which isn't valid, thereby

That's not true at all. The certificate is perfectly valid. And it's
trivial to decide whether or not to accept it in spite of the "doesn't
match" error *because* it's coming from a non-routable address. You're
manually entering the address, and that address can't exist anywhere
outside your local network (from your perspective). It's a sure bet the
certificate is kosher.

> adding virtually no security, and worse, training users to ignore
> certificate errors.

No security??

On the contrary, it's very hard security. Local networks are easier to
sniff than the Internet proper. For a home user with a single machine it
may not matter, but anything more complex than that and the SSL
encrypted connection is in some ways more critical than SSL connections
to outside servers. You're talking about the boundary equipment that
controls how traffic flows into, out of, and through the local net. Own
that, and you own every machine on that local net.

> I consider that a negative in the grand scheme of things.

I don't think you really understand what a router looks like on a
network. And you obviously don't understand non-routable IP
addresses. ;) There's no negative or positive about it really, it's
just the way things must be if you want a secure connection to your
router. It's silly to think that Linksys or anyone else should have to
have a different certificate for every piece of equipment they produce,
and it can't be done anyway because by default every model/series/class
of equipment is the same.

It simply just can't work that way.... :(

Re: How to tell a fake SSL certificate from a real one

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Anonymous schrieb:

> Joan Battaglia wrote:

>> Is THIS a fake certificate?

It is not.

>> Here's what happened.
>> I went to http://torcheck.xenobite.eu/index.php

I'm the maintainer of that site.

> Yes. at this juncture you're dealing with a fake certificate. You have
> no way of immediately knowing whether or not someone has hijacked your
> connection to xenobite.eu, and is trying to "sniff" some bit of
> important information. You should immediately drop the connection and
> start asking questions. Which you just did. :-)

There is a way..

[...]

> protecting in the first place? This particular test is to show you what
> information your browser hands out over an HTTP connection as opposed to
> an HTTPS connection. That information can be different. especially if
> you're using something like Privoxy to scrub content. Privoxy can't see
> content inside an HTTPS connection so that scrubbing fails. A good
> reason to leave all that stuff in the hands of your browser itself, and
> plugins like NoScript. They can scrub content/headers before the data
> is encrypted.
> The Xenobite test is specifically designed to bring the above points to
> light, FWIW.

Yes, right!

[...]

> You might also use DNS to verify the IP address of Xenobite, however
> any IP could be in the certificate owner's field so this isn't reliable
> even if you're doing secure DNS lookups. This is where known trusted
> CA's come into play, and the certificate in question isn't signed by
> any.

Since the certificate is signed and contains a correct host in it's CN,
you're wrong in this case.

There is no need to provide a named host for proving connection trust,
because the more basic endpoint descriptor - the IP address - is a
somewhat more reliable factor for simple connection security, in my
opinion. It cannot be spoofed so easyly like DNS can be..

> Another way is to compare the fingerprint of the certificate with the
> fingerprint other people see. Using the SHA fingerprint because it's
> somewhat more secure...
>
> Yours:
>
> D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61:11:B9:1B
>
> Mine:
>
> D3 CF DC 24 BC 3E E9 59 27 2B 82 51 27 67 D2 E8 61 11 B9 1B
>
> They match, so you know someone isn't attacking your connection
> specifically. I visited the site "naked", so you know it's not a Tor
> node, if anyone has managed to compromise the other end.

Exactly this you should do with the fingerprint information provided on
that page down below:

# Certificate's MD5 Fingerprint =
24:00:31:6D:F3:3B:E2:90:BC:73:CE:4D:BF:9C:2A:D7
# Certificate's SHA1 Fingerprint =
D3:CF:DC:24:BC:3E:E9:59:27:2B:82:51:27:67:D2:E8:61:11:B9:1B

Compare the numbers with your browser notification and on positive match
you're fine.

> A few more confirmations, especially from people who have examined the
> cert in the past, and you have a reasonable assurance that the
> certificate is acceptable. I wouldn't trust anonymous confirmations
> though, I could be anyone. ;-) But I do know in this case that if you
> pursue those lines you'll find people who will confirm the fingerprint.
>
> You can dig even deeper than that if you want to, but at this point I'd
> say we've determined that Xenobyte is simply using a free, untrusted

The certificate *is* trusted by StartCom: Your browser is *not*
complaining about the trust, only about the different hostname!

> certificate for the purposes of demonstrating how SSL affects your
> anonymous connection. The information you're giving Xenobite isn't
> critical, the trust factor is more than high enough to make you feel
> "comfortable" with what you're doing, so you can safely accept the
> certificate and proceed with the test.
>
> If the same scenario occurs with your banking site, however, you should
> run like hell. ;)

Of course!

- --

The origin problem I was trying to solve, was to provide my multi domain
single IP host with a secured connection layer without uncovering all
those domain names to the public by placing them all in the certificate.

Since it is not technically possible to install different SSL
certificates on the same IP on such multi domain hosts, I've decided to
put the IP instead of the host/domain into the CN to cover *all* domains
with an all-same factor (IP) somehow, for more easy verification by the
user. Just using a different domain name as CN would be more difficult
to check for plausibility, thought.

By using SSL for securing the connection against eavesdropping, instead
of using it for proving site identity, I wish the applications
(browsers) could do a second/alternate comparison using the IP for
making IPs as CN usable without hassle for the visitors...



Greets

- --

BlueStar88
________________________________________________________
PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKP+V/GOJMzYVDIYRA8UTAKCMR0Te6toep3+aZmJPB+IOR9BELACf Ua9O
4nF0m3DDmaKFTGf0UATF4Rg=
=EI24
-----END PGP SIGNATURE-----

Re: How to tell a fake SSL certificate from a real one

BlueStar88 wrote:

> > protecting in the first place? This particular test is to show you
> > what information your browser hands out over an HTTP connection as
> > opposed to an HTTPS connection. That information can be different.
> > especially if you're using something like Privoxy to scrub content.
> > Privoxy can't see content inside an HTTPS connection so that
> > scrubbing fails. A good reason to leave all that stuff in the hands
> > of your browser itself, and plugins like NoScript. They can scrub
> > content/headers before the data is encrypted.
> > The Xenobite test is specifically designed to bring the above
> > points to light, FWIW.
>
> Yes, right!
>
> [...]
>
> > You might also use DNS to verify the IP address of Xenobite, however
> > any IP could be in the certificate owner's field so this isn't
> > reliable even if you're doing secure DNS lookups. This is where
> > known trusted CA's come into play, and the certificate in question
> > isn't signed by any.
>
> Since the certificate is signed and contains a correct host in it's
> CN, you're wrong in this case.

No, I'm stating a fact. The certificate is not signed by any Trusted CA
that's installed in any software I use. Your mileage may vary of course.

> There is no need to provide a named host for proving connection trust,
> because the more basic endpoint descriptor - the IP address - is a
> somewhat more reliable factor for simple connection security, in my
> opinion. It cannot be spoofed so easyly like DNS can be..

Indeed. But the problem is that there's no such thing as "IP Based"
certificates (outside closed systems). So unless you rewrite SSL you're
still going to get errors that have to be dealt with. One way to deal
with them is to use IP addresses rather than domain names, but this
only changes the nature of the error.

> The certificate *is* trusted by StartCom: Your browser is *not*
> complaining about the trust, only about the different hostname!

You're wrong. My browsers complain because StartCom isn't a trusted CA.
And yes I realize it ships with *some* browsers by default, but when a
trusted CA can't even produce a certificate that doesn't invoke errors
when visiting their own website, my policy is to remove it. So my
preferred Opera browser complains by default, and Firefox complains by
design.

Again, YMMV. ;)

Re: How to tell a fake SSL certificate from a real one

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Nomen Nescio schrieb:

> BlueStar88 wrote:

>> Since the certificate is signed and contains a correct host in it's
>> CN, you're wrong in this case.
>
> No, I'm stating a fact. The certificate is not signed by any Trusted CA
> that's installed in any software I use. Your mileage may vary of course.

Right, but that does not denial to be a signed certificate anyway. And
it is not 'just' a self signed certificate. The only problem is, that
your individual browser installation does not know the specific CA in
question.

You may want to update your certificate repo:

https://cert.startcom.org/?app=131

And/or check again using this URL:

https://217.160.111.190/

It is another problem, that only big (money making) CA's are making it
into the wide spread commercial browsers by default. But it is the users
choice to add any other CA or self signed cert he trusts.
The browsers automatic trust to some several CAs is not the complete
deal on using SSL. A self chosen trust to another CA or to a single self
signed cert is fulfilling the job sufficently for simple connection
security.
And you should individually extend your personal policy to this. There
are others you can trust too! ;-)

The SSL developers should extend it, to cover connection security by IP
address only, like an additional simple trust mode..



Greets

- --

BlueStar88
________________________________________________________
PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKnsK/GOJMzYVDIYRA3JOAKCQAr/lPzAfOAAIL86od2DEyxbuWwCg kZOF
Ytu7oVxKwe+NVQ9nx+04iHc=
=37PD
-----END PGP SIGNATURE-----

Re: How to tell a fake SSL certificate from a real one

Anne & Lynn Wheeler writes:
> or old email from 1981 discussing pgp-like public key proposal
> http://www.garlic.com/~lynn/2006w.html#email810515

re:
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007q.html#73 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007r.html#12 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#17 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#18 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#19 How to tell a fake SSL certificate from a real one
http://www.garlic.com/~lynn/2007r.html#24 How to tell a fake SSL certificate from a real one


from my RFC index
http://www.garlic.com/~lynn/rfcietff.htm

recent PGP RFCs

http://www.garlic.com/~lynn/rfcidx16.htm#5081

5081 E
Using OpenPGP Keys for Transport Layer Security (TLS) Authentication,
Mavrogiannopoulos N., 2007/11/02 (8pp) (.txt=15300) (Refs 3280, 4346,
4366, 4880) (was draft-ietf-tls-openpgp-keys-11.txt)

http://www.garlic.com/~lynn/rfcidx16.htm#4880

4880 PS
OpenPGP Message Format, Callas J., Donnerhacke L., Finney H., Shaw D.,
Thayer R., 2007/11/02 (90pp) (.txt=203706) (Obsoletes 1991, 2440) (Refs
1423, 1950, 1951, 1991, 2045, 2440, 2822, 3156, 3447, 3629, 4086)
(Ref'ed By 5081) (was draft-ietf-openpgp-rfc2440bis-22.txt)

and as always ... clicking on the ".txt=nnn" field, retrieves the actual
RFC

could we be getting closer to certificateless SSL/TLS protocol?
misc. posts mentioning publickey certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless

for additional drift, posts mentioning possibility of general use of
"on-file" public keys (from the domain name system), including for a
SSL/TLS protocol like operation.
http://www.garlic.com/~lynn/subpubkey.html#catch22

and for even more drift ... a totally different DNS topic drift
(from a thread in comp.arch)
http://www.garlic.com/~lynn/2007r.html#48 Half a Century of Crappy Computing