Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers

From: Stefan Winter <[email-masked]>
Date: Thu, 28 Jul 2011 11:19:27 +0200

Hi,

>>> Lots of banks wants to use CCA for their users.
>> > 
>> > That is a non sequitur.
>> > 
>> > Banks (here in Germany) have abandoned tradtional TANs based on
>> > the unconditional presumption that client PCs are infested with
>> > malware, and most banks in Germany are currently replacing indexed TANs (iTAN)
>> > presumably based on the perception that malware on clients (trojans/phishing)
>> > has caught up with iTAN procedure complexity.
>> > 
>> > At this point, with the presumption that all client PCs are
>> > thoroughly infested with malware, going for a Single Sign-On
>> > mechanism would be completely braindead and irresponsible.
> So using client certificates for authentication is such a bad idea that
> there is no point in looking into issues on how to make it better?
>
> How is the German e-card supposed work then?

Just trolling around on this list every now and then, but can't resist
to comment because I got my new eID card and also HBCI access recently.

eID: The electronic identity card contains lots of personal details
about you in some credential storage. It must be put into a whitelisted,
EAL-whatever certified hardware device, connected via USB. There is one
well-defined application on your computer which can ask the reader to
retrieve a *subset* of the personal information stored. Other
applications on the computer talk to this one application via an API.
Your card reader will present the name of the application which wants
the data, the pieces of data it wants to have from your card, and will
ask for your authorisation to reveal that personal data. That is done
via display+PIN directly on the card reader; no secret information ever
leaks the card reader unless authorized directly on the device by the
user. [1]

This exhibits a property of the system which plain presentation of a
X.509 certs won't allow: send only a subset of the stored information.

It was refreshing to see this in action when I got my reader last week:
my car insurance website signalled they need my real name, birthdate and
birthplace to log me in to manage my insurance contract - not the rest
of "me" that the card stores as well. Did that, logged into their
website, no need to even create a username/password combo.

Note that I didn't use the term "client certificate" at all - the system
does involve PKI, but it's invisible to the user; all he has is a
hardware token and a PIN.

Sure: you need the card reader. Joe Sixpack can manage to go to a shop
and put money on the shelf to get it, I assume - he does that same thing
when buying a TV. Joe doesn't even have to know or care about how to get
a "certificate" - he just gets all the stuff piggybacked on his usual
plastic ID card.

Banking: These days, TAN lists are going away. Alternatively, several
approaches come into use:

a) cell phone transaction numbers: enter transaction details on website,
website generates a TAN for this very transaction, sends it along with
the input it received from you to your (pre-registered) cell phone, you
enter the number from the cell phone into the website. - A second,
independent channel makes sure that even if the PC's comms channel is
compromised, harm is prevented.

b) offline generated transaction numbers. You get a hardware device,
branded to your bank account (provisioned secrets). Its only interface
to the outside world is a black&white camera to read a bar code; and a
display to show a resulting TAN. Workflow is: you enter your transaction
details on the web site, they generate $SOMEDATA from it (which includes
the transaction details). $SOMEDATA is signalled to the hardware device
via barcode scan, which uses it to generate a TAN based on the
pre-provisioned secrets and $SOMEDATA. Bank does the same computation,
TANs must match. Again, a second channel comes to the rescue even if the
PC is compromised.

c) HBCI - Home Banking Computer Interface. There is no browser at
all(!). An application uses the HBCI API to talk to bank servers. Client
authenticates with a smart card to be put into a card reader. All crypto
again happens on the card reader. Joe sixpack gets the smart card+PIN by
checking a box on his bank acocunt application and doesn't need to know
anything more.

None of these use Client Certificates in a browser. All of them survive
if the PC is malware-infested. But yes, there are still attacks on these
- they are not the cure-all.

Greetings,

Stefan Winter

[1] There are also readers without a keyboard. If you use these, too bad
for you, because then your infested PC will log your PIN and so on.
Because of that, the system got quite some beating when introduced.

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 11:53:46 +0200

http://www.hbci-kernel.de/fints.htm

I'm happy that none the banks I have talked have any interests
in such crap.

The usage level of the German eID is hardly measurable either.

/A

On 2011-07-28 11:19, Stefan Winter wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 12:08:53 +0200

>> X.509 certs won't allow: send only a subset of the stored information.

Here I disagree. A system build with WebID enabled X509 certificates should be able to release subsets of information too. But instead of having the information come from your device, or be locked in the certificate, the information can come from RESTful access to your profile, or to related resources.

Here is one way to do this:

http://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo

