How to tell a fake SSL certificate from a real one

How to tell a fake SSL certificate from a real one

Secure Home | Search | About
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
How to tell a fake SSL certificate from a real one Joan Battaglia 10-27-2007
Posted by Anonymous Sender on October 28, 2007, 12:58 am
If you were  Registered and logged in, you could reply and use other advanced thread options
bealoid wrote:

>
> [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. :(


Posted by Anne & Lynn Wheeler on October 28, 2007, 9:51 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> 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

Posted by Krazee Brenda on October 28, 2007, 1:22 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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."

Posted by on October 29, 2007, 8:16 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> 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



Posted by Nomen Nescio on October 28, 2007, 9:00 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Anne & Lynn Wheeler wrote:

<snip>

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.


Similar ThreadsPosted
Howto setup a certificate authority and create a signed certificate using openssl on Debian sarge March 16, 2005, 10:39 am
What are the real dangers of shared hosting ? May 8, 2004, 7:25 am
Have real exploits of arithmetic overflows happened? February 13, 2007, 12:45 pm
Re: It's a fake terrorist scare, folks August 24, 2006, 6:05 pm
Re: It's a fake terrorist scare, folks August 15, 2006, 2:24 am
Re: It's a fake terrorist scare, folks August 16, 2006, 2:14 am
Re: It's a fake terrorist scare, folks August 18, 2006, 2:22 am
Re: It's a fake terrorist scare, folks August 18, 2006, 2:25 am
Re: It's a fake terrorist scare, folks August 20, 2006, 7:25 am
Re: It's a fake terrorist scare, folks August 24, 2006, 4:20 pm

The site map in XML format XML site map

Contact Us | Privacy Policy