The UK banks are encouraging us to join Verified by Visa (and the 
equivalent from MasterCard, to which this issue also applies), and may 
soon make it effectively compulsory.  However the marketing people in 
both Visa (MasterCard) itself and the UK banks do not seem to understand 
the authentication principles on which it is based.

What they are doing is providing a link, for registration, to an unknown 
US company, Cyota Inc (masquerading under a UK domain name), or at least 
that is what I see on the versions of their pages that I have fetched. 
The problem is that the Visa and bank VbV pages are on their insecure 
sites, so there is no protection from being fed a fake version of these 
pages pointing to the https site of a man in the middle.

I tried asking for confirmation of the Cyota URL over one of my internet 
banking sites secure mail system, but the support person refused to 
confirm the URL, saying the only URL they could provide was that of 
their insecure page.  Basically we have people who hopefully understand 
the issues, who developed VbV, but marketing and support people who 
don't understand the issues and undermine its security.

Does anyone know of a well known UK bank that uses the Cyota service and 
provides the signon link from a secure page, with an SSL certificate 
that belongs to them?  Otherwise, the main hope is that someone in VbV 
or UK banking who actually understands the principles upon which VbV is 
based and has influence with marketing will read this.

Whilst these links have pointed at Cyota for some time, so it is most 
unlikely that they are other than legitimate agents for the banks, I 
still feel unhappy having to rely on such weak tests of authenticity.

"David Woolley" <david@ex.djwhome.demon.co.uk.invalid> wrote in message
news:4892277e$0$620$5a6aecb4@news.aaisp.net.uk...
> The UK banks are encouraging us to join Verified by Visa (and the
> equivalent from MasterCard, to which this issue also applies), and may
> soon make it effectively compulsory.  However the marketing people in
> both Visa (MasterCard) itself and the UK banks do not seem to understand
> the authentication principles on which it is based.
>
> What they are doing is providing a link, for registration, to an unknown
> US company, Cyota Inc (masquerading under a UK domain name), or at least
> that is what I see on the versions of their pages that I have fetched.
> The problem is that the Visa and bank VbV pages are on their insecure
> sites, so there is no protection from being fed a fake version of these
> pages pointing to the https site of a man in the middle.
>
> I tried asking for confirmation of the Cyota URL over one of my internet
> banking sites secure mail system, but the support person refused to
> confirm the URL, saying the only URL they could provide was that of
> their insecure page.  Basically we have people who hopefully understand
> the issues, who developed VbV, but marketing and support people who
> don't understand the issues and undermine its security.
>
> Does anyone know of a well known UK bank that uses the Cyota service and
> provides the signon link from a secure page, with an SSL certificate
> that belongs to them?  Otherwise, the main hope is that someone in VbV
> or UK banking who actually understands the principles upon which VbV is
> based and has influence with marketing will read this.
>
> Whilst these links have pointed at Cyota for some time, so it is most
> unlikely that they are other than legitimate agents for the banks, I
> still feel unhappy having to rely on such weak tests of authenticity.

I'm probably missing something here - but I don't understand your concern. Why
is the link to the signon page from a normal ("unsecure") http page a problem?

Most banks have links to their interbank banking signon page from a normal http
page, and always have done, and sometimes that's the only way to get to the
signon page.

Provided they don't ask for the security details on the unsecure page what's the
problem?

Or are you thinking of a DNS server/host file hijack type scenario?

--
Andy

In article <4892277e$0$620$5a6aecb4@news.aaisp.net.uk>,
	David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> The UK banks are encouraging us to join Verified by Visa (and the 
> equivalent from MasterCard, to which this issue also applies), and may 
> soon make it effectively compulsory.

I read the terms and conditions when it first sprung up in front
of me, and since it seemed to change a number of fraud scenarios
to be my liability rather than the bank's, I declined it. It may
make fraud less likely, but I don't see why I should accept extra
fraud liability for doing so - that was too one-sided. So far,
one company lost my business by using it, and another had to take
a phone order rather than an on-line order.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

On Aug 1, 4:22 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> In article <4892277e$0$620$5a6ae...@news.aaisp.net.uk>,
>         David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>
> > The UK banks are encouraging us to join Verified by Visa (and the
> > equivalent from MasterCard, to which this issue also applies), and may
> > soon make it effectively compulsory.
>
> I read the terms and conditions when it first sprung up in front
> of me, and since it seemed to change a number of fraud scenarios
> to be my liability rather than the bank's, I declined it. It may
> make fraud less likely, but I don't see why I should accept extra
> fraud liability for doing so - that was too one-sided. So far,
> one company lost my business by using it, and another had to take
> a phone order rather than an on-line order.

Remind the bank that Consumer Credit Act limits your liability to the
first £50 of unathorised transactions on credit cards and in some
cases on debit cards as well.

wrote in message
news:a9e305c8-43a8-483e-b38f-13caec0cedbb@c58g2000hsc.googlegroups.com...
> > > The UK banks are encouraging us to join Verified by Visa (and the
> > > equivalent from MasterCard, to which this issue also applies), and may
> > > soon make it effectively compulsory.
> >
> > I read the terms and conditions when it first sprung up in front
> > of me, and since it seemed to change a number of fraud scenarios
> > to be my liability rather than the bank's, I declined it. It may
> > make fraud less likely, but I don't see why I should accept extra
> > fraud liability for doing so - that was too one-sided. So far,
> > one company lost my business by using it, and another had to take
> > a phone order rather than an on-line order.
>
> Remind the bank that Consumer Credit Act limits your liability to the
> first £50 of unathorised transactions on credit cards and in some
> cases on debit cards as well.

