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.

Posted by Sebastian G. on October 29, 2007, 8:07 pm

If you were Registered and logged in, you could reply and use other advanced thread options

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?

Posted by Anne & Lynn Wheeler on October 29, 2007, 9:02 pm

If you were Registered and logged in, you could reply and use other advanced thread options

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

Posted by Nomen Nescio on October 29, 2007, 11:40 pm

If you were Registered and logged in, you could reply and use other advanced thread options

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? ;)

Posted by Anne & Lynn Wheeler on October 30, 2007, 11:36 am

If you were Registered and logged in, you could reply and use other advanced thread options

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

Similar Threads	Posted
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