This is just a generalisation of what your devices do. Think of adding a web server to the device in question. Then give profiles a URL, and then only show parts of the information to the authentified service requesting them. Now there is no reason to put a web server on that device, you might as well have it wherever you think is best. If you do that, you are starting to see how http://webid.info can work.

Henry

>> Because of that, the system got quite some beating when introduced.

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 12:36:12 +0200

Henry,
You're missing the point.

These two guys says that having a key in the PC is braindead,
particularly if you use it from a browser.

Based on 15 years of experience of s.c. "security experts" we
can safely drop this thread; it won't go anywhere.

This attitude was OK before we entered the "Google- and Apple-age".
It's an entirely different ball-game now!

Anders

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 13:12:13 +0200

> It's an entirely different ball-game now!

I hear different voices in this conversation. But the best thing
will be to build examples that can show how this technology can be
used in new ways. All good technology is like that: it escapes the
initial ideas of its creators.

Social Web Architect
http://bblfish.net/

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 02:45:11 +1200

Stefan Winter <[email-masked]> writes:

>Banking: These days, TAN lists are going away.

Is there any information on what's being done in countries like France, Italy,
the Netherlands, Spain, ...?  The only place where it's really documented (in
quite some detail) is Germany (with surrounding/similar countries like Austria
and Switzerland using equivalent approaches), but what are other countries in
Europe doing?  There's rather little information *from third parties, not the
vendors* publicly available on how e-banking is done in France, Spain, ...,
the pros and cons, how it deals with new attack types, and so on.

>a) cell phone transaction numbers:

The problem is that mTANs are vulnerable to smartphone malware, as Zeus has
already shown.  It's currently a minor threat, but who knows how far the bad
guys will take it.  On the whole though mTANs are a nice tradeoff, you get to
verify the transaction over an independent channel, and the mTAN is a
cryptographic hash over the transaction data so if a MITB tries to modify what
the browser sends it gets detected.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 17:00:22 +0200

> the browser sends it gets detected.

It may be nice from a security point of view but it is horribly inconvenient.
I don't believe for a second that "this is where we are going".

Apple's interest in becoming the PayPal for the physical world will
take mobile security to levels PCs never did.

In iPhone client-side PKI is already ease to enroll even for Joe Sixpack!

Anders

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 17:07:07 +0200

Hi Peter,

 You may want to ask Prof. Martin Gaedke about this. He is working his way through the 
EU area on this and should have some good pointers on where these token cards are 
going around here. 

   Henry

Social Web Architect
http://bblfish.net/

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 03:12:52 +1200

>I don't believe for a second that "this is where we are going".

It's standard for banks in (at least) NZ, SA, and possibly Australia.  From
talking to banking people involved with it, there haven't been any serious
problems.

(I've used mTANs before as a case study of "security works in practice but not
in theory", because when you tell security people about it they come up with
long lists of reasons why it'll never work, and then when you deploy it it
works just fine).

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 21:10:00 +0200

Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so
why would the browser vendor bother about how it works?

Now to the cards: Since
1. readers is a non-standard item
2. all cards need different middleware
3. cannot be fitted with additional certificates
4. is generally only trusted by a restricted group
5. commercial CAs require certified RP SW, contracts
this is simply put entirely uninteresting

The government cards are status projects.  We have issued
x millions cards.  That they are only used as physical ID-cards
is something they are slightly less open about...

Banks in Scandinavia put eID on credit-cards which means that
every merchant get your SSN as well (if they want).

As I say all the time: Google and Apple will make all EU cards look
like they always was: A pile of s--t.

Anders

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 21:25:20 +0200

> why would the browser vendor bother about how it works?

This is where I disagree. It is not far from becoming the core authentication on the internet. Really really not far.  It may be surprising, but I have explained in detail here why I believe such a counterintuitive thing. More here http://webid.info and on my home page.  

Social Web Architect
http://bblfish.net/

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Thu, 28 Jul 2011 15:42:15 -0400

Anders,

Where is your data on government cards usage coming from? 

In US a lot (literally millions) of government email and Web access is secured by what you call "government cards". 

--
Regards,
Uri

----- Original Message -----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 03:10 PM
To: Henry Story <[email-masked]>
Cc: S.tefan Winter <[email-masked]>; Martin Gaedke <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] EU cards

Now to the cards: Since

Anders

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jul 2011 02:06:11 +0200 (MEST)

Anders,

> particularly if you use it from a browser.

I'm sorry for loosing my temper.  You don't deserve this.

I don't know what particular issue banks have with their
weird threat model here in Germany, I'm unable to find an even
remotely reasonable explanation why so many of them are suddenly
violently determined to completely kill any of their existing
paper-based TANs, including iTANs that they introduced just
a few years ago, aggressively touted as something that you need.