Indeed - however the problem is that the bank may argue that VbV is secure which
means that only you could have authorised the transaction (like they often do
with ATM withdrawals).

Ironically, if you did have a large disputed CC transaction it may be better to
tell the bank you were careless with your password ;-)

--
Andy

On Thu, 31 Jul 2008, David Woolley wrote:

> The UK banks are encouraging us to join Verified by Visa (and the equivalent
> from MasterCard, to which this issue also applies), and may soon make it
> effectively compulsory.  However the marketing people in both Visa
> (MasterCard) itself and the UK banks do not seem to understand the
> authentication principles on which it is based.

I've had the same problem with my bank, who insist that VbV increases 
security.  I've explained that I am being asked to submit a password to 
an insecure third-party site, and that password is one of the ones used 
to access my online bank account.  So I have gone from having that 
password in my head to access one system, to it being sent to an unknown 
third-party.  I am also concerned that in order to do this I was 
required to enable javascript, thus opening up another vector for no 
good reason.  From the conversations I've had with my bank it's clear 
that they don't "get it" and that they have been programmed to 
regurgitate the "VbV Is Good" marketing message.

-- 
Chris

[ I've changed the non-uk.finance crossposts as it turned out the groups 
weren't appropriate[A].  Because of that I'm not trimming the quoting 
this time. ]

Andy Pandy wrote:
> "David Woolley" <david@ex.djwhome.demon.co.uk.invalid> wrote in message
> news:4892277e$0$620$5a6aecb4@news.aaisp.net.uk...
>> The UK banks are encouraging us to join Verified by Visa (and the
>> equivalent from MasterCard, to which this issue also applies), and may
>> soon make it effectively compulsory.  However the marketing people in
>> both Visa (MasterCard) itself and the UK banks do not seem to understand
>> the authentication principles on which it is based.
>>
>> What they are doing is providing a link, for registration, to an unknown
>> US company, Cyota Inc (masquerading under a UK domain name), or at least
>> that is what I see on the versions of their pages that I have fetched.
>> The problem is that the Visa and bank VbV pages are on their insecure
>> sites, so there is no protection from being fed a fake version of these
>> pages pointing to the https site of a man in the middle.
>>
>> I tried asking for confirmation of the Cyota URL over one of my internet
>> banking sites secure mail system, but the support person refused to
>> confirm the URL, saying the only URL they could provide was that of
>> their insecure page.  Basically we have people who hopefully understand
>> the issues, who developed VbV, but marketing and support people who
>> don't understand the issues and undermine its security.
>>
>> Does anyone know of a well known UK bank that uses the Cyota service and
>> provides the signon link from a secure page, with an SSL certificate
>> that belongs to them?  Otherwise, the main hope is that someone in VbV
>> or UK banking who actually understands the principles upon which VbV is
>> based and has influence with marketing will read this.
>>
>> Whilst these links have pointed at Cyota for some time, so it is most
>> unlikely that they are other than legitimate agents for the banks, I
>> still feel unhappy having to rely on such weak tests of authenticity.
> 
> I'm probably missing something here - but I don't understand your concern. Why
> is the link to the signon page from a normal ("unsecure") http page a problem?
> 
> Most banks have links to their interbank banking signon page from a normal http
> page, and always have done, and sometimes that's the only way to get to the
> signon page.

In the better cases, these lead to an https URL in the well known domain 
  for that bank.  In the case I know of where this is not true, one can 
still check the subject of the SSL certificate for the secure domain and 
confirm that it was issued to that bank.

> 
> Provided they don't ask for the security details on the unsecure page what's the
> problem?

The domain name doesn't match Visa or the bank's well known domain name. 
  Alarm.  The domain name (something like securesite.co.uk) is 
pretentious.  Alarm (pretentious names are used by the more dodgy 
internet traders.  SSL certificate subject is neither the bank nor Visa. 
  Alarm.  SSL certificate subject is a US corporation.  Alarm (off shore 
companies trading under UK domain names are also an indication of a 
possible dodgy internet  trader, and one of the typical bits of internet 
buying advice is to check for a UK address, which all UK business sites 
are required to include, although many still don't).

Note.  A similar problem arises with many e-commerce sites which use an 
unknown service (their ISP?) for credit card processing, but the main 
risk there tends to be that authentication doesn't guarantee the company 
is trustworthy.[C]

> 
> Or are you thinking of a DNS server/host file hijack type scenario?

Yes.  Most, if not all, of the security related[B] reasons why one would 
want to buy an SSL certificate rather than using a self signed one.

As I understand it, in terms of actual hacker activity, DNS poisoning is 
the most likely attack, but anywhere outside of the client PC is 
vulnerable to attack.  I could be wrong,  but I suspect the insecure, 
marketing, web sites of banks are not as highly secured as their secure 
operational systems.

Incidentally, subject to finding out how it actually works, I have 
concerns that the transaction verification stage of VbV is trivially 
vulnerable to man in the middle attacks, unless, possibly, one uses SSL, 
rather than the VbV methods to authenticate the VbV server.  Does that 
certificate also point to someone other than Visa?

What could have been done, for registration, in roughly decreasing order 
of desirability is:

- Use the chip and PIN calculators, that the banks have been dishing 
out, in sign mode - this may avoid the need to register entirely.

- Don't outsource the process.

- Only outsource it as as far as Visa.

- Supply the VbV contractor with a subdomain of the bank's domain, on 
which to run a virtual server for the bank, and give them the 
corresponding SSL certificate; or the same, but at the Visa level.

- Put the final link to the contractor's secure site on an https site in 
the bank or Visa's domain name space.

- Supply them with an SSL certificate for a subdomain of their domain, 
which should be a .com domain representing their business name, so that 
people are not misled about the location to where they are sending data.

- Make prominent announcements in non-internet media telling people the 
domain name to check for when they register, and what the subject of its 
SSL certificate will be.

- Supply that information on demand when requested by people who care 
about security.

Note A. I wanted this to have some exposure on a newsgroup frequented by 
people who understand intenet security, but made some poor choices of 
newsgroup.  I was thinking SSL when I used the SSH group, and the uk one 
seems to be weird, with encrpted messages.  Hopefully comp.security.misc 
will be better, although it is rather broad.

Note B. The non-security reason for buying a certificate is to stop a 
browser nag, but whilst some have argued that the whole certificate sale 
thing is a con, there is some value in a certificate here.

You do not need a browser root certificate signature for encryption and 
I believe that SSL can create anonymous certificates for key exchange, 
and even do without them, although I don't know to what extent browsers 
and servers support this.

Note C. Actually, outsourcing the credit card processing may be better 
than having ones own certificate, but only if one uses a well known 
service, like WorldPay or PayPal.  Even then, it would be advisable to 
indicate that service prominently on the web site and promotional 
material - I note that people are beginning to do that on the web sites.

The reason that reputable outsourcing is desirable, is that one doesn't 
need to trust a relatively unknown company with the credit card details.

Chris Lawrence wrote:

> good reason.  From the conversations I've had with my bank it's clear 
> that they don't "get it" and that they have been programmed to 
> regurgitate the "VbV Is Good" marketing message.
> 
The problem is that even to sort it within the bank you have got to get 
past the support drone, their supervisor, marketing promotions side, and 
reach someone on the technical side that understands trust in secure 
systems.  The full chain is worse.  It probably starts with the 
development side of Visa marketing, then goes to their technical people 
(or more likely it is outsourced, introducing another level of first 
line support). Starting back from the technical people you then have: 
(outsourced first line support), Visa marketing (development), Visa 
marketing (promotion), bank marketing (promotion), support management, 
and finally support drone.  Of these only the technical people may 
really understand.

When one introduces scripting, as well as making it more difficult for 
the customer to verify, you probably introduce a script programmer, who 
probably doesn't understand security.

I've pruned the crossposts, as the originals were poorly chosen.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> Note.  A similar problem arises with many e-commerce sites which use
> an unknown service (their ISP?) for credit card processing, but the
> main risk there tends to be that authentication doesn't guarantee the
> company is trustworthy.[C]

we were brought to consult with small client/server company that wanted
to do payment transactions on their server and had this technology they
had invented called SSL they wanted to use ... the result is now
frequently referred to as electronic commerce. Part of what was done was
something called a payment gateway ... and we mandated some amount of
the useage interface between the webservers and the payment gateway
... including implementing something called "mutual authentication"
(which didn't exist at the time). misc. past posts mentioning
payment gateway for electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

we also did detailed protocol and business process walk thru of SSL,
digital certificates and these new businesses calling themselves
certification authorities.

for the payment gateway process, SSL mutual authentication evolved to
the point where it was apparent that digital certificates were redundant
and superfluous ... and there use was just a side-effect of using the
existing SSL software library ... aka the payment gateway had table of
all authorized webservers and the webserver had table with details about
the payment gateway (so obtaining the corresponding public key from a
digital certificate was superfluous).

also, at the time, the use of SSL domain name authentication ... by
clients were based on some business process assumptions ... in order
to result in:

  the webserver that a client is interacting with ... is the
  webserver that they think they are interacting with

aka

1) the client understood that relationship between the server they
wanted to talk to and the server's URL

2) the client supplied the URL to the browser

3) the browser validated the digital certifcate obtained from the
server

4) the browser validated the URL corresponded with the URL in
the (validated) digital certificate

misc. past posts mentioning SSL domain name digital certficates
and/or domain name digital certification
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

Almost immediately electronic commerce webservers discouvered that SSL
cut their thruput significantly and they dropped back to using SSL just
for payment/checkout. This created a large disconnect in the assumption
about the SSL business process and the associated integrity/security
that it provided. No longer was SSL being used to validate the URL
provided for initial contact.

The payment/checkout paradigm has the (typically completely unvalidated)
webserver making claims about a button that is clicked on. The client
clicks on a button which results in the webserver supplying a URL to the
browser (not the client). This now typically creates a huge disconnect
between the webserver that a client thinks they are talking to and the
associated URL.