I do not want having to carry around any of their fancy hardware tokens
with keypad and display (and personally bear the risk for loosing or
breaking it).  Nor do I want having to carry around a mobile phone,
let alone buy and carry a smartphone for similar reasons.

> can safely drop this thread; it won't go anywhere.

TLS when used by web browsers for HTTPS is a transport protocol
with non-persistent connections, which means that the only sensible
operational model for TLS client certs in browsers is for Single
Sign-On, everthing else is either a security problem or a
usability problem or both.

But attributing intent with a web browsers HTTPS CCA authentication or
authorizing transactions with it seems like a very bad idea, because
of the numerous problems in the entire architecture.

Browsers do _not_ enforce that elements on a page all come from
the exact same server when HTTPS is used, and MSIE8 and Safari4Windows
on Windows 7 do not even tell you which server is asking for a client
certificate when showing you the client cert selection box.

I assume that active content could even perform request "dark" in
the background while the pages that you actually see do not look
suspicious at all.

13 years ago Online banking regularly worked with secure browser
setting (i.e. active content disabled), pure-html and very quick
response times.  Today, most online banking requires active
content enabled and is dead slow for no reasonable purpose.

> It's an entirely different ball-game now!

Smart phones are already attractive targets for theft even with no
additional digital gems added by the end user.  Significantly
further increasing the attractiveness of that target for both,
digital theft through malware and physical theft of the smartphone,
does not seem overly sensible to me.

>From what I read in the german computer magazine,
  http://www.heise.de/artikel-archiv/ct/2011/15/154_kiosk

all existing iPhones and iPad1s seem to have the vulnerability
in the Boot-Rom (i.e. Hardware, no possibility to fix by software update)
that might enable thieves to bypass many if not all of the assumed
"protections" and retrieve your private data.

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Jul 2011 07:07:34 +0200

> Where is your data on government cards usage coming from?

various mailing lists such as:
http://www.opensc-project.org/opensc

Most of the people hanging out there are in some way working with the EU cards.

> 
> In US a lot (literally millions) of government email and Web access 
> is secured by what you call "government cards".

I guess you refer to PIV and CAC?
There is a fundamental difference between the US and the EU and that
only in the EU there is something called "citizen-cards" or eID.

Citizens are supposed to buy eID for carrying out secure services on
the Internet.  The cost have been high; results have been marginal
for the reasons I listed (and some more...).

Obama's NSTIC is something similar (but still very different) that
will be slightly interesting following although I don't think
their NIST friends really understand the consumer market and
the huge technical issues they will have to deal with.

IMO, the PC platform is dead as a vehicle for innovation; they
might go to phones from the start.  I never understood why
you need a picture on a token for Internet access :-)

Well, "it has always been like that" is probably the [lame] excuse.

Regards,
Anders

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 18:17:28 +1200

Anders Rundgren <[email-masked]> writes:

>Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why would the 
>browser vendor bother about how it works?
>
>Now to the cards: Since
>5. commercial CAs require certified RP SW, contracts this is simply put 
>entirely uninteresting

You forgot 2a:

2a. The middleware is buggy, unstable, only works on certain system 
configurations or on certain hardware, prevents or upsets normal operation of 
the system it's installed on, etc.  Vendors mostly ignore bug reports, and 
aren't interested in updating their drivers unless you go back and buy another 
half-million cards.

>The government cards are status projects.  We have issued x millions cards.  

I tend to refer to them as "government charities", but that's more or less the 
same thing.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 18:26:38 +1200

>by what you call "government cards".

Ah yes, the common access card.  Let me tell you about the CAC.  A couple of 
years back, a bunch of us were in a taxi line at a hotel.  I was wearing a 
shirt that said something about PKI.  Someone behind us in the queue (who 
turned out in later conversation to be a mid-ranking US military person) asked 
what the shirt meant.  When we explained it (briefly), his response was "Oh, 
you mean like the CAC?  Man, that stuff SUCKS!".

As a member of our party later put it, "when random strangers stop you in taxi 
queues to tell you how much the technology sucks, you know there's a serious
problem".

This is why, in a previous message, I specifically asked for reports of 
European banking authentication from independent third parties and end users, 
not the people involved in deploying it.  As Anders points out, these are 
status projects, if you ask the people involved in the deployment then you 
always get the same response, "we have millions of them deployed, it's a great 
success".  You have to ask the end users to get a real picture of what's going 
on.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jul 2011 18:39:16 +1200

Martin Rex <[email-masked]> writes:

>I don't know what particular issue banks have with their weird threat model 
>here in Germany, I'm unable to find an even remotely reasonable explanation 
>why so many of them are suddenly violently determined to completely kill any 
>of their existing paper-based TANs, including iTANs that they introduced just

This has been covered in a number of journal/magazine articles, for example 
there was a fairly comprehensive one in c't in the middle of last year on 
this.  Since paper-based TANs aren't tied in any way to the transaction 
they're authenticating, they're vulnerable to both phishing attacks and MITB 
attacks.  iTANs were introduced to counter straight phishing (ask for the next 
n TANs), the attackers countered with more aggressive TAN phishing and MITB, 
and the response to that was mTANs and tokens.  So German banks are actively 
tracking threats as they evolve and responding to them, which few other banks 
seem to be doing (or at least if they are, it's not documented anywhere).

This is probably why US phishing losses are a staggering *six hundred times* 
higher than German ones.  In Germany the banks try and address evolving 
threats.  In the US the banks take their customers to court when they become 
victims of poor banking security.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Jul 2011 09:34:27 +0200

> aren't interested in updating their drivers unless you go back and buy another 

You are [unfortunately] quite right.  The (relative) success smart cards have
had in controlled environment such as payment terminals cannot be translated
to the completely uncontrolled consumer computer base.

I see two possibilities:
1. The easy one.  Let Apple with iPhone/iPad provide us with the "container".
2. Define a new container where the interface is strict and support provisioning
so that even Joe Sixpack can succeed.  This is my take on the subject which
though is about 100 times more difficult than what Apple needs to do so
I guess I'm an idiot even trying...
http://webpki.org/auth-token-4-the-cloud.html

I just don't like the idea of going from an OS monopoly to a fullblown
OS + Device + Infrastructure monopoly. Banks and Governments have little
to compete with and will also [much too] late realize they're screwed.

Anders

> I tend to refer to them as "government charities", but that's more or less the 

:-)

Anders

---

From: Henry Story <[email-masked]>
Date: Fri, 29 Jul 2011 10:00:19 +0200

My take from this whole discussion is that PKI has been sold to unilaterally to one group of people. It has been sold to large banks and security heavy industries. They tend to make things more complicated, and their security people are too security conscious, having to deal with the most determined enemies. A good security profession in banks MUST like a good military man, be far from the daily family life. He is there to think about disasters, so that they don't happen, so that nobody should think about them. 

What should happen instead is to lower the security requirements, and enter the mass market. Just as we don't put fort knox security on our houses, but use simple keys with well known security issues, so one should start using PKI in a cheap but useful way. Of course PKI has to solve a problem that passwords don't solve, otherwise they can't get traction. But they don't have to solve EVERY security problem. 

To get that ball rolling PKI has to be dirt cheap, and extremely useful. It has to be 
 - one click to create a throw away certificate
 - authenticate across all sites (as Facebook connect does)
 (-> tie into the social web)
 
 That would provide a big enough improvement over passwords to get people interested, and it has a viral side to it. As soon as it works for enough people, those people become interested in getting others on board too.

 With millions or billions of adopters you can create the momentum, and the mass market, that will make all the other problems easy to solve. If there were just a million active developers in open source software using PKI every day for checking in software and communicating with their peers, you would soon find the technology make its way into every web site, and browsers being adapted to make their interface easy to use. With mass adoption it would be much easier to solve all the other technological problems, because citizens and politicians would have an immediate understanding of what you were talking about. 

That is what http://webid.info/ offers. Start with the low hanging problems: passwords. Then move on to add technology piece by piece to move up the security ladder.  This is the way technology works. Microsoft started with DOS and moved its way up to more and more secure versions of Windows - whatever you think of their OS you can't deny that that was a very successful strategy.

   Henry

Social Web Architect
http://bblfish.net/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 29 Jul 2011 11:00:54 +0200

> My take from this whole discussion is that PKI has been sold to unilaterally to one group of people. It has been sold to large banks and security heavy industries. They tend to make things more com…
[...]
> That is what http://webid.info/ offers. Start with the low hanging problems: passwords. Then move on to add technology piece by piece to move up the security ladder.  This is the way technology wor…

If you are referring to PKI as in PKIX (X.509) then banks had nothing
to do with it. Banks had their own set of standards that never took
off. PKIX was based on a telecommunications standard, that evolved
over the years as DOS in your example did. Many people think that this
was a sucessful strategy as well, and some others think it is just
ugly.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Jul 2011 14:33:26 +0300

On Jul 29, 2011, at 4:00 AM, Henry Story wrote:

> What should happen instead is to lower the security requirements, and enter the mass market. Just as we don't put fort knox security on our houses, but use simple keys with well known security issues, so one should start using PKI in a cheap but useful way.