Since the browser is only validating that the authenticated supplied
digital certificate corresponds to the supplied URL (not by the client
but by the webserver that hasn't been authenticate) ... SSL typical is
now

  the webserver that a client is interacting with ... is the
  webserver that the webserver claims to be

There is a huge difference between validating that the webserver is the
webserver the client believes it to be vis-a-vis validating that the
webserver is the webserver that it claims to be. 

This is also at the root of phishing vulnerabiilties ...  an email has
verbage saying clicking on a button takes the client to a banking
webserver ... the actual URL is for some webserver under control of an
attacker ... who has applied for and obtained a valid domain name
digital certificate for that webserver (proving that the webserver is the
valid webserver for that URL).

The critical issue in the original SSL deployment that the client knew &
understood the relationship between the webserver they believe they were
talking to and that webserver's (SSL validated) URL. That has become
increasingly rare in the current environment.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

Anne & Lynn Wheeler wrote:

> There is a huge difference between validating that the webserver is the
> webserver the client believes it to be vis-a-vis validating that the
> webserver is the webserver that it claims to be. 

Which is the whole problem with the VbV registration process.  The 
average user doesn't look at the domain name and wonder why it has 
changed, but simply believes that all must be well because the 
connection is encrypted, even though they were sent there from a site 
that was unprotected.

> 
> This is also at the root of phishing vulnerabiilties ...  an email has
> verbage saying clicking on a button takes the client to a banking

Which is why banks should be encouraging people to challenge any 
unexpected domain name, rather than making unannounced domain name 
switches themselves (but they also use other bad practices, like using 
scripting)

This is particularly bad for VbV as VbV is about authentication.

Anne & Lynn Wheeler  writes:
> This is also at the root of phishing vulnerabiilties ...  an email has
> verbage saying clicking on a button takes the client to a banking
> webserver ... the actual URL is for some webserver under control of an
> attacker ... who has applied for and obtained a valid domain name
> digital certificate for that webserver (proving that the webserver is the
> valid webserver for that URL).

re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust

an email phishing countermeasure has been if the area to be clicked on
(i.e. between the ">" after the href URL and the "</a>") looks to be a
URL ... then the email client checks if the purported claimed URL
matches the actual URL in the href. A simple work-around/countermeasure
(by the attackers) is to not display anything that resembles a URL
... so there is nothing to match on.

However, i've seen cases (for at least some email clients) ... where
they take the hostname from what appears to be a displayed URL ...  and
do a string compare against the hostname in the actual href URL ... and
it is treated as valid, even if the attackers are using a much longer
hostname (that just has a prefix part that matches the hostname part of
what is displayed).

the URL may or may not be a HTTPS/SSL connection. However, even if it is
a SSL connection ... all the attackers need to have done is to obtain a
SSL digital certificate proving that the actual provided URL (in the
HREF, not what is displayed) is a valid URL.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> Which is why banks should be encouraging people to challenge any
> unexpected domain name, rather than making unannounced domain name
> switches themselves (but they also use other bad practices, like using
> scripting)

re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust


then you probably aren't going to like:

Huge rise in fraud against UK banks
http://www.vnunet.com/vnunet/news/2222850/fraud-against-uk-banks-rise-kpmg
Bank fraud rockets in wake of credit crunch
http://www.inthenews.co.uk/money/manchester-united/features/bank-fraud-rockets-in-wake-credit-crunch-$1233892.htm
Banks hardest hit by fraudsters in 2008
http://www.channelweb.co.uk/crn/news/2222802/banks-hardest-hit-fraudsters
Major fraud against banks soars
http://www.computerweekly.com/Articles/2008/07/29/231676/major-fraud-against-banks-soars.htm
US Web Banking Full of Security Flaws - Three out of four financial
institutions have security related issues
http://news.softpedia.com/news/US-Web-Banking-Full-of-Security-Flaws-90860.shtml
Study Claims Majority of Web Banking Sites Insecure
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1217276924837016561&block=
UK banks hit by record fraud levels
http://www.finextra.com/fullstory.asp?id=18791
e-banking cybercrime
http://www.securitypark.co.uk/security_article261863.html
Security shocker: 75% of US Bank websites have flaws
http://www.theregister.co.uk/2008/07/25/bank_sites_insecure/
Three in Four Banks Exposed to Fraud Online: U Mich study
http://www.financetech.com/news/showArticle.jhtml?articleID=209601142
e-banking not yet secure
http://attrition.org/pipermail/dataloss/2008-July/002565.html
Study on Bank Site Security Design Flaws
http://bankwebsecurity.blogspot.com/
Banks warned of computer 'super bug' that can change identity
http://business.scotsman.com/bankinginsurance/Banks-warned-of-computer-39super.4328710.jp
Web banking security flaws 'widespread'
http://www.vnunet.com/vnunet/news/2222561/security-flaws-widespread-web
It's reality: legitimate websites are no longer safe (security breach)
http://www.securecomputing.net.au/News/117708,its-reality-legitimate-websites-are-no-longer-safe.aspx
Design flaws, besides vulnerabilities, hurt banking sites
http://www.networkworld.com/news/2008/072308-design-flaws-besides-vulnerabilities-hurt.html
Study finds bank websites vulnerable to hackers
http://www.latimes.com/business/la-fi-bankweb24-2008jul24,0,1619927.story
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549&source=NLT_AM&nlid=1
Online Banking: Widespread Security Flaws Revealed
http://www.livescience.com/technology/080723-online-banking.html
Three out of four banking websites have serious security flaws - study
http://www.tgdaily.com/content/view/38553/108/
Widespread Flaws In Online Banking Security Found
http://www.redorbit.com/news/technology/1491509/widespread_flaws_in_online_banking_security_found/index.html
Online Banking Security Flaws
http://www.technologynewsdaily.com/node/10099
Security flaws in online banking sites found to be widespread
http://www.physorg.com/news136023039.html
Summary Box: Study sees online banking flaws
http://news.yahoo.com/s/ap/20080723/ap_on_hi_te/tec_banking_security_summary_box
Studies: Banking Web sites, corporate computers are insecure
http://news.yahoo.com/s/cnet/20080723/tc_cnet/830110093999810683
Study: Online banking possibly dicier than assumed
http://news.yahoo.com/s/ap/tec_banking_security
Most Bank Websites Are Insecure
http://it.slashdot.org/it/08/07/24/1227230.shtml
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://www.pcworld.com/businesscenter/article/148790/design_flaws_besides_vulnerabilities_hurt_banking_sites.html
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://news.yahoo.com/s/pcworld/20080723/tc_pcworld/148790
Researchers Find Security Flaws In Online Banking Sites
http://www.consumeraffairs.com/news04/2008/07/online_banking.html
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549
Most Bank Sites Are Insecure
http://www.informationweek.com/news/internet/security/showArticle.jhtml?articleID=209600041
Study: websites of financial institutions insecure by design
http://arstechnica.com/news.ars/post/20080723-study-websites-of-financial-institutions-insecure-by-design.html
Study: Online banking possibly dicier than assumed
http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2008/07/23/financial/f120506D22.DTL

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

Changing the subject to address non-VbV aspects.

Anne & Lynn Wheeler wrote:
> David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
>> Note.  A similar problem arises with many e-commerce sites which use
>> an unknown service (their ISP?) for credit card processing, but the
>> main risk there tends to be that authentication doesn't guarantee the
>> company is trustworthy.[C]
> 
> we were brought to consult with small client/server company that wanted
> to do payment transactions on their server and had this technology they
> had invented called SSL they wanted to use ... the result is now
> frequently referred to as electronic commerce. Part of what was done was
> something called a payment gateway ... and we mandated some amount of
> the useage interface between the webservers and the payment gateway
> ... including implementing something called "mutual authentication"

Mutual authentication is much older than SSL (SSL doesn't really contain 
anything new, it just popularised techniques).  For example, PPP, for 
dialup connections, supports it, even though Dial Up Networking, 
Microsoft's implementation of it, doesn't.  PPP is also new compared to 
the concept.  (Mutual authentication is used in spy stories, done 
verbally, and is used by military sentries.  The clickers used on D-Day 
were a form of mutual authentication.)

> (which didn't exist at the time). misc. past posts mentioning
> payment gateway for electronic commerce
> http://www.garlic.com/~lynn/subnetwork.html#gateway
> 
> we also did detailed protocol and business process walk thru of SSL,
> digital certificates and these new businesses calling themselves
> certification authorities.
> 
> for the payment gateway process, SSL mutual authentication evolved to
> the point where it was apparent that digital certificates were redundant
> and superfluous ... and there use was just a side-effect of using the
> existing SSL software library ... aka the payment gateway had table of

Note that the libraries don't need digital certificates.  There are ways 
of negotiating session keys that don't use them at all.  It is really 
the browsers and servers that impose that limitation.

> all authorized webservers and the webserver had table with details about
> the payment gateway (so obtaining the corresponding public key from a
> digital certificate was superfluous).

What you haven't said, but must be the case, is that, if they don't have 
public keys, they must have shared secrets. preferably a bit stronger 
than the last transaction number, and information that is secure by 
obscurity.

> 
> also, at the time, the use of SSL domain name authentication ... by
> clients were based on some business process assumptions ... in order
> to result in:
> 
>   the webserver that a client is interacting with ... is the
>   webserver that they think they are interacting with

That's generally the case for the targets of phishing attacks.  It is 
also the case for major brands, like Amazon, but a lot of transaction 
start from a Google search, and then the correct retailer name, or even 
whether the retailer really exists at all, is unknown.

(I am disappointed, though, that one of my banks uses a non-obvious 
domain name for their secure server, which forced me to read the SSL 
subject the first time I used it.)

> 
> aka
> 
> 1) the client understood that relationship between the server they
> wanted to talk to and the server's URL
> 
> 2) the client supplied the URL to the browser
> 
> 3) the browser validated the digital certifcate obtained from the
> server
> 
> 4) the browser validated the URL corresponded with the URL in
> the (validated) digital certificate
> 
> misc. past posts mentioning SSL domain name digital certficates
> and/or domain name digital certification
> http://www.garlic.com/~lynn/subpubkey.html#sslcerts
> 
> Almost immediately electronic commerce webservers discouvered that SSL
> cut their thruput significantly and they dropped back to using SSL just
> for payment/checkout. This created a large disconnect in the assumption
> about the SSL business process and the associated integrity/security
> that it provided. No longer was SSL being used to validate the URL
> provided for initial contact.

That doesn't actually matter as long as one re-checks the domain name on 
the transition to a secure connection.  The problem is that e-tailers 
have been telling everyone that SSL is only about encryption, so they 
are not educated to make this check, and sometimes vanity issues result 
in significant obfuscation (e.g. using frames, or turning off chrome).

It is also important that significant information about the transaction 
  is reconfirmed in the authenticated part of the transaction - in 
particular transaction value (as a limit on risk) and delivery address, 
although the details of the order are also a good idea.

> 
> The payment/checkout paradigm has the (typically completely unvalidated)
> webserver making claims about a button that is clicked on. The client
> clicks on a button which results in the webserver supplying a URL to the
> browser (not the client). This now typically creates a huge disconnect
> between the webserver that a client thinks they are talking to and the
> associated URL.

The main conflict here is between "web designers" and the browser.  Web 
designers may want the ability to hide this subcontracting and browsers 
tend to go along with this, but browsers could be made to force the URL 
for an authenticated connection onto the user.  I do though, note a 
trend towards positively identifying the payment gateway, where it is a 
major brand, probably because it increases consumer trust, and because 
consumers are becoming aware of this "disconnect".

As I noted in my footnote, where the e-tailer is an unknown, but the 
payment gateway is well known, knowing that one is talking to the 
gateway can actually be more comforting for the customer than knowing 
one is talking to the e-tailor domain name one is talking to, especially 
if the gateway identifies the e-tailer it is serving.