The well-known issues in keys allow an expert to invade a home and steal the big-screen TV. It does not allow the expert to automatically invade all 100,000,000 homes in the US and steal every TV. Computers are very good at automation.

> (-> tie into the social web)

So what would PKI (with throw-away certificates) bring to the table that facebook connect doesn't?

> That would provide a big enough improvement over passwords to get people interested, and it has a viral side to it. As soon as it works for enough people, those people become interested in getting…

I don't see why. Logging into my bank to check my account balance is not one of those activities I like to share with friends. This is totally different from watching a funny video on youtube or pictures of cats with witty remarks.

> With millions or billions of adopters you can create the momentum, and the mass market, that will make all the other problems easy to solve. If there were just a million active developers in open s…

Again, PKI without a trust relationship with an identity provider can make some protocols more efficient (compare OpenID to BrowserID) but it doesn't bring any new security to the table.

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Fri, 29 Jul 2011 10:59:47 -0400

In general I'd disagree - but you've made an excellent point about innovation on PC being dead (and therefore no chance to properly secure them while keeping 'em usable). US DoD is moving along the "secure 'em" axis, thus making usability suffer (many reasons for that). Thus many bitching end-users (and some of them actually have reasons to). But overall - comparing what CAC were expected to do with what they actually do - I'd call it a success because they _work_, like it or not. (Now OS changes version and fragile middleware quits, some readers aren't supported, etc - overall not a pleasant picture, but the infrastructure is fine and the capabilities are right.)

--
Regards,
Uri

----- Original Message -----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, July 29, 2011 01:07 AM
To: Blumenthal, Uri - 0668 - MITLL
Cc: [email-masked]' <[email-masked]>
Subject: Re: [TLS] EU cards

Regards,
Anders

---

From: Henry Story <[email-masked]>
Date: Sat, 30 Jul 2011 10:41:09 +0200

> The well-known issues in keys allow an expert to invade a home and steal the big-screen TV. It does not allow the expert to automatically invade all 100,000,000 homes in the US and steal every TV.…

That is why no banks just accepts crédit card transactions automatically. They check the recent pattern of activities and compare it to someone's usual pattern of activity. TLS does not remove the need to keep doing this type of checking. 

Again we have here the knee jerk security reaction that tries to compare TLS with an ideal technology which does not exist, and then finds it wanting.

Consider also that most web sites one has access to don't have anything to steal. If you do propose financial transactions, then just add extra levels of verification.

> So what would PKI (with throw-away certificates) bring to the table that facebook connect doesn't?

Complete decentralization. Banks, companies, personal servers can all participate. There is a short video on http://webid.info/ that explains that. If you find that interesting you can also see the paper I presented at the first conference "Web & Philosophy" sponsored by the W3C that is on my home page.

> I don't see why.

That is because you have not yet understood the distributed nature of WebID, as your previous question revealed.

> Logging into my bank to check my account balance is not one of those activities I like to share with friends. This is totally different from watching a funny video on youtube or pictures of cats with witty remarks.

You would not be going to your bank account as a social site to chat with people. But you could potentially use your bank certificate to authenticate on other sites. (This is something that would require some brainstorming - think of these few paragraphs as an initial lightenging.) The Bank would put it's webid in the Issuer Alternative Name. Every country could publish a list of its legal banks and those it recognized from other countries.  Perhaps the US would publish in https://data.us.gov/banks/ a file containing among other things the following relation

<http://wellsfargo.com/about/#wfrg> a us:Bank .
... 

So here the social part is not in who you know, but who knows your bank. And of course at that level it is states and the global network of states that form the apropriate social partners.

In a banking situation your WebID is not linked to by friends, but more by commercial transactions. Your bank webid could be

  https://wellsfargo.com/acnt/1231241243#acnt

If you noticed a problem with your private key it's public key would be removed from that document. 

> Again, PKI without a trust relationship with an identity provider can make some protocols more efficient (compare OpenID to BrowserID) but it doesn't bring any new security to the table.

There are many more uses of PKIX once one ties PKIX into the web. Should we call this PKIW?  
The point is to explore and massively grow the use of PKI here. 

Btw, this in itself will massively increase security, as it - with DNSSEC and DANE - will move us to a 100% https web. Think of the huge security holes in the web currently. A few endpoints are https protected. But all the other web pages people click on to reach that web site can be man in the middle attacked and the links in the html be rewritten to point to fake sites. The pages that the Google crawler receives, can also be man in the middle attacked. Allow each resource to be protected just a little bit will in the network effect of the web lead to huge improvements overall.

Henry

Social Web Architect
http://bblfish.net/