The problem I have found is when an e-tailer that I marginally trust 
hands off to their ISP's payment gateway, or a minor league gateway, 
because they can't afford to buy a certificate for themselves or to use 
one of the well known payment services.  This may be becoming less 
frequent, because of the increasing availability of well known payment 
services, although it can still be difficult keeping track of all the 
services.
> 

> The critical issue in the original SSL deployment that the client knew &
> understood the relationship between the webserver they believe they were
> talking to and that webserver's (SSL validated) URL. That has become
> increasingly rare in the current environment.

And one of the problems here is that many e-tailers seemed to be unaware 
of the authentication concept, and SSL was sold to the general public 
purely on the basis of encryption, which, as you point out, doesn't need 
certificates.
>

David Woolley wrote:
> 
> Anne & Lynn Wheeler wrote:

>> for the payment gateway process, SSL mutual authentication evolved to
>> the point where it was apparent that digital certificates were redundant
>> and superfluous ... and there use was just a side-effect of using the
>> existing SSL software library ... aka the payment gateway had table of
> 
> Note that the libraries don't need digital certificates.  There are ways 
> of negotiating session keys that don't use them at all.  It is really 
> the browsers and servers that impose that limitation.

Note that, because the internet is vulnerable to man in the middle 
attacks, you cannot safely negotiate session keys without simultaneously 
authenticating, even though I believe the SSL libraries allow this. 
That authentication can be done with symmetric keys, and in the extreme 
case, authentication can simply be the result of using the master key 
without negotiating a session key.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> What you haven't said, but must be the case, is that, if they don't
> have public keys, they must have shared secrets. preferably a bit
> stronger than the last transaction number, and information that is
> secure by obscurity.

re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust

I didn't say they didn't have public keys ... i claimed that the digital
certificates were redundant and superfluous.

for some topic drift ... the original public key draft for Kerberos
was certificate-less ... with digital certificate specification added
later (kerberos is a widely used authentication infrastructure available
on mainly platforms, including windows)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

there have also been certificateless public key implementations dones
for RADIUS ... a widely used authentication mechanism used by
ISPs and corporate intranets ... frequently the mechanisms found
at the server end of PPP connections
http://www.garlic.com/~lynn/subpubkey.html#radius

misc. posts mentioning public key & digital signature authentication
w/o requiring digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

in the certification authority model ... a public key is generated and a
certification authority does some validating about the entity associated
with the public key and other information associated with the entity.
it then issues a digital signed digital certificate (including the
entity's public key and the associated information).

this is part of the process that we long ago and far away audited
... when the organizations calling themselves certification authorities
were new & young.

however, for this to work ... a browser (or other application) has a
built-in table of public keys (belonging to certification authorities)
that are used to validate/authenticate the (certification authorties)
digital signature on the digital certificate ... as the step where the
browser/application "validates the digital certificate (before
trusting/making use of the public key included in the digital
certificate).

so the payment gateway provides its public key directly to the
webservers as part of all the other stuff that the payment gateway
provides to the webserver for correct operation. each webserver provides
their public key to the entity operating the payment gateway (as part of
a whole lot of other information that they need to provide). the
exchanged public keys are kept in tables in much the same way that
browsers keeps a table of (trusted) certification authority public keys.

involving an independent (redundant and superfluous) 3rd party
certification authority in the process, is redundant and superfluous and
the digital certificates that they issue are then also redundant and
superfluous.

the digital certficate scenario is the electronic analogy to letters of
credit/introduction from the sailing ship days when the relying party
had first time encounter with complete stranger and had no other
recourse to information about the stranger they were dealing with.

the digital certificate design point is the offline email paradigm from
the early 80s; the electronic postoffice is dialed, email exhanged,
connection is broken ... and there is first-time communcation between a
complete stranger. In the absence of any other mechanism for information
about the stranger, a digital certificate can be better than nothing.

after having realized that digital certificates were redundant and
superfluous in situations where the parties already have information
about each other and/or have online access to information about each other
... which was part of setting up payment gateway for electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

we were brought in to the x9a10 financial standard working group
that had been given the requirement to preserve the integrity of the
financial infrastructure for all retail transactions ... which resulted
in the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

some of the other financial transactions efforts going on in that period
(that also involved public key) ... were heavily steeped in digital
certificates. a serious roadblock for them was that the digital
certificate paradigm increased the typical payment transaction size by a
factor of 100 times as well as increasing the processing overhead by a
factor of 100 times. misc. past posts mentioning the enormous bloat that
(redundant and superfluous) digital certificates represented for payment
transactions 
http://www.garlic.com/~lynn/subpubkey.html#bloat

the x9a10 financial standard working group had been given the
requirement to preserve the integrity of the financial infrasturcture
for *ALL* retail transactions ... and so we had a lot of payload size,
transaction processing overhead and protocol chatter constraints that
other efforts simply ignored.

for other topic drift ... recent posts in crypto mailing list regarding
certificateless public key in the DNSSEC scenario and a hypothetical
superfast SSL "lite"
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> Note that, because the internet is vulnerable to man in the middle
> attacks, you cannot safely negotiate session keys without
> simultaneously authenticating, even though I believe the SSL libraries
> allow this. That authentication can be done with symmetric keys, and
> in the extreme case, authentication can simply be the result of using
> the master key without negotiating a session key.

re:
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle

for other topic drift, lots of past posts discussing man-in-the-middle
attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

one of the scenarios about certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless

is that the table of trusted (certification authorities) public keys
preloaded in browsers and PGP tables of trusted public keys are
effectively the same mechanism ... they are directly *trusted* public
keys. 

certification authorities and digital certificates provide a mechanism
for indirect trust (ala letters of credit/introduction model from
sailing ship days) when there is no other source for the information.

for other topic drift ... part of recent thread in crypto mailing list
and(uk) financial crypto blog about historical pgp (and certificateless
public key)
http://www.garlic.com/~lynn/2008i.html#86 Own a piece of the crypto wars
http://www.garlic.com/~lynn/2008i.html#87 Historical copy of PGP 5.0i for sale -- reminder of the war we lost

there is archeological reference to old email from '81
http://www.garlic.com/~lynn/2006w.html#email810515

for a (certificateless) pgp-like implementation ... approx.  decade
before pgp.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> It is also important that significant information about the
> transaction is reconfirmed in the authenticated part of the
> transaction - in particular transaction value (as a limit on risk) and
> delivery address, although the details of the order are also a good
> idea.

there is overlap in this area between x9.59 financial transaction
standard (usable with certificate-less public key) ... references
http://www.garlic.com/~lynn/x959.html#x959

and the EU FINREAD standard ... misc. past posts discussing
issues and objectives of the EU FINREAD standard
http://www.garlic.com/~lynn/subintegrity.html#finread

... i.e. how do you know that the transaction being digitally
signed is really the transaction that you think it is.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

Anne & Lynn Wheeler wrote:

> I didn't say they didn't have public keys ... i claimed that the digital
> certificates were redundant and superfluous.
> 
Agreed.  And, in fact, in the case of businesses with a significant 
non-web presence (like banks and Visa!) it would be quite possible for 
them to publish their key fingerprint on their printed literature and 
letterheads (although the concept might be too technical for the 
marketing people) and the full key on the web. Visa could even put a key 
fingerprint on every Visa card!

However, when you have an American subcontractor pretending to be a UK 
web site, you are not going to know how to find the key fingerprint.

Incidentally, as I'm sure you know, in the sort of extranet environment 
that you describe, you can create a self signed certificate, and install 
it in the browser, so that the browser now trusts you as though it had a 
certificate from, say, Verisign.  Microsoft even provide tools for 
making these, although they claim they are only for testing.

Further topic drift: there are other flaws in the certificate system in 
that, by default, browsers come with all certificates enabled, but some 
represent higher levels of verification than others.  As the level of 
trust for some interactions may differ from that for others, one would 
really need to check the issuer on every access needing more than 
minimal authentication.  That's mainly dumbing down, but it has been 
suggested that you can basically buy the right to have a root 
certificate in a browser.  I think very few browser users realise that 
not all certificates are alike.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
> Further topic drift: there are other flaws in the certificate system
> in that, by default, browsers come with all certificates enabled, but
> some represent higher levels of verification than others.  As the
> level of trust for some interactions may differ from that for others,
> one would really need to check the issuer on every access needing more
> than minimal authentication.  That's mainly dumbing down, but it has
> been suggested that you can basically buy the right to have a root
> certificate in a browser.  I think very few browser users realise that
> not all certificates are alike.

there have been several discussions over the past decade on the
vulnerabiilty of the infrastructure when all certification authorities
are treated the same. simplest scenario is that if the probability of
any particular certification authority is X/year and there are 100
loaded certification authority public keys ... then a compromise of any
specific one (compromising the whole infrastructure) is 100*x/year.

One issue raised is what happens if a certification authority goes out
of business, what is the assurance of the associated private keys.

as discussed in this scenario
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
http://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model

mentioned in earlier post
http://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle

is the ssl domain name certification authority catch-22
http://www.garlic.com/~lynn/subpubkey.html#catch22

Basically, some number of the SSL domain name certification
authorities were supporting DNSSEC operation ... for a couple of
reasons.

1) the original SSL domain name digital certificates were, in part,
justified based on perceived weaknesses in the domain name
infrastructure. However, the SSL domain name certification authorities
rely on the integrity of the domain name infrastructure as to the "true"
owner of a domain (when validating requests for SSL domain name digital
certificates). Part of the DNSSEC scenario would include having domain
name applicants to register a public key as part of registering a domain
name. Then future communication would be digitally signed (authenticated
with the on-file public key), minimizing vulnerabilities like domain
name hijacking.  This improves the trust that certification authority
can correctly identify the true owner of a domain .... and validating
that the true owner is applying for an SSL domain name digital
certificate i.e. a fundamental basic trust issue for ssl domain name
digital certificate resides in whether the domain name infrastructure
correctly maintains the true owner of the domain name.

2) the current SSL domain name digital certificate process requires the
certification authority to perform the expensive, time-consuming, and
error-prone process of verifying that the digital certificate applicant
is the same as the owner on-file with the domain name infrastructure.
With an on-file public key, the certification authorities, can require
that SSL digital certificate applications be digitally signed.  They
then could do a real-time retrieval of the on-file public key and turn
an error-prone, time-consuming, and expensive verification process into
a much simpler, less-expensive and reliable authentication process.

this creates the catch-22, since if the certification authorities can do
real-time retrieval of on-file public key ... then it is possible that
the rest of the world could also.

the scenario is that a standard DNS host->ip-address lookup would
optionally piggy-back a (on-file) public key (and potentially other
crypto negotiation options) in the responseresponse.  Then an extremely
lightweight SSL ... has the client generating the random secret key,
encoding it with the server's public key and encrypting the initial
communication ... from the start (bypassing all the SSL protocol setup
chatter).

For additional topic drift ... in the 80s ... we had been involved in
both the NSFNET backbone activity ... some old email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
and various posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

and we were also on the XTP technical advisory board ... which was
looking at a highly efficient reliable protocol ... that would support
both efficient reliable transaction operation (minimum packet exchange
of 3 packets ... compared to minimum packet exchange of 7 packets for
TCP) as well as multicast and some number of other features. There was
also an attempt to get (ASC) X3S3.3 (us chartered organization for
standards involving the area around level 3 & level 4 in the OSI
networking model) ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

So in XTP terms (having access to the server's public key, either cached
from some previous interaction and/or piggy-backed on recent
name->ip-address response), a full transaction SSL-lite could be done in
the 3-packet minimum exchange ... prefixing the first packet with the
public key encoded random secret (session/transaction) key with an
appended encrypted transaction.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

On Thu, 31 Jul 2008 22:00:14 +0100, David Woolley
<david@ex.djwhome.demon.co.uk.invalid> wrote:

>The UK banks are encouraging us to join Verified by Visa (and the 
>equivalent from MasterCard, to which this issue also applies), and may 
>soon make it effectively compulsory.  However the marketing people in 
>both Visa (MasterCard) itself and the UK banks do not seem to understand 
>the authentication principles on which it is based.


When you ring up because it won't let you register they'll tell you
it's because it doesn't work in your choice of browser, that it's a
known issue and that it's tough.

The system sucks imo. iframes hidden and redirecting to god knows
where doesn't inspire confidence.

If shops only sold and delivered to the address on the card then it'd
solve a lot of problems.
-- 
http://www.freedeliveryuk.co.uk
http://www.holidayunder100.co.uk

"Andy Pandy" <spam8times@wonderful.spam.invalid> writes:
> I'm probably missing something here - but I don't understand your concern. Why
> is the link to the signon page from a normal ("unsecure") http page a problem?
>
> Most banks have links to their interbank banking signon page from a normal http
> page, and always have done, and sometimes that's the only way to get to the
> signon page.
>
> Provided they don't ask for the security details on the unsecure page what's the
> problem?
>
> Or are you thinking of a DNS server/host file hijack type scenario?

same thread in comp.security.misc
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
http://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
http://www.garlic.com/~lynn/2008l.html#33 Authentication in the e-tailer / payment gateway / customer triangle

we had been brought to consult with small client/server company that
wanted to do payment transactions on their server and had this
technology they had invented called SSL they wanted to use ... the
result is now frequently referred to as electronic commerce. Part of
what was done was something called a payment gateway ... and we mandated
some amount of the useage interface between the webservers and the
payment gateway ... including implementing something called "mutual
authentication" (which wasn't implemented at the time). misc. past posts
mentioning payment gateway for electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

we also did detailed protocol and business process walk thru of SSL,
digital certificates and these new businesses calling themselves
certification authorities.

for the payment gateway process, SSL mutual authentication evolved to
the point where it was apparent that digital certificates were redundant
and superfluous ... and there use was just a side-effect of using the
existing SSL software library ... aka the payment gateway had table of
all authorized webservers and each webserver had table with details
about the payment gateway (so obtaining the corresponding public key
from a digital certificate was superfluous).

also, at the time, the use of SSL domain name authentication ... by
clients were based on some business process assumptions ... in order
to result in:

  the webserver that a client is interacting with ... is the
  webserver that they think they are interacting with

aka

1) the client understood the relationship between the server they
wanted to talk to and the server's URL

2) the client supplied the URL to the browser

3) the browser validated the digital certifcate obtained from the
server

4) the browser validated the URL corresponded with the URL in
the (validated) digital certificate

misc. past posts mentioning SSL domain name digital certficates
and/or domain name digital certification
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

Almost immediately electronic commerce webservers discouvered that SSL
cut their thruput significantly and they dropped back to using SSL just
for payment/checkout. This created a large disconnect in the assumption
about the SSL business process and the associated integrity/security
that it provided. No longer was SSL being used to validate the URL
provided for initial contact.

The payment/checkout paradigm has the (typically completely unvalidated)
webserver making claims about a button that is clicked on. The client
clicks on a button which results in the webserver supplying a URL to the
browser (not the client). This now typically creates a huge disconnect
between the webserver that a client thinks they are talking to and the
associated URL.

Since the browser is only validating that the authenticated supplied
digital certificate corresponds to the supplied URL (not by the client
but by the webserver that hasn't been authenticate) ... SSL typical is
now

  the webserver that a client is interacting with ... is the
  webserver that the webserver claims to be

There is a huge difference between validating that the webserver is the
webserver the client believes it to be vis-a-vis validating that the
webserver is the webserver that it claims to be.

This is also at the root of phishing vulnerabiilties ...  an email has
verbage saying clicking on a button takes the client to a banking
webserver ... the actual URL is for some webserver under control of an
attacker ... who has applied for and obtained a valid domain name
digital certificate for that webserver (proving that the webserver is the
valid webserver for that URL).

The critical issue in the original SSL deployment was that the client
knew & understood the relationship between the webserver they
believed they were talking to and that webserver's (SSL validated)
URL. That has become increasingly rare in the current environment.

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70